On the benefits of using
Git or other version control software to deploy software, instead of traditional
This is a brief discussion (~15 minutes) on using Git, Mercurial or other distributed version control software to deploy software to servers. It works when you have one or two servers and rapid iterations.
Traditionally, software is deployed by simply copying it to the server over FTP or SFTP. More clued-in developers use rsync for its ability to update only changed files. There are two problems with this approach:
No version control for deployments. You may have versioning in your development environment, but you’re missing it in your deployment. It’s not easy to roll back if something breaks.
You have to separate your development configuration files from your production configuration files. You could accidentally overwrite production config with development config, breaking the site.
Distributed version control systems provide a better way to manage deployments. They already understand how to ignore certain files (specified in
.hgignore) an allow committing a change and pushing it to a remote location that isn’t necessarily the central repository. You can commit a change and push it to a test server. On the production server, you can pull changes from the repository and Git/Mercurial will automatically ensure that config files are not clobbered.
This approach is trivial to setup and makes for much peace of mind when deploying rapid iterations.
During the session I’ll present on how I manage my deployments and then we’ll discuss how you do yours.