Change Advisory Board（CAB）承認プロセスなど、厳しい変更管理環境でDevOpsプラクティスを他の人がどのように設計するのか興味があります。
自動化により、より厳密で、証明可能で、繰り返し可能なプロセスを保証することにより、監査プロセスを改善できることを理解しています。しかし、そのような状況では継続的な展開は多かれ少なかれ不可能だと感じています。変更が承認されるまでに1週間以上かかることがあるため、迅速かつ頻繁に展開することができなくなります。変更要求を送信して承認を待つ以外に、これらのプロセス内で作業するにはどのような手順を取りますか？
回答:
変更プロセスを順守する必要がある場合は、変更プロセスの制限に従ってフルストップで制限されます。展開前に変更を承認する必要がある場合、継続的な展開はできません。承認に時間がかかる場合、迅速に展開できません。プロセスに従うことができ、プロセスの影響を受けないようにする回避策はありません。それは、変更プロセスに従うためのコストであり、そのプロセスの利害関係者の注意を引く価値のあるコストです。
すべてが失われることはありません...あなたは、自動化を最大化することができます周りの誤差を最小にするために、プロセス。安定したアーティファクトの生成とそのアーティファクトのプロダクションへの展開の間のリンクを除くすべてのCDステップ。このリンケージは、何らかの種類のユーザー介入（ボタン、CLIコマンドなど）に置き換えられるか、承認の記録にリンクされます（たとえば、変更要求チケットが「承認済み」状態に移行した場合、関連するデプロイメントを起動します） ）。あなたは、あなたが苦しめられてきたどんな強制的なプロセスにも従いながら、できるだけ多くの利益を絞り出さなければなりません。もちろん、承認が速くなることはありません。