4 ms·
If you go the continuous delivery route, I think you will need a way to canary a pending release. I also think you need really good production monitoring soluti
by swframe2 9y ago
If you go the continuous delivery route, I think you will need a way to canary a pending release. I also think you need really good production monitoring solution that can trigger a rollback to the previous release automatically (assuming you have a way to mark a release as "appropriate to automatically rollback").
The amount of tests you need to automatically release "bulletproof" code is staggering. In one successful example, I noticed there were about 10k tests that took about 30 minutes to run (before the code could be checked in). I would think you need to use TDD to feel confident that your tests are good enough.
The other aspect of CI/CD that bugs me is the dramatic increase in complexity. I thought KISS and Occam's Razor would kill the CI/CD efforts. Moving to weekly release seems a lot simpler and I doubt most teams need to release changes much faster than that. With CI/CD, if you have several components and lots of shared code then managing which component to update given dozens of changes affecting different components is a nightmare. Unfortunately, once you start using CI/CD, there is no going back (often for political reasons).
- matthewmacleod 9y agoThe other aspect of CI/CD that bugs me is the dramatic increase in complexity. I thought KISS and Occam's Razor would kill the CI/CD efforts. I’m honestly really surprised to hear that view. If anything, I’ve found it much simpler. For some insight as to how my current team works: - feature development happens on git branches - all pushes to github are automatically tested on CI, built, and produce a deployable artifact - any artifact can be deployed to a fully-featured staging environment - Builds from the master branch are automatically deployed to production - the product owner is responsible for acceptance testing the feature in the staging environment - a PR into the master branch is raised for code review - when this branch is never, after product owner approval, the feature is live. It’s delightfully simple and entails no release schedule. Large features can be placed behind feature flags and allow other teams to activate feature for user groups as required. Honestly I can’t imagine going back to releases ever again.
- rev0lutions 9y agoKISS and Occam's razor?
- swframe2 9y agoKISS = "Keep It Simple Stupid" https://simple.wikipedia.org/wiki/KISS_(principle) https://simple.wikipedia.org/wiki/KISS_(principle) Occam's razor https://simple.wikipedia.org/wiki/Occam%27s_razor https://simple.wikipedia.org/wiki/Occam%27s_razor Suppose there exist two explanations for an occurrence. In this case the simpler one is usually better. (I was trying to say "If there are two ways to release a product, the simpler way should be better".)
- jonhohle 9y agoIt sounds like your software might be too complex and may benefit from being broken up into smaller, independent components. With a reasonably well-defined, decoupled system, you should be free to run a targeted test suite without much concern for affecting consumers (assuming you're not breaking contracts). Moving to CD(eployment) significantly reduced release complexity and increased quality of several of the system I owned in the past (which handled thousands of TPS and were affected millions of customers and dollars, globally, per day). In fact, I preferred starting with a CD pipeline to kick off new services from the start so from the very first check-ins (even before any tests were written), the deployment automation was in place and all changes were going to the latest stage we felt comfortable with at the time (often production, since initially there would be no consumers). That sets an expectation from the start that when developers peer review and merge, their code is going to production.