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

lindsaymacvean
  • 121
  • 3

1 Answers1

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.

Fenton
  • 343
  • 1
  • 2
  • 9