I have a dream…
In my dream each commit a developer does, is automatically tested and deployed to production without any manual intervention, without affecting the users of our app.
Each commit is tested in the CI before it is deployed. Once the CI is green, the deployment starts automatically (including all the commits in that successful build). Version is deployed on a staging server on which smoke tests are performed to validate the version on real data, and only after they pass the version is deployed to production gradually.
This vision is called Continuous Deployment – every developer’s dream…
Why is this dream so appealing to so many in the software industry?
Product wise – We want to expose features to our users as fast as we can and create an effective feedback loop, so our product will get better all the time, quickly.
Development wise – I always like to say that developers are a lazy bunch (in a good way). We don’t like repeating the same thing again and again. Deployments are like that – a repeatable task – before you go you want to validate your version with a suite of tests (usually the same suite is used + the tests you just wrote for your feature) and deploy it (without breaking our product). So we will automate the tests – both intrusive tests (ones that create data) that will run on our CI and smoke tests to validate that the changes did not break the product in production, and automate the deployment process. We only want to be involved if there is a problem in one of these.
In the next couple of weeks I’ll explain the road we are taking in order to bring us closer to this dream.
The next post will discuss the differences between continuous deployment and continuous delivery.