2

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

Improve this question

1 Answer 1

Reset to default
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.

Improve this answer
2
  • 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
    May 15 at 21:08
  • 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
    May 16 at 5:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.