Continuous delivery is characterized by set of capabilities that allow making changes to production safely quickly with sustainable pace. When implemented properly it improves delivery performance, quality, culture, reduce burnout and deployment pain.
- Build-in quality – Quality is a part of a culture supported by tools and people where issues can be detected quickly, so they are cheap to detect, resolve and fix.
- Small batches – Allow delivering measurable business outcomes quickly for the small part of target market. Small batches enable fast feedback that allow teams to correct course. They might cause small overhead but save work that delivers zero or negative value.
- Automate repetitive task – People solve problems, computers perform repetitive tasks. Things like regression testing or software deployments should be continuously simplified and automated.
- Relentlessly pursue continuous improvements – Improvements should be part of every day work. Never settle for status quo.
- Everyone is responsible
When implemented correctly, the process of releasing new versions to users should be a routine activity that can be performed on demand any time.
Configuration management – Tests, configuration of environments and software should be part of version control. Any change to environments should be applied by automated processes from version control.
Continuous integration – changes to software should be applied in small batches by means of short-lived branches that represent less than a day of work. Each commit to the master branch should trigger build & test process. Short lived branches reduce need for code freeze while long-lived branches discourage refactoring and intra-team communication.
Continuous testing – Testing should be integral part of software development. Developers should be able to run tests on their machines without external dependencies.
Fully automated tests, configuration and deployment reduces deployment pain and reduces team burnout. Including application and system configuration in version control has especially big impact on delivery performance.
Teams that scored high on continuous delivery also identified more strongly with the organization. They achieved higher delivery performance (lead time, MTTR, deployment frequency), decreased change failure rate and embraced generative, performance driven culture.
Developers accept responsibility for global outcomes such as quality and stability more likely when they are given:
- Tools to detect problems when they occur
- Time and resources to invest in their development
- The authority to fix problems right away
How to measure quality?
There is no single definition of quality – it means different things for different people. However we can measure proxy variables for quality
- How team building the product perceive the quality
- Percentage of time spent on rework on unplanned work
- Percentage of time spent on fixing defects identified by end users
Unplanned work indicates failure to build-in quality in your process and product.
Research shows that high performers spend 21% of their time to unplanned work while low performers need to sacrifice 27% of their time for the same purpose.
Team should strive to do the right thing the first time by improving the quality of the service they provide.
Automated tests should be reliable. Failed test should indicate real defect, while passing test guarantee correct behavior. Unreliable tests should be removed or moved to separate quarantine test suit.
Test should be developed and maintained by development team. Outsourced tests and tests created by QA team do not correlate to development performance.
Developers should have access to adequate data that allows them to run tests on their machine.