<p>It's pretty common to have a difference at the code level, for example building off a branch of the code. However, the build and deployment pipeline ought to be the same.</p>
<p>The issue around what code goes live should be handled pre-build with a branch, or as part of the build process. There should't be any differences after this (i.e. it shouldn't be used as an opportunity to expedite a fix faster as that's where the trouble starts).</p>
<p>Ideally, you wouldn't even branch for this - you'd trust your feature flags. However, a certain amount of pragmatism helps at the 10,000 employee level.</p>

CC BY-SA 4.0
2023-05-15T21:08:57.753Z
Thank you that is helpful. The build and deployment pipeline are the same i.e. the code is committed to the repo test branch and that has a pipeline that builds and deploys the app to a test environment. Same for pre-prod and prod. 

The bit that we are stuck on is what if a CVE comes in for one of our dependencies but we are halfway through adding some features to a release train. How do we skip that fix to the front of the queue and deploy the app without releasing all the half built things prematurely.
lindsaymacvean
CC BY-SA 4.0
2023-05-16T05:10:52.183Z
The ideal answer is to work in smaller batches and deploy more often. You can then respond to a problem like a CVE faster without expediting the fix. Otherwise, you have to take a branch that represents "what's currently live" to make the fix and ensure it makes it into other branches (sounds okay, but gets messy).
Fenton
CC BY-SA 4.0
2023-05-15T12:36:00.187Z
2023-05-15T12:36:00.187Z
Fenton
<p>Working with a larger corporate. They are planning on opening a second pipeline for a hybrid mobile app. This second pipeline will be for hotfixes straight into production. My gut feeling is that this is a bad smell and what should really happen is more shift-left, better code quality/testing and feature flagging hiding the code/features that are not yet ready. This keeps one pipeline and means its the same process to release for features as it is for hotfixes.</p>
<p>Their concern with this approach is that releasing half finished code (even hidden) into production could open them to liability/bad pr from people who find it and interpret it the wrong way. I am thinking we run the compilation process so that the feature flags stops code even going into the production version of the app.</p>
<p>My question is, do other pragmatic people with real experience in a large (~10k employees) corporate use a second pipeline? If you don't have a second pipeline, what is the best evidence to build a case for change (I tried looking in the devops handbook and doing some googling but no really authoritative statements I could find)?</p>

<continuous-integration><continuous-deployment><build-pipeline><pipeline><operations>
Best practice multiple pipelines into production
lindsaymacvean
# Best practice multiple pipelines into production

(Asked by: username_0 on 2023-05-15)

Working with a larger corporate. They are planning on opening a second pipeline for a hybrid mobile app. This second pipeline will be for hotfixes straight into production. My gut feeling is that this is a bad smell and what should really happen is more shift-left, better code quality/testing and feature flagging hiding the code/features that are not yet ready. This keeps one pipeline and means its the same process to release for features as it is for hotfixes.

Their concern with this approach is that releasing half finished code (even hidden) into production could open them to liability/bad pr from people who find it and interpret it the wrong way. I am thinking we run the compilation process so that the feature flags stops code even going into the production version of the app.

My question is, do other pragmatic people with real experience in a large (~10k employees) corporate use a second pipeline? If you don't have a second pipeline, what is the best evidence to build a case for change (I tried looking in the devops handbook and doing some googling but no really authoritative statements I could find)?

**Tags:** continuous-integration, continuous-deployment, build-pipeline, pipeline, operations


---

## 1 answers

### Answer by username_1 on 2023-05-15. Score: 1

It's pretty common to have a difference at the code level, for example building off a branch of the code. However, the build and deployment pipeline ought to be the same.

The issue around what code goes live should be handled pre-build with a branch, or as part of the build process. There should't be any differences after this (i.e. it shouldn't be used as an opportunity to expedite a fix faster as that's where the trouble starts).

Ideally, you wouldn't even branch for this - you'd trust your feature flags. However, a certain amount of pragmatism helps at the 10,000 employee level.

> **Comments:**
> **username_0**: Thank you that is helpful. The build and deployment pipeline are the same i.e. the code is committed to the repo test branch and that has a pipeline that builds and deploys the app to a test environment. Same for pre-prod and prod.   The bit that we are stuck on is what if a CVE comes in for one of our dependencies but we are halfway through adding some features to a release train. How do we skip that fix to the front of the queue and deploy the app without releasing all the half built things prematurely.  
> **username_1**: The ideal answer is to work in smaller batches and deploy more often. You can then respond to a problem like a CVE faster without expediting the fix. Otherwise, you have to take a branch that represents "what's currently live" to make the fix and ensure it makes it into other branches (sounds okay, but gets messy).  

---

