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.

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: http://sebduggan.com/blog/deploy-your-website-changes-using-git/

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

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.

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 http://gitolite.com/deploy.html
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 http://substack.net/task_automation_with_npm_run (who needs extra ulta-complicated task runners??)

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!

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.

+1 on DeployHQ, great service.

When things get a little more serious Capistrano is also worth a mention.

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. https://github.com/kidino/Git-Deploy-ELB

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! :)