大きな変更が発生している間、CI / CDプロセスが中断されるのを防ぐ方法は？
これは手順の詳細であり、おそらく哲学的問題です。
私が所属している開発チームは、同じ製品で作業するスクラムチームまたはスクワッドに分かれています。場合によっては、これらのチームのいずれかが、コア機能またはコンポーネントの改造、データベースのアップグレードなど、「大きな」何かに乗り出す必要があります。
チームが採用している現在のアプローチは、現在のリリースをロックダウンし、そのチームの作業のみをマージしてナイトリービルドにすることです。他のチームは依然としてスプリントの目的を追求していますが、チケットをナイトリービルドにマージすることは禁止されているため、チケットの資格を得ることができません。基本的に、「大きな」変更を除いて、他のすべての作業はブロックされます。
状況を処理または少なくとも管理するためのオプションは何ですか？より効率的な方法で？また、分隊は地理的に離れていることにも注意してください。
これは、Hewlett Packardがソリューションを再設計したときにまさに抱えていた問題です。あなたはそれについて読むことができます この本で （ ショートバージョン ）。
基本的に、変換中に古いバージョンと新しいバージョンの両方が共存できるように移行を設計する必要があります。これの問題は、物事がより複雑になり、より多くの努力が必要になることです。そして、そのような段階的な移行を可能にするために適切なアーキテクチャを必要とする場合がよくあります。しかし、それは開発者や建築家が認めようとするよりも頻繁に可能です。
本当に、大きなアーキテクチャの変更を取り、それを小さな段階的な変更のチェーンに変換することは、アジャイルのコアであり、私はエンジニアリング、スキルセットと言えます。ソフトで段階的な移行のコストが増加する可能性があるため、問題ないことを彼らに思い出させる必要があります。
変化が異なると変化をより緩やかにするために異なるアプローチとソリューションが必要になるため、具体的な答えを出すのは困難です。多くの場合、古いバージョンと新しいバージョンの両方を同時に持つことがよくあります。これらのシナリオでは、下位互換性もよく見られます。機能フラグも良い考えです。
関連：