| > Nothing against CI/CD and continuous delivery, but the hamster wheel has gotten to a point where we have to release all the time. Corners are cut on everything, and testing is given lip service. Just to call it out: Having CI/CD doesn't mean you have to do all these things, or do scrum. It's imho just good engineering practice. I have it in my side projects, and I've had it at work on a Kanban-driven team (as well as on scrum). It removes disputes over build process (eg, nobody can ever say "well, it complies on my machine"). It is a form of build/deploy documentation. It removes bottlenecks ("only Tom knows how to deploy that service, but he's on vacation") and stupid mistakes ("whoever deployed this last did it wrong and left a bunch of old files around"). I also have found deploying regularly is stress-reducing. For one, with CD the development environment is running the same steps, and we know it works because we do it dozens of times a week. The longer it's been since last prod deploy, the less confident we can be it'll go smoothly, whereas when it gets deployed every few days it becomes a non-event. When something breaks, having only 1 or 3 changes makes it really easy to figure out why. Recovering after a big release with 40 PRs in it is absolutely painful. None of this means you have to release everything on a regular schedule (like a sprint). You can still do long running branches or feature-flag things off, Just try not to go too long without deploying something. |
This is, by far, the most important reason to practice continuous deployment. I've been part of enough of these fire fighting sessions following big releases to see that it's not a sustainable way to deploy software. And yet, I've never been able to convince any boss I've ever had to adopt CD because they're worried it'll introduce more regressions into production.