I recently wrote about doing continuous deployment from day one with a software project that had pretty good test automation and (if I do say so myself) a somewhat modern and decent architecture.
I’ve recently transitioned to working on a fairly ambitious overhaul of an existing project that has been around for a few years. The software has already reached a (mostly) working steady state and is used every day by real customers.
The very first thing I did, ahead of making any functional changes, was automate the deployment system using essentially the same kind of test gauntlet and approach for zero-downtime deployments I was using at Victors United. I added some very basic test automation, starting from the top of the test automation food pyramid with a simple “is the web server able to execute code, connect to the database server, and return an ‘OK’ rsponse?” test. From there, I’ve working my way down, just getting around to writing my first “pure” unit test just today.
Only after I was confident that I could do zero-effort and zero-downtime deployments that
- Wouldn’t completely destroy the system (I had a test for that) and
- Could be rolled back very easily if something went screwy
did I make my first functional change to the software.
And then, I made the smallest functional changes that could work. I tested them locally, added some test automation around them, and then let the automatic deployment system do its magic.
A few years ago, I was interested in doing continuous deployment, but I felt that the level of test automation wasn’t good enough, I wanted to be at least at around 90%. Now I think that the less test automation you have, the more important it is to start doing continuous deployment of tiny incremental changes right away.
If you are working on software that’s actually in use and are interested in doing continuous deployment someday, there’s no better someday than today. Seriously. Do it now. It will start making your life better almost immediately.