If you have worked in software in the last ten years, there is a good chance you have heard of the Agile Manifesto and the twelve principles behind it. The Manifesto was written to improve how software gets built, in direct response to the inefficiency of traditional processes and their reliance on weighty documentation.
One of its principles says we should "deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale."
How often does that happen in real life? Not often enough.
More often than not, an engineering organization declares itself agile, adopts a framework (usually Scrum), and goes through the motions: sprints, daily standups, planning and retrospectives. Those steps matter and they almost always help. But the work does not end there. Continuous integration and delivery is one of the most important traits of an agile organization.
Organizations usually fall short on the "deliver working software frequently" part. That leads to stressful releases, engineers on call, working weekends and delayed increments.
What changes when you release often
In our experience, an engineering organization benefits greatly from moving from long release cycles to releasing early and often. The benefits show up in both team satisfaction and software quality:
- Less stress around releases. When releasing is part of the daily routine, it stops being a special event. What did not go out today goes out tomorrow.
- Shorter feedback loops. Release every day and you hear from customers quickly, so you can adjust the product quickly.
- Better code quality. Smaller releases ship less code at once, which lowers the chance of shipping bugs.
- Faster recovery. When a bug slips past QA, a small release makes the root cause easier to find and the fix quicker to ship.
What it takes
Releasing early and often requires some adjustments and investment in your software development life cycle. These practices got us to a cadence of one release per day:
- Run QA in parallel with development. Developers and QA engineers start the feature together, agree how it will be verified, write the test cases, and test it as it is built.
- Automate as many test cases as possible to reduce the effort needed for regression testing.
- Put safeguards in place. We run automated tests on every pull request before it is merged to the main branch.
- Automate the release process so the latest increment can go to production in a couple of clicks.
- Use feature flags and staggered rollouts for more complex features.
- Invest in observability. You must know about a problem before your customers tell you. A tool such as New Relic gives you real-time performance metrics through logs and dashboards, so you can spot irregularities and react.
- Invest in site reliability engineering. Strong SRE engineers make your deployment pipeline more resilient and scalable, and your response to production issues faster.
Our view
We would recommend these principles in nine cases out of ten. But there is no one-size-fits-all answer in software. The most important thing is to assess your needs honestly and choose your route from there.