There’s an important and confusing detail in the CD part which, among other things, allows the techniques and benefits from Ady’s article and the comments to apply in more situations.
As Ady says, there are two meanings of CD:
- Continuous delivery = getting a release candidate, i.e. code that you could put into production if you wanted to
- Continuous deployment = putting the release candidate into production
It’s easy to default to thinking that all software is web-based Saas, with the economics, constraints etc. that go with that. However, you might be working on software that e.g. controls a steel plant. In that context you can’t push new code into production several times a day (like e.g. Amazon does) because there’s a physical production line that must be kept running.
However, even though you can’t do continuous deployment to the steel plant, you could still do continuous delivery. That means, among many other things:
- There’s always a version of the software that could be deployed
- Changes to a pre-production test or staging environment can still be made often, in small batches
So even if you can’t deploy more often than once a year (for instance), you can still be updating a staging environment frequently, via helpful automation as described in Ady’s article. As with all tools and approaches, you need to work out how to apply CI/CD/CD to your context, to get as many of its benefits and avoid as many of its drawbacks as possible.