TFSでフィーチャ分岐戦略を行う方法

Question

私は、私たちの会社のために新しい分岐戦略を提案しようとしています。私が来たもので説明していないエッジケースがあるかどうかは疑問ですと一緒に。

まず、ここに私たちの現在の分岐戦略です：

各チームは、彼らがチーム3のような独立したQA環境を持っていないので、チーム1と2が非常に小さい、独自の開発ブランチがあります。各チームは変更をメインにマージし、開発ブランチに戻します。

現在、私はチーム3に属しています。置き換えたい戦略は、特にチーム3のセクションの下にあります。私たちはチェンジしてMainからINTへのチェンジセットをQAからDevへ、そしてすべての方法で再びチェンジします。フルブランチマージはなく、私たちが行うすべてのマージは、単にチェリーを選ぶという事実のために、根拠のないマージであると信じ始めています。

私は何をしようとしていることは、私が作ってみたものをここでは、常に桜チェンジを選んで、全体のブランチをマージするに戻る必要性を排除するのです。

長時間実行のために

フィーチャーブランチとdevを作成する機能は、次のリリースで本番運用に向かうバグやユーザーストーリーを主に扱うために使用されます。

QAブランチでの開発は行われていません。テストの準備ができたら、DEVからのQAまでの変更のみをマージします。

すべてのテストに合格したら、Mainにマージし、次のリリースのためにmainのバージョンブランチを作成します。バージョンブランチは、複数のチームがメインにマージするので、修正プログラムを実行するためのクリーンなブランチを持つことができます。

可能な限り機能ブランチとシェルフセットを利用して、チェリーセットをチェリーピックする必要性をなくし、現在行っているマージ競合の狂気の量を減らすことを望みます。

これは効果的な戦略のようですか？

Answer 1

環境ごとの分岐は一般的に悪いことです。一度ビルドしてから、そのビルドを環境のパイプラインに配置する必要があります。コードをマージして新しいビルドを作成するたびに、実行したテストのすべてを効果的に放棄し、最初から開始します。

機能トグルの背後にある開発中の機能を分離します。各機能は「完了」と見なされるため、メインにマージしてQAサイクルを開始します。他のチームは、同じコードベースに対して開発を続けるために、メインからフィーチャーブランチにマージする必要があります。

フィーチャが生産準備が整っていないと判断された場合は、機能トグルでフィーチャを無効にしてから、のファンクションをリリースすることができます。後で機能を統合すると、誰かがバグを逃してしまう可能性が高くなります。機能が統合されているが、無効になっていることを確認すると、少なくとも、無効化された機能が他のものを破壊していないことを証明するのに役立ちます。それは正しく機能しないかもしれませんが、少なくともアプリケーションを壊すわけではありません。

このモデルがチームにとってより自然になるので、機能ブランチを完全に削除して、トランクからすぐに作業できます。

More reading on feature toggles.