UATリリースのgitflowモデルは無秩序すぎるので、単純化するにはどうすればよいですか？

Question

$DAYJOB、次のリリース/配信パイプラインがあります。

新機能を入手し、新機能に取り組みます。
すべての機能が完了すると、独自のQAが回帰などを実行します。
QAは最初のUATビルドを承認し、お客様のUAT部門に出荷します（これは実際にはお客様自身のQA部隊です）。これで最初のバージョンが始まります（例：v1.0）
顧客QA（UAT）が問題を見つけ、リストを送り返します。
開発は問題のリストに対処します。時には、改善や小さな機能などの欠陥ではないものを要求するかもしれません。これらはケースバイケースで切り分けます。私たち自身のQAも修正を検証します。彼らはサインオフし、私たちは新しいビルドを出荷します（これはv1.1のようなバージョンのバンプを取得します）
この「リストの取得」および「リストでの作業」プロセスは、顧客がビルドをサインオフするまで数回繰り返されます（UATパス）。
サインオフしたビルドは「本番」になります。これで、開発者は次のリリースの新機能に取り掛かることができます。

このプロセスに関するいくつかのメモ：

このプロセスにはgit-flowの粗末バージョンを使用します（後で詳しく説明します）。
バージョン管理については、UATリリースと製品リリースを区別しません。 UATへのリリースはいつでも承認され、いつでもゴールドになると想定する必要があります。私たちにとって、「戸外」での各ビルドは「製品リリース」として扱われます。
開発者は新機能のためにdevelopのブランチに取り組んでいます。 nextリリースの機能にも取り組んでいます。ただし、リリースがスケジュールされるまで、機能はマージされません。これは、「リリース」ブランチを作成しないためです（これについては後で詳しく説明します）。

以下は、バグと機能の両方に対する開発プロセスの流れです。

開発者はdevelopを分岐して作業を開始します。
開発者が作業を完了し、コードレビューを実行する
コードレビューに合格し、ブランチがテストの準備ができていることをQAに示します。 CIビルドシステムはリモートリポジトリ内のすべてのブランチをビルドし、QAは任意のブランチからアドホックビルドを取得できます。 QAはいくつかの理由でブランチの機能をテストします（developからではなく）：
1. developのビルドには、複数の開発者からの複数の機能またはバグ修正が含まれる場合があります。回帰が発生すると、回帰の原因を追跡することがより困難になります。「test-each-branch」モデルを使用すると、そのブランチの変更に対する回帰（つまり、1つの機能またはバグ修正）を分離できます。
2. QAが満足するまで、すべての機能をdevelopにマージしないため、すべての機能をブランチでテストする必要があります。また、QAは導入スケジュールを管理するので、開発者がいつ新機能の準備ができるかを知ることができます。
3. QAリソースは厳しくなっています。現在、開発者とQA担当者の比率は4：1です。彼らは私たちの仕事に追いつけないだけです。
QAがブランチの機能に満足したら、彼らはそれを「検証済み」としてマークします。
検証されると、適切な権限を持つ誰かが機能またはブランチを「承認」するまで、変更はありません。この時点で、開発者は最新のブランチをリベース/マージし、競合を修正してからdevelopにマージします。

最後にソフトウェアをリリースするとき（通常は新しいUATビルド）、developからmasterに直接マージします。

現在のシステムの症状：

マージされるのを待っているたくさんの枝。現時点では100を超え、ターンアラウンドタイムは、マージされるまでに数か月かかることがあります。
プロセスは複雑で、QAによって厳しく制御されています
サブモジュールをミックスに投入すれば、災害と複雑さのレシピが手に入ります。

releaseブランチを現在使用しない理由は、ブランチでの経験が悪いためです。 UATプロセスには数か月かかることがあります。時には彼らは不当に機能を要求し、上級管理職はそれを許可します。リリースブランチが多数になり、寿命が長くなり、パリティの大きな問題が発生しました（つまり、リリースブランチは存続期間中に大量の変更を蓄積します）。

