Automatic deployment
Created: 2007-12-13 23:38:51, last updated: 2007-12-13 23:57:05
This simple technique is a must when doing Continuous Integration, but no matter if you are an early releaser or not, after going into production, most of your applications will require to be updated, modified, or bug fixed after going live. In this article I would like to encourage you to adopt an old practice that will save you a lot of time while giving you more trust when working in production: Automatic deployment.
What problem does it address?
What Automatic Deployment tries to do is to speed up the deployment process but it also eliminates the risk of the changing files in production by hand. Another benefit is that we can automate backing up the live site before doing the changes so we can rollback in case something goes wrong (most deployment scripts do this).
How can I implement it?
I'm just a novice on this, so I have created a small bash script that backups the current folder in a tar archive, deletes that folder and exports the head revision of the svn server. Then it just overwrites the database configuration file. (If I updated that file, I would have to upload it manually to the server, but I can live with this, as this file won't change for the moment). This way I would have to manually rollback when something doesn't works, but I could quickly create a simple rollback script to wipe the site's folder and untar the backup.
What you must take into account is that whenever you're using a bash script or a powerful deployment application such as capistrano, it must provide the following:
- Handling for production configuration files.
- Backups
- Rollback
and it has to do it very fast.
