How we develop software
Part 4: Continuous Deployment
From our point of view, there is only one right time to roll out a new feature to the server: when it is ready. Not sometime, but right away. Why wait? The work is done, the feature is tested and the developer, product owner and customer agree that it adds value to the site. So go for it.
Of course, this only works if deploying it to the server doesn't create a huge overhead. But this is exactly what we achieved in part 3 of this series: we can fully automatically assemble the code including all dependencies and deploy it to a server. Bingo!
Now we could sit back, sip a cup of coffee and check off another marketing buzzword. But that's not how we work.
Harvest what we sow!
In the previous part of this series, I explained that our build chain doesn't really care which server we deliver the site to, as long as it's accessible and we have all the information we need.
At the same time, for internal QA and for the review meeting with the client, it would be great to have an environment where we could discuss, test, and have individual features approved.
And of course, we built just that: Our review server.
As soon as a developer submits work on a feature to our version control system, our buildchain goes off and builds for all it's worth. In addition to the many tests to see if the developer has followed the coding guidelines and the code is clean, it now builds a standalone instance that differs from the current production site in only one detail: The feature that the developer has just worked on.