この全体はかなり混沌としていて、管理するのが難しいです。ただし、リリースは非常に安定しているため、QAにより、このプロセスについて多くの素晴らしいフィードバックが得られます。これは、QAがマージされる前にすべてのブランチに触れるのに対し、開発者が1日中developにマージし、QAが変更に対応できなかったため、リリースでは多くのテストが行われなかったためです。

プロセスと状況を説明したので、いくつかの質問：

このプロセスをどのように簡略化できますか？
途中にUATプロセスがある場合、releaseブランチはどのように処理する必要がありますか？理想的には、developでアクティブな開発を継続できるようにしたいafter UATの開始。

Michael Durrant · Answer

多くの組織で私が見たよく知られた問題の多く。

私の提案は次のとおりです：

機能分岐のマスターから分岐
QAにマージをマスターに戻してプッシュする
マスターを毎週リリースし、各リリースにリリース日をタグ付けする

それはコードであり、ワークフローの面でもです。

難しい部分は次のとおりです。

文化を変える
何が間違っているのか、なぜ間違っているのかについては、おそらくさまざまな意見があります。組織の最高（関連）レベルから賛同し、擁護する必要があります。このようなスリム化されたシステムの利点を説明して販売する必要があります。シンプルさと迅速なターンアラウンドを説明してください。（おそらく）アジャイルプロセスが単なるリップサービスではなく、実際のアジャイルプラクティスと、可能な場合はスクラムマスターから十分に検討されていることを確認してください。
既存のワークフローを変更する新しいワークフローをまとめて、それに移行するための計画を立てる必要があります。

他の考え：

（一部の）変更をマージできるが、管理GUIを介して機能をオン/オフにする包括的な機能切り替えシステムの実装を検討してください。
機能を完成させてQAに渡すのではなく、デリバリーパイプラインで、設計、実装、およびテストにQAを関与させることを検討してください。 QAが実装に驚いたり、開発者がQAのテスト方法に驚いたりしたくはありません。
関係者全員と毎週リリースミーティングを行い、すべてのチケットを通過します。これは簡単に50-100チケットにすることができます。ビジネスへのリリースの影響、リリース前のステップ、リリース後のステップ、ダウンタイムなどについて、それぞれに基づいて触れてください。

Amila · Answer

私はこの質問が少し古いことを知っていますが、手動qaを通過するまで物事がマージされて開発されなかった同様のフェーズも経験しました。私の経験が同様の問題に直面している誰かを助けることを願っています。

最大の問題は、ブランチが孤立しすぎて、マージして開発しようとしたときにマージ地獄が作成され、その後の機能がまだマージされていない開発前のブランチのコードに依存している場合に、開発者が回避策を見つける必要があることです。。

そのため、古いブランチをマージするために何時間も無駄に費やした後、開発者が完了したら直接マージして開発することを決定しました。開発で見つかったバグは優先的に修正されます。

開発者がテストするまで何もリリースしないという責任を（正しく）負わせ、QAが「ゲートキーパー権限」を失うことにあまり満足していないため、これは文化的な変化でもあります。

しかし、私たちはしばらくの間、直接マージして開発を続けてきました。

void.pointer · Answer

最終的に、howお客様が使用するつもりであるかどうかに関係なく、物理的なリリースごとにリリースブランチを使用することを決定しました。リリースされたビルドが偶然UAT経由で作成されなかった場合、それは問題ありません。別のreleaseブランチを作成して、再度出荷します。ただし、UATがビルドを受け入れた場合、再度ビルドする機会はありません。その場合、彼らは取得したビルドを保持し、UATとはまったく関係のない次のリリースに進みます。

この点で、すべてのリリースはまったく同じフローとルールに従います。 UATサイクル中に週にいくつかのリリースブランチを作成するのではないかと思いましたが、そうではありません。 QAチームはリリースブランチに十分な時間を費やしており、2週間に1回しか作成していません。

これまでのところ、これはうまく機能しており、非常に扱いやすいです。また、機能のリリースがUATのリリースが完了するまで待機するように強制します。これは素晴らしいことです。より詳細なレベルでリリースを処理できます。