Latest information from Radtac

See all topics

Subscribe to the Radtac blog

Connect with us

Recent Posts

Latest information from Radtac

SAFe Practice Tips: CI/CD Part 2 - Continuous Delivery

25-Apr-2018 14:39:01 SAFe How-To Agile IT CI/CD
Find me on:


 Continuous deployment

*This post is part of the series ‘SAFe Practice Tips’, which aims to offer helpful advice to anyone using SAFe.


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.The next practice we discuss is  Continuous Delivery (CDel).


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.


Continuous delivery


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.


The following are required for Continuous Delivery:


  • 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 artefacts 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 1 sprint, or a whole PI.  Generally speaking, the larger the release the higher the risk.


Ideally a team will move to releases at such frequency 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 of this series which will discuss Continuous Deployment.


Don’t miss the next part of the  CI/CD blog   - sign up to blog notifications.

Want to build your knowledge on SAFe , why not check out one of our SAFe training courses.

 Explore SAFe courses



Rich Levy

Rich Levy

As a Software developer, it is Richard’s responsibility to technically oversee all new and on-going development, maintaining hands-on presence to ensure a laser focus on quality. Richard also takes on-line and resource management responsibilities for development teams, along with ownership of development practices and R&D into new technologies & Agile methodologies. A Sun Certified Java Programmer and Developer, plus a Certified ScrumMaster and Kanban Practitioner. Read more