Expressionengine 2 and git (version control)

Sorry for the duplicate post, but does anyone have any insight on this?

I’m exploring that same issue: how effectively can EE2 be managed through Git.

I’m working on a network of websites that will constantly grow in features. My ideal scenario is create on a development repo, then when a particular feature is finalized, push it to the production repo.

So far I’ve committed the entire local install, except for any upload directories and [system folder]/expressionengine/cache. I have the system directory above webroot, along with the templates directory (for quicker access, as this will be altered much more frequently than the ee system).

I’m uncertain how things like installing plugins will be handled; I’ll be playing around with it today, and let you know anything I find.

Awesome, it’s good to know I’m not the only one. I look forward to hearing about the experiments you are conducting, I’m sure they’ll be useful!

Just wanted to let you know that I finally have a viable solution worked out. I have to do a bunch of work, but I’ll post the write-up as soon as I have a chance.

Looking forward to it. This is a topic of great interest.

Okay, finally got a break! Apologies for the delay. So, where does Git fit into EE?

Git can be an immediate-access backup solution. It can be used to rapidly transfer files between servers/workstations. And finally, of course, it is development version control. Here’s the setup I’ve implemented:

I’m on a dedicated server, so some things I mention won’t work on fully-managed shares such as EngineHosting. However, you MIGHT be able to push/pull from local using with just FTP access; if somebody could test this and post on it, I would really appreciate it.

So, first up is directory structure:

Setting up your directories

On my dedicated server, I have two accounts, development and production. In each home directory I have the following files (among other server/os files):

.git/ - the git repository .gitignore - the file listing what files to ignore [system folder] - the EE system folder moved above webroot [templates folder] - the EE templates folder for flat file templates, for quicker access as the are typically the files being developed [webroot] - typically htdocs/, public_html/ or something similar, where your index.php lies (along with admin.php for masked CP access).

In my [webroot] directory, I also have an ‘assets’ folder containing 3rd-party css/js files and css images, and ‘images’ and ‘media’ folders for user uploads.

To set this up, don’t bother doing a full ExpressionEngine install on the server. Instead, create your local version first, mirroring how it will be set up in the site home folder. To make it easy, I’m using XAMPP on my Mac.

Once you’ve installed EE and are done with all the setup/configuring for site/template access on your local install, we can get rolling with Git:

Writing .gitignore

Now that EE is set up, install Git, and we’re ready to configure. First, we need to create the initial .gitignore file, to tell Git what we don’t want in the repo.

I should explain my EE2 Git repo philosophy first. Some people use git to back up everything in their project; I don’t find that is convenient for EE. Very little in the EE2 system actually changes often; most is done in the database. For most files, I find that if anything ever corrupts, I can just pull a new file from an EE archive. Other files have hard-coded paths or other info, such as database access credentials, that you aren’t going to want to edit every time you push/pull from one location to another. In the event of corruption, these are easily replaced, so again, you’re not going to want these in the Git repo.

.gitignore is just a text file containing lines for files that that shouldn’t be added to the git repo. Anything without a directory / is considered a pattern.

So! My .gitignore file contains the following lines (im using MSM as well, hence the ‘secondary sites’ stuff):

#os or program files
.DS store
.tmproj

#ignore main and secondary sites' index.php and admin.php files
public_html/index.php
public_html/admin.php
public_html/*/index.php
public_html/*/admin.php

