The ability to deliver code all the time, sounds magically. I propose most companies aren’t that far from enabling this within their development teams and even their legacy code bases. One of the most common arguments against is that we don’t have enough automated tests to continuously deliver.
I’d argue that the 4 things you need to enable continuous delivery are:
- continuous integration
- a minimum of 2 automated tests
- blue green deployment setup
The most important is the ability to monitor the changes going to live. A good start is something like NewRelic which is easy to install on production boxes and gives a good feeling for whether your application is healthy or not.
When talking about automated tests, my preference is to test the most important part of your journey. For an ecommerce site this would be placing an order as a guest. Then the second test might be placing an order as a signed in user. My maximum for these kind of tests (if you are thinking Selenium) is around 5 at the most. Once you have these tests in your build pipeline you are a step closer to continuously deployment.
Finally having a blue, green setup for deployment is essential, so if the monitoring is showing you a change has broken something you can simply revert quickly. Then fix and re-deploy as quickly as possible.
There is obviously a caveat to this, try to start deploying smaller increments to live – ideally one changeset. Then if something goes wrong you know what has broken it.
I don’t propose no Test Driven Development, or no testing.
I’m just proposing that it’s not as hard as you think it is to get to a point where you can continuously deliver software. I consider continuous delivery to be an ability.