Other Considerations

Continuous delivery

The phrase “CI/CD” has become common in the software industry, which implies that organizations are routinely doing both continuous integration and continuous delivery. However, we do not see most organizations practicing the “CD” part of CI/CD. DZone Research reports that while 50% of organizations believe they have implemented CD, only 18% actually meet the textbook definition (DZone Research, 2015).

CI is a prerequisite for CD, so we have found that it makes sense to get CI right first. Despite much recent attention on environments like Netflix and Amazon, which deploy hundreds of times per day, environments that deploy weekly, monthly, quarterly, or less often are common and will be for the foreseeable future. You might be working on embedded systems, on combined hardware/software products, on regulated systems, in an enterprise space, or on legacy systems that can’t accept frequent releases. However, you can still benefit from automating the repetitive parts of CI. You can also benefit from the discipline associated with continuous delivery, even if continuous deployment will never be desirable.

This is an area where the concept of the Agile boundary is useful—you might have good reasons to draw your Agile boundary so that it includes CI but doesn’t include CD.

The Agile boundary applies to external customers as much as it does to internal development organizations. We’ve worked with organizations that have developed the ability to release software externally much more frequently than they actually do—they release less often because their customers have requested that. Their customers are on the other side of the Agile boundary. They still deliver frequent internal releases for the sake of obtaining the benefits described in this chapter.