#ignore main and secondary sites' upload directories
public_html/images/uploads/*
public_html/media/*/uploads/*
public_html/*/images/uploads/*
public_html/*/media/*/uploads/*

These files are ignored because they contain paths respective to each server/local account. These will have to be intially edited for each account, but won’t change after.

Once this is written, Git can be initialized:

Initializing Git

The local site copy is set up, Git is installed, .gitignore has been written; let’s fire Git up! Open up a terminal, move to your site’s home directory, and type

git init

This has created the empty git repository in .git/. Now we need to add files to the repo. Like I said earlier, I only want things in the repo that are either: a) files modified often b) site-critical files that cannot easily be recovered from an EE2 archive c) and don’t contain hard-coded paths

so in the terminal, type the following:

git add .gitignore [webroot] [system]/expressionengine/fieldtypes [system]/expressionengine/plugins [system]/expressionengine/extensions [system]/expressionengine/modules [system]/expressionengine/third_party

where [webroot] is htdocs/, public_html/, or whatever your webroot folder is named and [system] is your EE system folder.

The adds your templates folder, .gitignore file, everything in your webroot file besides user upload directories/files, and the fieldtypes/, extensions/modules/plugins, and third_party/ directories of your system folder. This way, additional plugins/mods/whatevers only need to be installed once, and once tested to insure interoperability, can be pushed to your dev or production servers.

all that is left is to make your initial commit

git commit

and viola! You are rolling with Git.

Setting up remotes

Of course, Git locally is great, but what we really want is to push/pull stuff between our local and remote environments. So! Let’s get those working.

First, via FTP, copy the entire contents of your local site home directory to your remote account. Remember to include .git/ direcotry and the .gitignore file.

Follow the guide to site migration, and definitely use deeploy_helper to ease the process. Double check your permissions as they can get mangled in FTP.

Before you can access your remote, you will want to setup SSH keypairs.

Now, open a terminal, cd to your local site’s home directory (where the .git/ repo is), get your site shell access credentials, and type

git remote add [repo name] [username]@[address]: ./.git

where [repo name] is whatever name you want to give your remote repository, such as “development server”, and the username/address are your share credentials.

You now have your remote in place, to which you can

git push

or

git pull

.

And that is how I’ve set up Git! I’m still refining my workflow, and will post about it when I feel I have something worth sharing. I would love to hear anybody else’s comments, setups, etc etc etc. I hope that this is helpful and saves you a few hours of headache that I spent figuring out how to pair Git/EE2.

I should mention, pushing/pulling does nothing regarding the database. Since EE2 is so database-centric, you’ll have to import/export the db anytime you want to keep users/plugins/etc consistent. I haven’t seen how this will play out yet, so more info in the future.

I’m in the process of refining our deployment strategy with git as well, although ours is remarkably different! (Amazing how flexible and powerful git is.)

I’ll run through it as briefly as possible here. Our strategy includes a local development box (an iMac running Snow Leopard) and our production server. (No need for staging on this particular project since it’s an in-house gig.)

We’re using git for version control and Codebase for repository hosting. (I took a look at GitHub, and it’s awesome, but Codebase is just a better fit for us given the tools available and the value. I’d encourage everyone to take a look at it.)

The folks who run Codebase have a new product called Deploy that’s currently in the late stages of beta testing, and you get a free Deploy account with your Codebase account. Deploy connects to our production server to push updates based on our Codebase git repository, and it allows us to push custom files and run SSH commands as well. We’ve got a shell script that Deploy sends to the server (read: not version controlled in our repo) that clears the cache and corrects any incorrect permissions, and then we have Deploy send an SSH command to delete the shell script. Done and done.

(We considered Capistrano, but since its site has been down for days, we had to choose a different strategy. Besides, we’re cool with the deployment part of our process to have some GUI goodness.)

We’ve decided not to ignore the config.php, database.php, or constants.php file in our git repo after following Matt Weinberg’s excellent article at EE Insider on setting up a dynamic config.php file. After modifying our config.php file to work no matter what server we’re on, we ran with the idea and adjusted our database file to use CI’s database groups. (More on this later.)

We’re also running this particular project on a shared server with suPHP which requires all directories to have 0755 permissions and files to have 0644 permissions, so our constants file needed to be modified. We use a switch to determine which server we’re running on first:

switch($_SERVER['HTTP_HOST'])
{
    case 'mysite.com':
    case 'www.mysite.com':
        define('SITE', 'live');
    break;
    
    case 'mysite.dev':
    case 'www.mysite.dev':
        define('SITE', 'dev');
    break;
    
    default:
        define('SITE', 'live');
    break;
}

Then we run the constant SITE through an if/then statement to define the permissions constants that CI needs:

if (SITE === 'dev')
{
    define('FILE_READ_MODE', 0644);
    define('FILE_WRITE_MODE', 0666);
    define('DIR_READ_MODE', 0755);
    define('DIR_WRITE_MODE', 0777);    
}
else
{
    define('FILE_READ_MODE', 0644);
    define('FILE_WRITE_MODE', 0644);
    define('DIR_READ_MODE', 0755);
    define('DIR_WRITE_MODE', 0755);
}

Now because CI loads the constants.php file before the database.php file, we can use the SITE constant defined in constants.php to switch between database groups. Create your groups based on this info in the CI User Guide so that you have at least a dev and a live group:

$db['dev']['hostname'] = "127.0.0.1";
$db['dev']['username'] = "db_username";
$db['dev']['password'] = "xxxxxxxxx";
$db['dev']['database'] = "dev_ee_db_name";
etc...

$db['live']['hostname'] = "localhost";
$db['live']['username'] = "db_username";
$db['live']['password'] = "xxxxxxxxx";
$db['live']['database'] = "live_ee_db_name";
etc...

Then add this to the bottom of your database.php file:

// Check the configuration group in use exists, if not use the default
$active_group = (defined('SITE') && array_key_exists(SITE, $db)) ? SITE : 'live';

This is working quite well for us so far, and it allows us to keep in our git repo everything except the assets/uploads folder (which is where we moved all the upload directories normally located in images).

Changing paths and all that was always such a bear, so we’re thrilled to have a dev/live setup where all we have to worry about is the database.

hearsay,

Thanks for the link to the dynamic config file! Ideally I would like to have the entire system in .git, but it wasn’t possible with my limited knowledge. I might be making a version 2 based on this new info.

Yeah, I was pretty excited when I got the dynamic files working. Much less work and troubleshooting later!

Thanks for taking the time to do this writeup, Kevin. I’ve been meaning to test out the same setup as you got. I’ve been using Codebase this year, and it’s been lovely, including the pricing. Now, my current setup is for EE1, but I based it on among other things Leevi’s EE2 config file here: http://gist.github.com/448166/358877917bd92074ddaa5af2a3688a2eb8cb4588

His way of defining things is really clean, and my prefered method as well. Looking forward to trying Deploy as well. I’m in the middle of optimizing my base install + looking at deployment right now, so I’m sucking up every worthwile tip I can find. It feels especially fitting right before EECI 😊

Could you tell us about that shell script of yours?