<<< Back to the blog

Git deployments

it me
Published on
Warning: This post is over a year old. I don't always update old posts with new information, so some of this information may be out of date.

A look at how I'm deploying projects using Git.

Back in March I laid out our Git workflow - in that, I made it known that I hadn’t settled on deployment strategy.

I’ve been trying to get Capistrano to work with ExpressionEngine but just haven’t managed to sort that.

I looked at Dandelion which is deployment via SFTP or FTP which works nicely but doesn’t give me enough options in terms of deploying from specifc Git branches.

The current method was deployment using DeployHQ or cloning the Git repository into production and then each time there was a need to deploy I’d SSH into the server and doing a git pull.

While this works, having to SSH into a production server, cd into the Apache root and then executing the pull each time we wanted to deploy was a few steps too far. Anything that can shave key presses off a process is a productivity win in my book. The same could be said for using DeployHQ, opening the browser, clicking the bookmark, logging in (even with 1Password), browsing to the project and then choosing the deployment server, it just doesn’t scream efficient.

Our new method

So we're now using Git hooks to allow us to do git push production master

This is a run down on how it works.

On the production server:

$ ssh [email protected]
$ mkdir /home/user/projectname.git && cd /home/user/projectname.git
$ git init --bare
$ nano hooks/post-recieve

You then want to paste:

GIT_WORK_TREE=/home/user/public_html git checkout -f

Into the open file via terminal and save the changes - we then need to change the permissions on file by doing:

$ chmod +x hooks/post-receive

Back on our local environment we want to add our production environment to Git, you can do that via Terminal or using Tower.

Using Terminal we want to do this:

$ git remote add production ssh://[email protected]/home/user/projectname.git
$ git push production +master:refs/heads/master

And that will deploy our master local branch into the production repo and then execute our post receive hook to deploy into the appropriate location.

The benefit here is that our production repo never gets production files added to the working tree, ie a website admin adds images to a blog post or page meaning we never need to stash or delete those files from production.



Leave me a message. If you like what you read here, there's a great chance we could be a good fit. If it's something I don't do, I'll likely know someone who does.