Примирення постійного впровадження із суворою політикою управління змінами

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

Я розумію, що автоматизація може покращити ваш процес аудиту, гарантуючи більш суворий, надійний і повторюваний процес. Але відчувається, що безперервне розгортання є більш-менш неможливим у такій ситуації. Оскільки для затвердження змін може знадобитися тиждень і більше, ви втрачаєте можливість швидко і часто розгортатися. Які кроки ви робите для роботи в цих процесах, крім того, щоб просто надсилати запити на зміни та чекати затвердження?

Якщо ви повинні дотримуватися процесу змін, ви будете обмежені відповідно до обмежень процесу змін, повна зупинка. Якщо зміни повинні бути затверджені до розгортання, не можна робити постійне розгортання. Якщо затвердження триває тривалий час, ви не зможете швидко розгортатися. Немає жодних рішень, за якими можна як слідкувати за процесом, так і на нього не впливати. Це вартість слідування процесу змін, і це варто довести до відома зацікавлених сторін у цьому процесі.

Чи не все втрачено ... ви можете максимально автоматизувати навколо цього процесу, для того , щоб звести до мінімуму помилки; всі кроки CD, за винятком зв'язку між створенням стабільного артефакту та розгортанням цього артефакту у виробництво. Це посилання буде замінено або якимсь втручанням користувача (кнопка, команда CLI тощо), або пов'язане із записом затвердження (наприклад, коли білет запиту на зміну переміщується у стан "затвердженого", відключає пов'язане з ним розгортання ). Ви просто повинні вичавити якомога більше користі від цього, дотримуючись при цьому будь-якого обов'язкового процесу, з яким ви натрапили. Звісно, ​​це не змусить згоди отриматись швидше.