すぐにリリースされる機能を本番リリースに1週間おきにのみ含めるにはどうすればよいですか？

私はかなり大規模なアジャイルチームのソフトウェア開発者です（8人の開発者が1つのコードリポジトリに積極的に変更を加えています）。2週間ごとに、ソフトウェアの新しいバージョンを運用環境にプッシュします。現在のワークフローは次のとおりです。

• 新しいタスクを開始するとき、開発者はメインの開発ブランチ（gitを使用）から「機能ブランチ」を作成し、この新しいブランチで作業します
• 開発者がタスクの作業を完了すると、機能ブランチを開発ブランチにマージして戻します
• 開発者は、開発ブランチをQAブランチにマージします。
• QAブランチからビルドがトリガーされます。このビルドの出力はQA環境に展開され、テスターがテストを開始できるようにします。

テスターがQAブランチにマージされたこれらの新機能の問題を見つけることは非常に一般的です。これは、常に、QA環境にいくつかの新しい機能が含まれていることを意味します-テスト済みでバグのないもの、壊れたものなど。QAビルドが実稼働対応状態になることはまれなので、これによりリリースが困難になります。

これを軽減するために、開発者がリリースの数日前に開発ブランチをQAブランチにマージしないことを意味する「QAフリーズ」を開始しようとしました。QA環境のバグ修正はQAブランチで直接行われ、開発ブランチにマージされます。理論的には、これによりQAの新しい壊れた機能が排除され、QAで既に発生している問題を修正できます。

この「QAフリーズ」の概念は部分的には成功していますが、調整が難しく、QAへのマージが許可されているかどうかについて人々はしばしば混乱します。また、「QAフリーズ」の期限を設定することは困難でした。誰もがフリーズとリリースの間に息を吹き込む部屋のアイデアを好みますが、実際には、デッドラインを尊重するよりも次のリリースで機能を持ちます。

1週間おきにリリースのクリーンビルドを確保するより良い方法はありますか？

これには、発生している問題を引き起こしているいくつかの問題があります。

1つ目は、長時間実行されるQAブランチです。QAブランチとメインラインの両方で複製する必要があるさまざまな作業があるため、開発メインラインと並行して実行時間が長いブランチがあると混乱の原因になる可能性があります。これは、メインラインにマージする必要がある（悪いことではない）QAブランチの修正をチェックインするか、QAブランチにマージされるメインラインにチェックインする（可能性のあるバグのソース）ことを意味します。 。

長時間実行される並列ブランチのもう1つの問題は、ファイルの同期が完全に失われる可能性があることです。決してマージされないコード修正、またはテストされず開発メインラインの一部である本番ビルドに必要な構成。

次に、影響を受ける役割があります。これは、パッケージングの役割（これについては後で説明します）が十分に分離されていないことを意味します。

git-フロー・モデル、リリースブランチは、開発から分岐している（いない開発はQAに合併）とすべての修正プログラムがリリースブランチにチェックインされた後、開発ブランチにマージされ。

分岐の哲学の一部は、Advanced SCM Branching Strategiesにあります（優れた資料と考えています）。これは、各ブランチが担う役割に焦点を当てています。リリースブランチはパッキングの役割を担います。

パッケージングの役割は、多くの場合、蓄積またはより一般的なメインラインの役割と混同されます。意図した開発と保守が実行され、蓄積が完了したら、リリース用のコードを準備します。そのような努力は些細なことではなく、リリースエンジニアのチームと、すでに実行されているもの以外の追加の修正が必要です。パッケージングブランチのポリシーは、パッケージングの役割が示唆するように、メンテナンスブランチのポリシーとは大きく異なります。製品をリリース可能にするために必要な変更のみに対処する必要があります。

• 開発ポイントからリリースブランチへのブランチ。QAがビルドするリリースブランチは、1つのブランチを取得し、開発からマージしません。
  • 一貫した命名とフックを使用してその道を進みたい場合は、リリースブランチへのマージが行われないようにすることができます。
• リリースブランチで修正が必要なものをすべて修正し、それらの変更をメインラインにマージします。
• リリース作業の最後に、リリースブランチを「releases go here」ブランチにマージし、そのようにタグ付けします。
  • 一部のサイトには「ここにリリース」ブランチがなく、リリースブランチの終わりにタグが付いているだけです。

git-flow全体を適切に適用することを真剣に検討する必要があります。これは現在行われていることからそれほど遠くなく、各ブランチの意味と各ブランチが他のブランチと相互作用する方法にある程度の規律と一貫性を置きます。

問題は、QAブランチが1つしかないことです。

リリースごとに、プライマリ開発トランク/マスターから個別の QAブランチを作成します。次に、そのブランチの機能のバグの修正のみをマージします。新しい機能は使用しないでください。QAにそのブランチをテストしてもらいます。

このように、「フリーズ」は非常に明白です-それはブランチ名にあります。次のようなものを使用できますrelease/26/10/2015。そうすれば、この後誰も新機能をマージしてはならないことは明らかです。

フリーズするまでブランチをフォークしない場合に特に役立ちます。人々はいつでもマスターにマージできます。テストに間に合わない場合、このリリースの一部にはなりません。

長時間実行されるQAブランチを1つも持たないでください。これはトラブルを招いています。各リリースのメイン開発ブランチから分岐し、そのブランチをQAします。

以下に示すDevelopment-MAIN-Production分岐モデルに多少マッピングされます。MAINの上のエリアは開発エリアと呼ばれます。MAINの下の領域は生産領域です。

このモデルのハイライトは、あなたに関連すると思います：

