SAFe Practice Tips Part 2: Continuous Delivery

This is the second part to the CI/CD blog series where I discuss continuous integration, delivery & deployment, and the differences between them but also how they relate to one another. You can find the first part, discussing Continuous Integration here. In this blog we will discuss Continuous Delivery (CDel).

Full automation

CDel builds on top of CI by adding release automation to the teams’ responsibilities. The ultimate goal is full automation of the release process so that it only takes a 1-touch operation to release. In doing so, our release scripts become part of our source code. The process that moves software from source control to deployment through environments is called a build pipeline.

CDel is not just about deploying applications to environments, it’s also about ensuring consistency of deployments too. Teams may automate the creation of environments and infrastructure as part of the release process, which leads to collaboration with Operations, who in turn will change the way they work to accommodate CDel.

The automation of releases can be very difficult, especially with older applications. It is much more progressive for a team to refactor or re-architect their application to make it easier to deploy than it is to constantly struggle to achieve release automation. Release automation becomes a non-functional requirement of our application, which is why CDel is an approach to delivering software.

To verify automated releases, a suite of automated acceptance tests should also be used to test each deployment, and these will be run as part of the release process. These tests are not limited in scope to application functionality but should test all aspects required to determine that the release is potentially shippable. Any test excluded from the acceptance test suite should be tested manually.

Continuous delivery requirements

The following are required for Continuous Delivery:

• • Continuous integration (CI)
  • Release automation is the teams’ responsibility
  • A build-pipeline capable CI server
  • A suite of automated acceptance tests

• Collaboration with operations
• The ability to create/configure environments on demand
• The ability to automatically release your application
• Production-like test environments & test data
• All release artifacts in version control

When a team moves from practicing CI to practicing CDel or CDep (Continuous Deployment), operations and architecture must become heavily involved, and the scope of the teams’ work is broadened to include the release process and automated acceptance test. Teams practicing CDel must decide the breadth of their acceptance tests, but this approach still allows for a manual testing phase before release.

An existing application may be able to be automatically released using this sort of approach – it may be that the major effort is in the environment and release automation. Using this approach, an application can be held until certain features are finished before it is released. This could be one sprint, or a whole PI. Generally speaking, the larger the release the higher the risk.

Ideally a team will move to such frequent releases that the release is no longer an event. This is where a Continuous Deployment approach will be used.

I hope this blog post has helped to give you a better understanding of Continuous Delivery and how the teams scope must expand to enable it. Keep an eye out for the next blog in this series which will discuss Continuous Deployment.