複数の環境での機能ベースの展開
私のチームは現在、ソース管理（TFS）、ビルド（チェックイン時にトリガー）、および展開（VSTSリリース管理を使用）にVisual Studio Team Servicesを使用しています。
4つの環境（Dev、QA、Int、＆Prod）があり、コードの変更は、次に展開する前に（環境ごとに異なる関係者によって）サインオフする必要があります。
現時点では、変更がダウンストリーム環境にデプロイされるたびに、アップストリーム環境からのeverythingがすぐに実行されます。これを変える必要があることをチームと経営陣の両方に納得させました。
もちろん、それはそれを変更する方法を理解することは私にあることを意味します。私は機能ブランチを売り込みましたが、TFSを使用しているので、チームはあまりにもヘビー級であることを押し戻しています。私はgitへの移行をフロートしました。これは、管理者が原則的に同意したものの、将来は未定義の時点まで延期されました。
ソース管理をTFSから変更したり、ビルドとリリースをVSTSから変更したり、機能ブランチを実装したりせずに、環境のパイプラインを通じてコードの変更を選択的に推進するにはどうすればよいですか？
更新：コメントに基づいて、私の目標は明らかにあいまいなので、明確にしようと思います。現在のインフラストラクチャ内で、特定の環境にあるものの任意のサブセットを後継者に展開できるようにしたいと考えています。
たとえば、Qt環境にまだIntにデプロイされていない5つのアイテムがあり、テスターが2番目と5番目のアイテム（チェックイン順）にサインオフし、1番目、3番目、4番目のアイテムがサインオフするとします。欠陥があります。 3つの欠陥のある変更をデプロイせずに、2つのサインオフされた変更のみをIntにデプロイするにはどうすればよいですか？
このような環境でこのような問題に直面している場合は、そのような細かさを追求することはお勧めしません。
- QAのためにドロップしたときに、5つの機能を備えた新しいリリースを作成したのには理由があります。ビジネスの人々は、それらが一緒に配信されることを望み、実装は密結合されています。そして、これらの理由は、リリース機能のサブセットが準備されていないという事実の影響を受けません。つまり通常、リリースのサブセットを提供する必要はほとんどありません。
- このプラクティスにより、配信に集中するのではなく、チェーン全体に未完成の機能を積み重ねることができます。ボトルネックを可視化する代わりに、すべてを改善するという誤った衝動を生み出します。
- 通常、機能のサインオフだけでは不十分です。アプリケーション全体をサインオフして次のステージにドロップし、このステージのセットアップも実行する必要があります。機能別機能は、これらの取り組みを倍増させます。
- 特定の厄介な機能のインジェクトトグルを最初から延期する必要がある場合があります。
あなたがするかもしれないこと
- さまざまなサイズのリリースを試して、最大のスループットが得られるものを確認してください。
- 機能の追加から提供までの優先順位を再調整します。
- 「単一のブランチ」に関しては、環境と同じブランチのチェーンが必要になる場合があります。 QAからINTへのマージは、QAがINTの準備ができるすべての基準を通過するまで許可されず、DEVの準備ができていない場合にDEVからQAへの即時マージを意味しません。
現在TFSにあるブランチの数を説明していません。機能リリースのためにあなたが従う現在のプロセスはわかりません。失礼します。以下、同じことを繰り返します。
私ができると思うのは、DEV、QA、INT、PRODの4つのブランチがあることです。 QAブランチは、開発者が完了した作業の品質保証の最後の行にする必要があります。
1つの機能は、DEVブランチでの開発用に複数のチェックインを持つことができますが、QAブランチにマージすると、はすべてマージされ、1つのチェンジセットを作成する必要があります。バグが修正された場合、または変更が要求された場合は、同じ機能についてDEVからQAにさらに変更が加えられる可能性があります。つまり、QAブランチではコード開発が完了し、テストされ、リリースの準備ができている必要があります。
フィーチャーをリリースする場合、QAブランチからのそのフィーチャーのすべてのチェンジセットを、単一のチェンジセットからINTブランチにマージする必要があります。 INT環境で正常に検証されたら、それをPRODブランチにマージし、そこからPROD環境にデプロイする必要があります。ここでは、あなたのINT環境が、機能がデプロイされた後、しばらくの間そこに留まり、製品の安定性をチェックしてから製品化されると想定しています。
ここでは、ブランチからブランチへの選択的なマージが主なアイデアです。また、環境ごとに個別のビルドスクリプトが必要です。
また、ビルドスクリプトは、それぞれのブランチからコードを取得するように構成する必要があります。
VCSにブランチがない場合、目的を達成することは非常に難しく、自動化よりも手動の作業になります。
個別のブランチにコードを保持しない限り、個々の機能のコードを選択的に昇格することはできません。
機能ブランチはできるだけ回避することに同意します。別々の機能ブランチでコードをテストする場合、マージするとコードが正しく機能することがわかりません。また、あるブランチのリファクタリングされたコードが別のブランチのリファクタリングされていないコードと連携しない場合があるため、複数のブランチが共存するとリファクタリングが非常に困難になります。 。
特定の機能のコードを特定の環境から遠ざける必要がある理由を述べていません。コードを遠ざけるのではなく、構成オプションを使用して、各環境で必要に応じて機能をオンまたはオフにしようとします。
また、承認される前に、あらゆる機能について広範な自動テストを実施することも試みます。これにより、将来的に展開される機能のコードによって暗黙のうちに壊れないことが保証されます。