隔週で製品リリースにすぐにリリースできる機能のみを含めるにはどうすればよいですか？
私はかなり大きなアジャイルチームのソフトウェア開発者です（8人の開発者が1つのコードリポジトリに積極的に変更を加えています）。 2週間ごとに、新しいバージョンのソフトウェアを製品版にプッシュします。現在のワークフローは次のとおりです。
- 新しいタスクを開始するとき、開発者はメインの開発ブランチから「機能ブランチ」を作成し（ git を使用）、この新しいブランチで作業します
- 開発者がタスクの作業を完了すると、機能ブランチを開発ブランチにマージします。
- 開発者は、開発ブランチをQAブランチにマージします。
- ビルドはQAブランチからトリガーされます。このビルドの出力は、テスターがテストを開始できるように、QA環境にデプロイされます。
テスト担当者がQAブランチにマージされたこれらの新機能の問題を見つけることは非常に一般的です。これは、常に、QA環境にいくつかの新機能が含まれている可能性があることを意味します。 QAビルドが本稼働可能な状態であることはまれであるため、リリースが困難になります。
これを緩和するために、私たちは「QAフリーズ」を開始しようとしました。これは、開発者がリリースの数日前に開発ブランチをQAブランチにマージしないことを意味します。 QA環境のバグ修正は、QAブランチで直接行われ、開発ブランチにマージされます。理論的には、これにより、QAで問題のある新しい問題を修正しながら、QAから新しい機能の破損を防ぐことができます。
この「QAフリーズ」の概念は部分的に成功していますが、調整が難しく、QAへのマージが許可されているかどうかについて混乱することがよくあります。 「QAフリーズ」の期限を設定することも困難です。誰もが、フリーズとリリースの間に少し余裕があるというアイデアを気に入っていますが、実際には、期限を尊重するよりも、次のリリースに機能を持たせたいと考えています。
隔週でリリースのクリーンビルドを確保するためのより良い方法はありますか？
これには、発生している問題の原因となっているいくつかの問題があります。
1つ目は、長期にわたるQAブランチです。 QAブランチとメインラインの両方でレプリケートする必要のあるさまざまな作業があるため、開発メインラインと並行している長期実行ブランチがあると混乱の原因となる可能性があります。これは、メインラインにマージする必要があるQAブランチの修正をチェックインしている（悪いことではない）、またはQAブランチにマージされているメインラインにチェックインしている（バグの可能性のあるソース） 。
長時間実行される並列ブランチのもう1つの問題は、ファイルが永続的に同期されなくなる可能性があることです。マージされないコード修正、またはテストされておらず開発メインラインの一部である本番ビルドに必要な構成。
次に、影響を受ける役割があります。これは、パッケージの役割（これについては後で詳しく説明します）が十分に分離されていないことを意味します。
git-flow モデルでは、リリースブランチは開発から分岐され（not開発はQAにマージされます）、すべての修正はリリースブランチにチェックインしてから、開発ブランチにマージして戻しました。
分岐の哲学の一部は Advanced SCM Branching Strategies にあります（私は優れた読み物と考えています）。これは、各ブランチが担う可能性のある役割に焦点を当てています。リリースブランチがパッキングの役割を果たします。
パッケージングの役割は、蓄積、またはより一般的にはメインラインの役割と混同されることがよくあります。意図された開発とメンテナンスが行われ、蓄積が完了したら、リリースのためにコードを準備します。このような作業は簡単ではなく、リリースエンジニアのチームと、すでに実行されたもの以外の追加の修正が必要です。パッケージングロールのポリシーは、メンテナンスブランチのポリシーとは大きく異なります。パッケージングの役割が示唆するように、製品をリリース可能にするために必要な変更のみに対処する必要があります。
- 開発ポイントからリリースブランチに分岐します。 QAのビルド元のリリースブランチには1つのブランチがあり、開発からのマージはありません。
- 一貫したネーミングとフックを使用してその道を進みたい場合は、リリースブランチへのマージが行われないようにすることができます。
- リリースブランチで修正する必要があるすべてを修正し、それらの変更をメインラインにマージします。
- リリース作業の最後に、リリースブランチを「リリースはここに行く」ブランチにマージし、タグを付けます。
- 一部のサイトには、「リリースはここに行く」ブランチがなく、リリースブランチの終わりをタグでぶら下げています。
Git-flow全体を適切に適用することを真剣に検討する必要があります。これは、現在行われていることからそれほど遠くはなく、各ブランチの意味と各ブランチが他のブランチとどのように相互作用するかにある程度の規律と一貫性をもたらします。
問題は、QAブランチが1つしかないことです。
リリースごとに、プライマリ開発トランク/マスターからseparate QAブランチを作成します。次にマージしますのみそのブランチの機能のバグの修正-新しい機能はありません。そのブランチをQAテストします。
このように、「フリーズ」はブランチ名に含まれているので非常に明白です。わからない、release/26/10/2015などを使用できます。その後、誰もこの後の新機能にマージするべきではないことは明らかです。
フリーズするまでブランチをフォークしない場合に特に便利です。人々はいつでもマスターにマージすることができます。テストするために間に合わなければ、このリリースには含まれません。
単一の長期実行QAブランチを作成しないでください。問題が発生するだけです。各リリースのメイン開発ブランチからのフォークとそのブランチのQA。
以下に示すDevelopment-MAIN-Production分岐モデルに多少マッピングされます。 MAINの上のエリアは開発エリアと言われています。 MAINの下の領域は、生産領域です。
私があなたに関連すると私が考えるこのモデルのハイライト：
- 開発者は頻繁に（週に2〜3回）フォワード統合（FI）（FI = MAINからマージ）して、DEVブランチに最新の変更が常に最新の全体的な開発を考慮するようにする必要があります。
- 開発者は、QAに公開したい機能完了マイルストーンに到達したときに、テストブランチのみでリバース統合（RI）（RI = MAINにマージ）する必要がありますまた、QAフィードバックに応じて迅速な修正を提供する準備ができています。修正はTESTブランチで実行され、すぐにDEVブランチでFIが実行されます。
- 絶対にしないDEVブランチからメインへのRI
- QAがTESTの品質に問題がないと判断した場合のみ、常にTESTからRIがMAINに分岐します。 MAINにマージするための高品質のしきい値を維持します。少なくとも、製品マネージャーは、MAINの最新のコミットから製品の作業バージョンを常にデモできる必要があります。
- 必要な場合にのみ、生産エリアにブランチを作成します。ビルドサーバーは、開発エリアからのブランチを含むすべてのブランチに常にタグを付ける必要があり、ビルド/リリースのソースは、ブランチがどこにあっても常に識別可能である必要があります。
- MAINまたは生産エリアからのみ、生産用のリリースを取得してください。後で正確にリリースされたバージョンの修正を提供する必要がある場合（つまり、MAINから最新バージョンを提供するだけではできない場合）、修正が必要なときに、障害のあるリリースのMAINタグから本番エリアにブランチを作成します。 HotFixブランチで常に問題を修正してから、すぐにRIをMAINに、FIをTESTにしてください。
私はあなたが問題を抱えていると思います：
- 開発者のRIが機能マイルストーンの完了していないTESTコードに
- 開発者のRIがQAから青信号を取得せずにTESTに入る（つまり、QAは何がTESTに注入されるかを制御していない）
- QAがTESTに関するバグを報告すると、開発者はDEVブランチでバグを修正し、次にRIをTESTに組み込みます。これはメジャーの悪い習慣です。マージは常に他の不完全な開発クラップをもたらすためです。彼らは常にそれをTESTで修正してから、FIをDEVブランチに修正する必要があります。 TESTで修正できない場合は、そもそもがらくたを出し、大きな問題が発生します。
- 開発者はTESTから十分な頻度でFIを取得しないため、開発者はTESTを配信するたびに不安定化します。 FIからDEVへの変換頻度のバランスをとるのはすばらしい技術です。あまりに延期すると、配達の直前に非常にコストがかかり、リスクが高くなります。あまりにも頻繁に実行し、その間にTESTの他の人から提供された作業と重複しすぎると、実際の開発作業が完了しません。
質問を理解すると、2つの問題があります。 （a）壊れた機能は、リリースしたい優れた機能と統合されています。 （b）壊れた機能を抑えながら、優れた機能をリリースできるようにしたい。考えられるソリューションの制約として、次のリリースで予定されているすべての機能を含む統合ブランチで最終的な/公式のQAテストを実行することを想定しています。
SCM分岐モデルに関係なく、次のいずれかまたは両方を試すことをお勧めします。
- 各機能チームにQAリソースを割り当てます。彼らに機能ブランチからのビルドでいくつかの機能テストを行わせ、機能をマージするのに十分な時期を決定する権限を与える。理想的には、機能チーム（の残りの部分）と協力して作業してもらい、記述後すぐにテストを行います。 （これは、すべてのテストを自分で行う必要があるという意味ではありません。）
- 機能分岐の代わりに、または機能分岐に加えて、機能切り替えを使用します。機能の切り替えを行うと、機能の切り替えにより、コードからのマージを解除せずに、壊れた機能をオフにできるため、他の機能をテストしてリリースできます。私が話している種類のトグルは、顧客がアクセスすることはできません。テストする組み合わせの数が指数関数的に増加するのは望ましくありません。 QAブランチのトグルを、リリースする予定の機能と一致するように設定し、機能の準備ができていないために計画が変更された場合は、そのトグルを変更します。
これらの問題が発生する理由は、QAにリリースされたコードの品質が十分ではないため（そして誰かがそうですか？！）、QAのリリースを改善する必要があるため、頻繁にビッグフィックスを受け取る必要がありません。これを行う最も簡単な方法は、リリースする中間ブランチを導入することです（テストを呼び出します）。これはまだ開発権限の下にありますが、開発者はそれをプッシュして作業を続けることができ、QAに送信するのに十分な品質の統合ブランチも持つことができます。
QAが現在検出しているバグを見つけるために、統合テストをこのブランチで行うことができます。バグは元のブランチで修正してから再度マージできます。また、このブランチで直接修正するか、バグを直接修正できるようになるまで繰り返します（私は、前者）。一連の基本的なテストに合格したら、「ユーザーの指を動かして、彼らは何をしましたか？」についてQAに送信できます。テスト。
したがって、このアプローチは、QAブランチを開発機能の破損から保護するように設計されています。これは、機能が十分にコーディングされていなかったためか、予期しない統合問題があったかどうかは問題ではありません。統合テストに合格した開発ブランチのみがQAに昇格されます。
私があなたのチームより少し大きいチームで作業するのを見た非常に単純な解決策の1つは、すべての人が単一のブランチから作業して展開することです。
チームは俊敏であると言いますが、スプリント（つまり、スクラム）で作業しているか、より継続的なフロー（つまり、かんばん）で作業しているかは明確ではありません。あなたがスプリントをしていると仮定すると、チームの目的は、隔週のリリースのために、各スプリントの終わりにコードをリリース可能にすることです。それらがすべて一緒に開発されたため、ある機能が別の機能を壊すかどうかについて混乱はありません。テスターは、開発者がそれらに提供するオーバーヘッドが少ないため、小さなチャンクで機能にアクセスできる場合があります。また、QAフリーズは実際には必要ありません。代わりに、スプリントの終わりがいつ終わり、展開できない（つまり無効な）状態のままにできないか、誰も仕事を始めるべきではないことを誰もが知っています。
明らかに、どのアプローチにも賛否両論がありますが、これは必ずしも「最良の方法」ではないオプションとして提示します。