Defining Continuous Deployment
First of all, there’s the somewhat pedantic fact that deployment does not imply release. As we say in the book, you can continuously deploy to UAT - no big deal. What makes continuous deployment special is deploying every change that passes the automated tests (and optionally a short QA gate) to production.
Source: continuousdelivery.com
Source: crisp
Is It Worth the Time?
Source: xkcd
Deploying to Production != Release
Just because the code is deployed to production that does not necessarily mean that a new function is released. The recommended pattern for this are Feature Toggles.
Feature Toggles
A feature toggle, (also feature switch, feature flag, feature flipper, conditional feature, etc.) is a technique in software development that attempts to provide an alternative to maintaining multiple source-code branches (known as feature branches).
Continuous release and continuous deployment provide developers with rapid feedback about their coding. This requires the integration of their code changes as early as possible. Feature branches introduce a bypass to this process. Feature toggles bring developers back to the track, but the execution paths of their features are still “dead” if a toggle is “off”. But the effort is low to enable the new execution paths just by setting a toggle to “on”.
The technique allows developers to release a version of a product that has unfinished features. These unfinished feature are hidden (toggled) so they do not appear in the user interface. This allows many small incremental versions of software to be delivered without the cost of constant branching and merging.
Source: Wikipedia
Justification Of The Choices Made
- The benefits of manual acceptance test does not outweigh the increased dependencies that build up in the staging environment and the effort involved in doing the manual tests
The Other Alternatives That Were Not Chosen
- Continuous Delivery