Согласование непрерывного развертывания со строгими политиками управления изменениями

Мне любопытно, как другие строят свои практики DevOps в строгой среде управления изменениями, такой как процесс утверждения консультативного совета по изменениям (CAB) .

Я понимаю, что автоматизация может улучшить ваш процесс аудита, гарантируя более строгий, доказуемый и повторяемый процесс. Но кажется, что в такой ситуации непрерывное развертывание более или менее невозможно. Поскольку одобрение изменений может занять неделю или более, вы теряете возможность быстрого и частого развертывания. Какие шаги вы предпринимаете для работы в этих процессах, кроме простой отправки запросов на изменение и ожидания одобрения?

Если вы должны придерживаться процесса изменения, вы будете ограничены в соответствии с ограничениями процесса изменения, полная остановка. Если изменения должны быть утверждены до развертывания, вы не можете выполнять непрерывное развертывание. Если утверждение занимает много времени, вы не сможете быстро его развернуть. Не существует обходного пути, при котором вы оба можете следить за процессом и не подвергаться его влиянию. Это стоимость отслеживания процесса изменений, и стоит обратить внимание заинтересованных сторон в этом процессе.

Не все потеряно ... вы можете максимально автоматизировать вокруг этого процесса, для того , чтобы свести к минимуму ошибки; все шаги CD, кроме связи между генерацией стабильного артефакта и развертыванием этого артефакта в производстве. Эта связь будет заменена каким-либо пользовательским вмешательством (кнопка, команда CLI и т. Д.) Или связана с записью подтверждения (например, когда заявка на изменение будет переведена в состояние «одобрено», отключите связанное развертывание). ). Вам просто нужно выжать из нее как можно больше преимуществ, следуя при этом обязательному процессу, с которым вы столкнулись. Конечно, это не ускорит процесс согласования.