Skip to content

24 ways to impress your friends

Developing Robust Deployment Procedures


Comments are ordered by helpfulness, as indicated by you. Help us pick out the gems and discourage asshattery by voting on notable comments.

Got something to add? You can leave a comment below.

Jason Resnick

This is all great and I’m all for any process that makes it easy to rollback in case of a blow up. But my question is what would you do if you have a client that you work on their site from time to time, but they also work on it. The caveat here is that they don’t have any knowledge of source control and just make changes on the fly.

Would you “sync” their changes each time you work on it? Or would you totally abandon the process?

Amazing article for sure — this is something that I think those that aren’t using a defined deployment process would be able to follow this to the “T” very easily & quickly.

Seb Duggan

I’ve been deploying via Git for a year or so now, but have a slightly different method (albeit one that probably requires more than just FTP access to a production server).

I set up Git and SSH on my production server; I then init a bare Git repository on the server (but separate from the actual web root). To this I add a “post-receive” hook which runs when the repo is updated, and checks out from the repo to the specified working directory (the web root).

Then you can simply add this as a remote (“production”) on your local repo, and push to this in exactly the same way as you would to Bitbucket etc. The repo is updated on your production server, and then when it has completed, the code is instantaneously checked out into your web root.

Full details of this slightly different method here:

Aaron Bassett

Jason Resnick: I would never recommend developing on a production environment, but I understand that sometimes you just have to work with the hand you’re dealt! if there is no way to avoid the situation you describe then I would:

* Create a “release” branch for the client
* Have a CRON job which at the end of each night does a git add . && git commit -m “Save client changes for $DATE && git push origin <branch name>”
* Before I begin work pull down the most recent client release branch and squash commits before rebasing onto my working branch
* Once finished push up my working branch and create pull request to master
* Merge into master, pull down onto production, GOTO #1

Aaron Bassett

I wouldn’t suggest doing automatic deployment to the live site.

The trepidation might be because you haven’t mentioned automated testing even once in this article? I know this is a very basic introduction but testing is such a fundamental part of development that it really should be taught right at the start.

There are even tools now to make automated testing much easier (such as travis-ci) which could be integrated into the workflow you describe.

* Edit your files locally as before, testing them through a web server on your own computer and running your automated test suite.
* Commit your changes to your local Git repository on your feature branch
* Push changes to the remote repository.
* Create a pull request to your master branch
* Wait for Travis to run your test suit
* Once all tests pass merge into your master branch
* Log into the deployment service.
* Hit the Deploy now button.
* Preview the changes.
* Run the deployment and then check your live site.

David Fregoli

There’s one big advantage over ftp you haven’t touched, speed; using git’s deltas and compression and eliminating ftps connections overhead is a huge benefit.
I also use a post-update hook, using method 4.1 described here
node-modules and minified js/css are not checked in, the hook also does an npm install and all the browserify stuff using the npm run strategy described by James Halliday here (who needs extra ulta-complicated task runners??)

Nicolas Chevallier

It is very important to drop the transfer via FTP and move to an automated deployment, based on Git (or other soucre control). A MAJOR advantage is that during the deployment phase we can automate other tasks: minification, concatenation of scripts and CSS , compressing images for example. Or create a CSS sprite, regenerate cache files, launch test batchs … The possibilities are endless!

Adrian Kirsten

When it comes to deployment, I have found a lot of success using Github’s (Bitbucket, gitlabs, etc) POST Hooks. Just throw in a single line php file, and deployments happen automatically.

The only real setup is getting the server’s www-data user authenticated to your git host.

I then use branches for differen’t deploys. Staging branch deploys to staging server, master deploys to production.

Iszuddin Ismail

I have been using Git deploy for the past year. But my simple hack is to use the hook that is available in Github or Gitlab. That will trigger a script in the designated server and does a git pull.

Another step is this — it doesn’t simple pull everytime there is a push from the developer. It will only do a pull when it is of specific branch, ie “live”. Also not everybody can actually push to this branch. So before anything is merge to the “live” branch, it is thoroughly tested on staging, dev, etc.

But then comes the problem of autoscaling. I am on AWS, I user their ELB load balancer and I have created an autoscaling rule where servers (EC2 instance) will be added and remove based on certain rules I’ve set, like CPU usage percentage, etc. The problem with this setup is that I can’t simply create a new hook every time a new server is added — especially when I don’t quite know when that is.

So I created a PHP script (let’s call it githook.php) to handle this for setup at AWS with Autoscaling. githook.php is triggered from GitLab’s hook settings. It queries your load balancer and asks for information of the instances under it. And then it will trigger a web requested to specific URL (let’s call this gitpull.php) using the instances’ IP address. gitpull.php will simply do a git pull for the project.

And today, I just discovered AWS has CodeDeploy…

Any, if anybody finds this useful.

Vincenzo Coppolecchia

Thanks for the article, it really helps. I was thinking to a way to cut on deployment time, it really is tedious and error prone for me.

This year I’m proud to be already improving my workflow by adding version control (Git) and a task runner to it (Grunt)! I can’t imagine going back to my old habits, and this will also be a sweet add-on! :)

Alex Storkey

This is probably out of scope for this article, but I’m curious as to how you’d handle vendor-dependencies (npm/bower/composer packages obtained from a 3rd party) using this approach? A post-deployment hook on the remote server maybe to download new packages?

Keiron Lowe

Thanks for the article. I’ve been deploying via Git for a while now, I just SSH into the server, and pull in the latest changes and execute some commands.

What are the benefits of using deployment software over my method? Apart from the 1 click deployment?


Tom Dyer

What a fantastic article, I have been searching for this information for a while now. Fantastic and easy to take in. I am impressed, thank you 24ways!

Danny Zabolotny

I’ve actually been deploying sites with this method since I started working full time as a dev earlier this year. I use Tower to manage my hosted repos on Bitbucket, that way I never have to touch the command line. For deployment I use, which my company pays for. It definitely makes life a lot easier for all the Wordpress development I do.


Thanks for this article, good inspiration for us that still hasn’t moved on from FTP uploading!

I’m in the same boat as previous commenter Vincenzo, just started using Git and Grunt this year. This deployment workflow will be the first on my list to get implemented for 2015! :)


Great & useful article which gave me the kick that I needed to finally automate the deployment process of my site. Thanks for the detailed steps, made it easier to start.

Impress us

Be friendly / use Textile