SAFe Practice Tips Part 3: Continuous Deployment

This is the final part to the CI/CD blog series where I discuss continuous integration, delivery & deployment, the differences between them, and how they relate to one another. Be sure to get up to speed by reading the first and second parts in this series, which discuss Continuous Integration and Continuous Delivery (CDel). In this last blog, we will discuss Continuous Deployment (CDep).

Continuous delivery and continuous deployment are similar, but different

While CDel and CDep appear very similar, the full automated end-to-end aspects of CDep may have an impact on the development practices employed by the team, the architecture of your application and infrastructure, the quality and types of automated testing employed, and the monitoring of your application in production. There is no manual UAT phase when practicing CDep so the automated tests must include not only functional tests, but non-functional (including infrastructure) and governance tests (e.g. info-sec).

You may achieve CDel with an automated release process that takes 3 hours and can run overnight. This sort of release would not be suited to a CDep approach as you’re likely to create a traffic jam of releases with a team of any reasonable size. In this case, the process of releasing must be made more efficient so that changes are deployed more quickly. This is easy to recommend but may require significant re-architecting of your application to achieve.

A CDep approach will also impact your teams’ development practices. Because code is checked-in frequently and changes deployed as long as your tests pass, code will move in to production for incomplete features, or for features that may be complete but might have external dependencies (such as marketing campaigns). The use of feature toggles or similar practices should be employed to ensure only the appropriate features are exposed in your application.

Cdep requirements

The following are required for Continuous Deployment:

• Continuous Deployment
• Architecture, development & operations collaboration
• Quantifiable criteria up-front for all acceptance tests including non-functional and governance
• No human intervention or team hand-offs required for release
• Loosely coupled architecture
• Techniques such as feature toggles
• Production monitoring & dashboards

and the following will make Continuous Deployment much easier:

• Acceptance Test Driven Development (ATDD)
• Test Driven Development (TDD)
• Trunk based development
• Cloud based environments
• Containerisation
• Immutable servers
• Feature teams including architecture and operations

The breadth and quality of your automated tests are key to the success of this approach. Practices such as ATDD and TDD are hugely beneficial to CDep, forcing the software to be driven by test criteria.

The greatest enabler for CDep however is the collaboration between architecture, development and operations. Each discipline holds a part of the solution, and it’s only through understanding each other’s perspectives that a smooth flow of application functionality to production can be enabled. When these disciplines are working smoothly together, you have DevOps.

I hope that this series of blogs has explained the differences between the three practices. When used effectively, these practices are a key enabler of feature-flow through the technology value stream.