At the heart of any software delivery effort should be the deployment pipeline, widely popularized by Jez Humble and Dave Farley in their groundbreaking 2010 book, Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation.
A deployment pipeline helps create a fast flow of change by ensuring that all software changes use the same "route to live." However, many organizations see deployment pipelines—and continuous integration/continuous delivery (CI/CD) more generally—as just a set of automation scripts.
But limiting your view misses out on significant advantages from CI/CD, including autonomy, loosely coupled architecture, limited cognitive load, reduced dependencies, and using the pipeline as a way to visualize the value stream.
CI/CD is really a key organizational enabler for fast flow. Combining core CI/CD principles with the patterns and practices from Team Topologies: Organizing Business and Technology Teams for Fast Flow, a book I wrote with Manuel Pais, can help produce software and organizational architectures that promote fast flow and therefore greater business agility.
1. The CD deployment pipeline is the value stream
The book Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, by Nicole Forsgren, Humble, and Gene Kim demonstrated beyond doubt that CD is essential for achieving high organizational performance in software delivery. In fact, the use of CD as a set of practices is a predictor of high organizational performance.
A key concept in CD is the deployment pipeline, so here is the definition of deployment pipeline from Humble and Farley's book, Continuous Delivery:
A deployment pipeline is an automated manifestation of your process for getting software from version control into the hands of your users
So, crucially, the deployment pipeline is not just about building or testing the software. The deployment pipeline should be the only way that software reaches production. There should be no behind-the-scenes activities; all software and configuration changes should go via the deployment pipeline.
These days, most organizations should use a CI/CD tool from a vendor, rather than building one in-house. Since the CD book was published in 2010, there have been huge improvements in CD tooling, such that, if you choose a good tool, it will help your organization take advantage of good practices, such as value stream management (VSM).
Treating aspects of an organization in terms of value streams can really help align business decisions and software with the natural flows of change, which in turn helps to speed up the rapid and safe delivery of changes.
In fact, a good deployment tool will help to emphasize that the pipeline is part of the value stream for that part of the organization. Some deployment pipeline tools even provide a value stream map view, which shows end-to-end flow of changes, including execution and wait times, essential for value stream analysis.
2. Good deployment pipelines highlight dependencies
A typical high-performing organization will have many separate deployment pipelines—one for each separate "thing" that can be deployed: a service, an application, supporting infrastructure, and so on. Each deployment pipeline should also help to highlight the dependencies within that value stream.
Dependencies are a necessary part of modern software delivery, because a single team cannot expect to build everything itself; the team and its software always depend on other resources.
However, it's important to distinguish among different types of dependencies. There are two different, key dimensions of dependencies:
Software versus team dependencies
Direct software dependencies—things such as libraries, APIs, and platforms, trackable via lock files or package specs
Team dependencies—where one team depends on another team to do some work before the first team can progress
Direct software dependencies are relatively straightforward to manage these days, especially if the dependency uses a versioning scheme (such as SemVer, or semantic versioning) that provides clear signals about suitability. These kinds of dependencies are normally tracked by version configuration files stored in version control and so are easily surfaced via the deployment pipeline.
Team dependencies currently take a bit more manual effort to track, but thankfully there are some simple approaches that work well. I put together the Team Dependencies Tracking template with co-author Manuel Pais to help organizations explore how to track team dependencies.
The free-to-use template is itself based on an example shared by people working at Spotify in 2012, which has been tried and tested for nearly 10 years.
The nature of the dependencies
The second important thing to distinguish is blocking versus nonblocking dependencies. A blocking dependency is one where the first team must wait on another team to do some work before the first team can progress. This clearly slows down progress and hurts fast flow.
Contrast that with a nonblocking dependency, where the first team simply consumes something "as a service" from the second team. In this case, the first team does not need to wait on the second team at all because the dependency (perhaps a code library, a service, an API, some data, some content, etc.) is ready to use in a self-service manner.
Figure 1: Blocking versus nonblocking dependencies. Source: Team Topologies
3. Rapid deployment feedback avoids context switching
A hugely valuable outcome from using a good deployment pipeline is that the engineers get fast feedback on code changes. As soon as code changes are committed to version control, the deployment pipeline is triggered and runs some rapid tests. This creates a virtuous circle feedback loop, where engineers gain confidence in their changes by proving validity against a test suite, encouraging them to commit changes more frequently and encouraging smaller, more understandable changes.
In effect, if the deployment pipeline enables rapid builds and tests, teams can lean on the tooling to make their workflow much more effective. Engineers become familiar with producing many small changes incrementally, using the deployment pipeline tooling to do the heavy lifting around testing and difficult changes.
In its excellent 2020 State of Software Delivery report, pipeline-deployment tool vendor CircleCI found that half of the 11 million workflows it measured finished in under four minutes, and 75% of workflows finished in under 11 minutes. These durations are short enough to run the workflows many times per day, encouraging engineers to focus on a series of small changes rather than batching all their changes into fewer larger blocks.
Not only are smaller changes easier to diagnose and debug, but because the changes are smaller, the test suites can be smaller too; only the changed code and immediate integrations need retesting. This helps to avoid "context switching" in engineering teams: They retain their focus on the task at hand rather than jumping to another task while the (very slow) build and test process runs.
Engineering teams that retain their focus on the business domain are likely to produce fewer coding mistakes compared to teams that regularly context-switch waiting for slow test suites to complete.
Retaining focus also limits cognitive load, which further improves code quality. Rapid deployment pipelines produce better, more bounded software.
4. CI/CD helps with re-architecting software
Achieving a fast flow of business changes needs aligned software architecture and system architecture. But what kind of architecture is compatible with a fast flow of change and how can organizations achieve that?
The research in the Accelerate book specifies that a loosely coupled architecture allows for scaling. One way to move toward a loosely coupled architecture is to use the insights and signals from deployment pipelines to drive changes in responsibility boundaries for teams and software.
Use the deployment pipeline to identify different kinds of dependencies (see above). Once the different kinds of dependencies have been identified, it is important to have directed conversations about these dependencies.
The aim is to identify dependencies that are hurting a fast flow of change. To use terminology from Team Topologies, instigate a period of collaboration between the two teams on either side of the dependency to discover a better boundary around the dependency.
Techniques such as independent service heuristics and domain-driven design can really help to discover better boundaries that align to the streams of change. This in turn helps evolve the business and software architecture to become more nimble and fast-flowing.
The rapid feedback from CI/CD deployment pipelines helps with the code refactoring process at a low level and also helps to keep the resulting software decoupled. This happens by having separate deployment pipelines for separately deployable things (services, apps, data, etc.). All this is essential for fast flow of change.
5. Team ownership increases with good CI/CD
Good CI/CD can also help to increase a sense of ownership within engineering teams. Teams feel empowered when using CI/CD properly; a well-implemented deployment pipeline helps a team own the software, from development all the way to production, enabling rapid changes when needed.
For example, if a zero-day vulnerability is found in a software service, a good deployment pipeline empowers a team to ship a fix for the zero-day within minutes. The team members better understand the nature of the zero-day vulnerability and so can more easily avoid similar problems in future.
Treat CI/CD as a key organizational capability
CI/CD is not simply a tool set or minor detail for modern software delivery. On the contrary, CI/CD is a fundamental approach to software delivery that sets apart the leaders from the followers. By investing in good CI/CD tooling and practices, an organization can discover and sustain ways of working and software designs that encourage a fast flow of change.
In particular, by listening to the signals from a good deployment pipeline, organizations can detect misaligned software and team boundaries and thereby begin to adopt proven practices from Team Topologies and Accelerate, realigning teams and software.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
