<p>The &quot;D&quot; in CI/CD means different things to different people, either delivery or deployment. For both groups, it rarely means release everything immediately to production. For the delivery group, the output of CI/CD is an artifact that <em>can</em> be deployed. For the deployment group, there are typically gates in pipelines with either automatic or manual checks before deployment happens. Automatic gates include the unit tests, CI tests, but also things like canary releases with monitoring of key metrics.</p>
<p>Manual approvals in Jenkins involve adding an <a href="https://www.jenkins.io/doc/pipeline/steps/pipeline-input-step/" rel="nofollow noreferrer">input step</a> to your pipeline. E.g.</p>
<pre><code>input([message: &quot;Ready to continue?&quot;])
</code></pre>
<p>In my experience, having various stalled pipelines waiting for user approval is fairly common. I often include timeouts to clear out stale prompts, and sometimes I configure old prompts to automatically cancel with a more recent pipeline is approved to reduce the workload on users. If you do the latter, you may want to have a separate pipeline for backout/revert jobs since that would otherwise being a new job that gets promoted to production in an emergency and aborts all the other work in progress.</p>
<p>I still like to separate my builds from deploys with separate pipelines. It gives developers better feedback with their CI pipelines of what's working. Then the deployment team picks from a list of automatically queued up deployment jobs that were automatically triggered from those successful CI jobs.</p>

CC BY-SA 4.0
2020-08-29T14:35:05.353Z
2020-08-29T14:35:05.353Z
BMitch
<p>The &quot;naive&quot; CI/CD approach could work.  I think a good practice here might be something like feature toggles.  The same code would be deployed, and make it to prod, but you would choose when to turn that feature on or off based on the feedback of the customers.</p>
<p>I'm actually surprised so many people think that they &quot;need&quot; a manual step, or &quot;need&quot; to push their branches to some UAT or QA environment in order to properly test things.  They literally, invent some contrived process to solve their problems, but the real problem is that this methodology, according to any docs, does not scale or work well in an enterprise setting.</p>

CC BY-SA 4.0
2024-04-08T17:05:05.673Z
2024-04-08T17:05:05.673Z
Vaibhav Kumar
<p>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.</p>
<h3>The Scenario</h3>
<p>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 <code>UAT</code>) before it is released to production (<code>PROD</code>). This means that releases to <code>PROD</code> happen on &quot;off weeks&quot; 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 <code>PROD</code>.</p>
<h3>Question</h3>
<p>Clearly the <em>naive</em> CI/CD pipeline approach doesn't work here since most code changes aren't expected to make it straight down a pipeline to <code>PROD</code>. In light of this, <strong>what is the best approach here for a team that is still interested in utilizing pipelines as much as possible?</strong></p>
<h3>Some Thoughts</h3>
<ul>
<li><p>We could use a single pipeline with manual approval steps prior to the <code>UAT</code> portion and then again prior the <code>PROD</code> portion. 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.</p>
</li>
<li><p>We could use 2 pipelines. One is totally CI/CD with <code>DEV</code> and <code>STAGING</code> environments. 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 <code>UAT</code> and <code>PROD</code>.</p>
</li>
</ul>
<p>If it's relevant, jenkins would be the pipeline of choice.</p>

<jenkins-pipeline><build-pipeline>
CI/CD pipeline with manual advancement?
CorbinMc
# CI/CD pipeline with manual advancement?

(Asked by: username_0 on 2020-08-28)

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 Scenario

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 `PROD`.

### Question

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?**

### Some Thoughts

* We could use a single pipeline with manual approval steps prior to the `UAT` portion and then again prior the `PROD` portion. 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 `DEV` and `STAGING` environments. 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 `UAT` and `PROD`.

If it's relevant, jenkins would be the pipeline of choice.

**Tags:** jenkins-pipeline, build-pipeline


---

## 2 answers

### Answer by username_1 on 2020-08-29. Score: 2

The "D" in CI/CD means different things to different people, either delivery or deployment. For both groups, it rarely means release everything immediately to production. For the delivery group, the output of CI/CD is an artifact that can be deployed. For the deployment group, there are typically gates in pipelines with either automatic or manual checks before deployment happens. Automatic gates include the unit tests, CI tests, but also things like canary releases with monitoring of key metrics.
Manual approvals in Jenkins involve adding an input step to your pipeline. E.g.
input([message: "Ready to continue?"])

In my experience, having various stalled pipelines waiting for user approval is fairly common. I often include timeouts to clear out stale prompts, and sometimes I configure old prompts to automatically cancel with a more recent pipeline is approved to reduce the workload on users. If you do the latter, you may want to have a separate pipeline for backout/revert jobs since that would otherwise being a new job that gets promoted to production in an emergency and aborts all the other work in progress.
I still like to separate my builds from deploys with separate pipelines. It gives developers better feedback with their CI pipelines of what's working. Then the deployment team picks from a list of automatically queued up deployment jobs that were automatically triggered from those successful CI jobs.


---

### Answer by username_2 on 2024-04-08. Score: 0

The "naive" CI/CD approach could work. I think a good practice here might be something like feature toggles. The same code would be deployed, and make it to prod, but you would choose when to turn that feature on or off based on the feedback of the customers.

I'm actually surprised so many people think that they "need" a manual step, or "need" to push their branches to some UAT or QA environment in order to properly test things. They literally, invent some contrived process to solve their problems, but the real problem is that this methodology, according to any docs, does not scale or work well in an enterprise setting.


---

