Release-based deployments are sort of nice in the sense that you plan, draw a line, prepare stuff and release one or more components at the same time. It however stalls feature deployments a lot (e.g. a nice feature can be implemented in say a day but the release is sheduled in a month). It also gives way to out-of-order releases to please the business. Agile (CI/CD) aims to alleviate some of these problems.

Prerequisites

As part of the transition process, one has to establish a stack. In my case, it's formed of:

  • Jenkins,
  • Docker,
  • Helios and
  • Rundeck ( this we aim to retire)

In order to transition to CI/CD, we need to build a pipeline (be it implemented as a series of jenkins jobs, a jenkins pipeline or a combination of the two). A relatively simple approach can be:

  1. git checkout/pull
  2. compile
  3. test
  4. build e.g. jar/war
  5. deploy components (e.g. nexus)
  6. build docker images (if needed)
  7. build helios jobs (if needed)
  8. mark successful builds (e.g. tag release)
  9. auto-deploy to dev (if successful)
  10. be able to select a destination (dev/test/prod)
  11. get list of available versions
  12. select version to promote
  13. allow user to select different version (optional)
  14. deploy selected version to the destination environment

This approach can always be improved with e.g. using pull requests, but we can already use the approach as a proof of concept to speed up deployments to dev and inform developers if something goes wrong.

HTH,