I am currently learning about CI/CD pipelines for DevOps. I have some practice implementing them in some basic scenarios, but I've recently encountered a slightly more complex scenario and I'm not sure the best way to integrate CI/CD pipelines into this project.
The client and the development team have agreed to work in 2 week sprints. Once the sprint has ended, the client's management team wants 1 week to play with the sprint delivery in a sandbox environment (we'll call it
UAT) before it is released to production (
PROD). This means that releases to
PROD happen on "off weeks" from a sprint perspective, if they happen at all for that sprint. If the customer is unhappy with something they'll ask us to not deploy to prod until the issue is resolved. We still continue working in sprints, we just don't release that sprint to
Clearly the naive CI/CD pipeline approach doesn't work here since most code changes aren't expected to make it straight down a pipeline to
PROD. In light of this, what is the best approach here for a team that is still interested in utilizing pipelines as much as possible?
We could use a single pipeline with manual approval steps prior to the
UATportion and then again prior the
PRODportion. This has the benefit of being a single pipeline, so a single build artifact progresses through the entire pipeline, which seems to be a best practice. The problem is that most things that enter the pipeline are going to get hung up at a manual approval step. Most pipeline runs will then either be stalled or marked as failed.
We could use 2 pipelines. One is totally CI/CD with
STAGINGenvironments. Every two weeks, a separate pipeline would be manually started (or started by some other release mechanism associated with SCM like tagging or merging). This would be in charge of rebuilding, retesting, and deploying to
If it's relevant, jenkins would be the pipeline of choice.