• 開発者は、最新の変更が常に最新の全体的な開発を考慮できるように、頻繁に（週に2〜3回）DEVブランチにForward Integrate（FI）（FI = MAINから離れてマージ）する必要があります。
• 開発者は、QAに公開し、迅速な修正を提供する準備ができている機能完了のマイルストーンに到達した場合にのみ、TESTブランチでリバース統合（RI）（RI = MAINへのマージ）を行う必要がありますQAフィードバックへの応答。修正はTESTブランチで実行され、DEVブランチですぐにFIが実行されます。
• 決して任意のDEVブランチからMAINにRI
• TESTの品質がOKであるとQAが判断した場合にのみ、TESTブランチからメインへのRIを常に使用します。MAINにマージするには、高品質のしきい値を維持してください。少なくとも、プロダクトマネージャーは、MAINの最新のコミットから、製品の動作バージョンを常にデモできる必要があります。
• 必要な場合にのみ、生産エリアにブランチを作成します。ビルドサーバーは、開発エリアからのブランチを含むすべてのブランチに常にタグを付ける必要があり、ビルド/リリースのソースは、ブランチに関係なく常に識別可能でなければなりません。
• メインまたはプロダクションエリアからのみプロダクション用のリリースを取得します。後で正確にリリースされたバージョンの修正を提供する必要がある場合（つまり、MAINから最新バージョンを提供することはできません）、修正が必要なときに、障害のあるリリースのMAINタグから生産エリアにブランチを作成します。HotFixブランチの問題を常に修正し、すぐにRIをMAINに、FIをTESTに修正します。

次の理由で問題があると思われます。

• 機能マイルストーンが完全ではないテストコードへの開発者RI
• QAから青信号を取得せずに開発者RIがTESTに移行します（つまり、QAはTESTに注入されるものを制御しません）
• QAがTESTのバグを報告すると、開発者はDEVブランチでバグを修正し、RIをTESTに修正します。マージは常に他の不完全な開発スクラップをもたらすため、これは大きな悪い習慣です。常にTESTで修正してから、FIをDEVブランチに修正する必要があります。TESTで修正できない場合、彼らはそもそも完全ながらくたを出し、あなたはより大きな問題を抱えています。
• 開発者はTESTから頻繁にFIを取得しないため、テストを配信するたびにTESTを不安定にします。FIからDEVに至る頻度のバランスをとる美術です。延期しすぎると、配達の直前に非常にコストがかかり、リスクが高くなります。あまりにも頻繁に行うと、その間にTESTで他の人から提供された作業とあまりにも重なっていると、実際の開発作業を完了できません。

私が質問を理解しているように、あなたには2つの問題があります。（a）破損した機能は、リリースしたい優れた機能とマージされます。（b）壊れた機能を抑制しながら、優れた機能をリリースできるようにしたい。考えられる解決策の制約として、次のリリースに予定されているすべての機能を含む統合ブランチで最終/公式QAテストを実行したいと考えています。

SCM分岐モデルに関係なく、次のいずれかまたは両方を試すことをお勧めします。

1. QAリソースを各機能チームに割り当てます。機能ブランチからのビルドでいくつかの機能テストを実行し、機能がマージに十分であるかどうかを判断する権限を与えます。理想的には、機能チーム（の残りの部分）と協力して作業するようにしてください。そうすれば、内容は作成後すぐにテストされます。（これは、すべてのテストを自分で行う必要があるという意味ではないことに注意してください。）
2. 機能分岐の代わりに、または機能分岐に加えて、機能トグルを使用します。機能の切り替えを行うと、破損した機能をコードからマージ解除せずにオフにできるため、他の機能をテストおよびリリースできます。私が話している種類のトグルには、顧客はアクセスできません。指数関数的に増加する組み合わせの数をテストする必要はありません。QAブランチのトグルを設定して、リリースする予定の機能に一致させ、機能の準備ができていないために計画が変更された場合、そのトグルを変更します。

私があなたのチームよりも少し大きいチームで働いているのを見た非常に簡単な解決策は、誰もが単一のブランチから作業してデプロイすることです。

チームは機敏であると言いますが、スプリント（つまりスクラム）で作業しているのか、より継続的なフロー（つまりかんばん）のアプローチで作業しているのかは明確ではありません。あなたがスプリントをしていると仮定すると、チームの目的は、2週間ごとのリリースのために、各スプリントの終わりにコードをリリースできるようにすることです。ある機能がすべて一緒に開発されているため、ある機能が別の機能を破壊するかどうかに関して混乱はありません。開発者が提供するオーバーヘッドが少ないため、テスターはより小さなチャンクで機能にアクセスできる場合があります。また、QA-Freezeは本当に必要ありません。代わりに、誰もがスプリントの終了がいつ終わるかを知っており、終了できない作業を行ったり、展開可能な（つまり無効な）状態のままにしてはいけません。

明らかに、どのアプローチにも賛否両論がありますが、これは必ずしも「最善の方法」ではないオプションとして提示します。

これらの問題が発生する理由は、QAにリリースされたコードの品質が十分ではないためです（そして誰でも！これを行う最も簡単な方法は、リリース先の中間ブランチを導入することです（テストと呼びます）。これはまだ開発権限の下にありますが、開発者は作業を続行するためにプッシュすることができます。また、QAに送信するのに十分な品質の統合ブランチも必要です。

QAが現在見つけているバグを見つけるために、このブランチで統合テストを行うことができます。バグは元のブランチで修正してから、再度マージできます。前者）。一連の基本的なテストに合格すると、「ユーザーの粘着性のある指と彼らが何をしたの？」のためにQAに送信できます。テスト。

そのため、このアプローチは、機能が十分にコーディングされていないためか、予期しない統合の問題があるかどうかに関係なく、QAブランチを壊れた開発機能から保護するように設計されています。統合テストに合格した開発ブランチのみがQAに昇格します。