Content is available under Creative Commons Attribution.


Automated Deployment Neutrality

Once you have automated your deploys, it will make you start thinking differently about how often, when and what mechanisms you will use to update your site. Many people patch and release code differently. But if you ask me, ideally, you would treat every change to your production site the same, with a full deploy. All too often, I have seen people ftp’ing changes or making changes directly in production to get the change out quickly. I propose a different solution, get your deploy time down and consistent.

Automated Deployment
If you are still deploying by hand, then stop now and go and automate your deploys. Every change that goes out to production should be done with an automated script, ideally at the push of a button, pulling from a source code management system. This ensures that all your deploys are consistent and all dependencies are updated or restarted as need be. Manual processes all too often lead to silos of information that are not easily transferred from one person to another, instead document your deploy process in the code.

The 5 Minute Deploy
Ideally one should be working to achieve a 5 minutes or less deploy time, from start to finish. I know this sounds crazy, but it can be done. I recently challenged a company that once had a 2 hour deploy process, which took down the site, to review their manual process and get it down under 5 minutes with automated deployments. We got it down to 15 minutes pretty easily, the last 10 minutes were deemed impossible. By the end, we had it down to less than 5 minutes with the help of more automation. As a bonus, the site is never taken offline during maintenance or updates.

Database Changes
Changes in your database often lead to problems in your deployment process. Out of sync code and database schema is the most prevailent problem. A good way to deal with this is to always be looking forward and to do reversible changes. The biggest problem comes with dropping a column that your application is depending on. But that is workable, first change the code to not use that column (or use a different one), then deploy again, since it will only take 5 minutes per deploy. Sometimes data migrations take a long time, do this in the background to a new table, outside of the deploy process, and ensure that it is a recoverable process. Once the data is migrated, then start using it by swapping the data or by deploying new code.

Patching Production
There is no such thing as a patch to production once you have the 5 minute deploy process. Even if it is a 10 or 15 minute deploy, it is always best to treat any code change the same. Just update your code in the SCM and deploy.

Automating deployments for applications and software is possible with a tool such as Leroy build engine.

Leave a Reply

by: Epic Force