*This post is part of the series ‘SAFe Practice Tips’, which aims to offer helpful advice to anyone using SAFe.
This is the final 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 and second part, discussing Continuous Integration and Continuous Delivery. The last practice we discuss is Continuous Deployment (CDep).
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.
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
- 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. Radtac offer a number of courses to support these practices, including the Certified Scrum Developer and DevOps Foundation courses. We shall shortly be launching new Scaled Agile courses aligned to these practices too.
Don’t miss the last part to Darren Wilmshurst's SAFe Practice Tips Series - sign up to blog notifications.
Want to build your knowledge on SAFe , why not check out one of our SAFe training courses.