機能がテスト用にステージングされるようになると、規模が大きくなるにつれて問題に遭遇し始めますが、すべてがテストされ、承認された新しい機能がテスト用にステージングされます。

これは、テスト済みの機能と未テストの機能の組み合わせがあるため、本番環境にほとんどプッシュできない環境を作成しています。これは一般的な問題であると確信していますが、まだ私たちにとって良いリソースが見つかりませんでした。

いくつかの詳細：

• BitBucketのGIT
• Azureへのスクリプト展開用のJenkins

私が望んでいるのは、機能が環境を移動するときに機能を分離し、準備ができているものだけをプッシュする方法です。

ここにいくつかの問題があるようです。

1.特定のリリースの機能を識別する

これはプロジェクト管理の問題であり、調整の問題です。ウィルこの機能は、同じ時間に、前にリリースされ、またはこの後のこと、他の機能は？リリースが一度に1つの機能を実行したい場合は、それを特定します。機能をリリースにグループ化する場合は、グループ化が何であるかを把握し、開発者と意思決定者に適用します。問題追跡システムまたはチケットシステムを使用して、リリースにタグを付けます。特定のリリースの1つの機能がノーゴーである場合は、すべての機能がノーゴーであることを明確にしてください。

2.分岐戦略

Git-flowはこれらのような問題に対する簡単な答えであり、多くの場合、人々はそれが何であるかを知らなくてもgit-flowのバリアントを使用します。すべての問題に対応できるとは言いませんが、大いに役立ちます。

機能が承認されたスキャッターショットであり、以前に開発を開始したものが最近開始されたもの-跳躍カエル機能の後にリリースされる可能性がある非決定的リリース戦略の問題に直面しているようです。

長期にわたる機能ブランチまたは同時リリースブランチは、おそらくこの種の問題に対する最善の答えです。masterから最新のブランチを長期実行ブランチにマージします（または、使い慣れている場合はリベースします）。すでに公開されている機能のみをマージするように注意してください。そうしないと、これまでに発生していた問題（1つのブランチに多すぎる機能が混在している）に遭遇します。

「Hotfix」または「bugfix」ブランチは、このプロセスの重要な部分です。QAサイクルが短い小さな一時的な修正に使用します。

あなたの説明から、公式の「開発」ブランチを維持しないほうが良いかもしれません。むしろ、すべての機能をマスターから分岐し、リリースが識別されたらマージされたリリース分岐を作成します。

3.環境

production == masterを除き、gitブランチを環境に合わせないでください。「開発」ブランチは破損していると想定する必要があります。リリースブランチは、QA環境であろうとステージング環境であろうと、テスト環境にプッシュされます。必要に応じて、特定の機能ブランチを環境にプッシュします。

個別にリリースする必要があるが、同時にテストされている機能ブランチが複数ある場合.....¯\ _（ツ）_ /¯....別のサーバーを起動しますか？たぶんそれらを一緒にスローアウェイブランチにマージしてください...元のブランチに修正/変更をコミットし、スローアウェイブランチに再マージしてください。個々のリリースブランチで最終承認とUATを行います。

4.承認されていない機能をブランチから削除する

これは、上記の考えが回避しようとしていることです。なぜなら、これは間違いなく試してやるべき最も苦痛なことだからです。運が良ければ、マージコミットを使用して、機能が開発ブランチまたはテストブランチにアトミックにマージされています。運が悪い場合、開発者は開発/テストブランチに直接コミットしています。

いずれにせよ、リリースの準備をしていて、承認されていない変更がある場合、Gitを使用して、承認されていないコミットをリリースブランチからバックアウトする必要があります。リリースをテストする前にそれを行うのが最善のアイデアです。

幸運を祈ります。

ここにアイデアがあります。リリースブランチの使用をやめてください。代わりに、機能トグルの構築を開始し、構成を介して管理します。そうすれば、機能のブランチを常にmasterにマージし、どのバージョンがテスト中またはprodであるかについて質問することはありません。環境でアクティブな機能/実装について質問がある場合は、構成ファイルを確認してください。

これは、テストと本番の間の調整の単純な問題でなければなりません。Gitで機能ブランチを使用している場合は、テストサイクル中に完了した機能ブランチのテストへのプッシュを停止し、テストが完了したら再開します。

これよりも適切な制御が必要な場合は、テストを開発サーバーと受け入れテストサーバーに分け、受け入れチームにプッシュされるブランチをテストチームと調整します。その後、誰かがAcceptance TestからProductionへの最終展開を開始する責任を負うことができます。

積み上げ

これは私の経験では普遍的な問題です。私はそれに対処します：

• 製品所有者による機能リリースの強力な管理
• ブランチがマージされたときに削除されるようにする
• 進行中の作業を制限する（Jiraの列制限を使用）
• バグと機能の両方で、苦しんでいる古いチケットの四半期レビュー
• 問題の構成要素を議論する回顧
• すべての人によるコードレビューの絶え間ない励まし
• 長年のチケットと問題に取り組むためのペアリングの機会
• 古いチケットを確認して整理する四半期ごとの会議
• 開発者、製品、QA / QEを緊密に連携させるためのチームアプローチ
• 新しい製品機能とバックログを明確にするための優れたレポートとツール
• セッションを確認して古いブランチを通過し、それらを削除します

枝

そのプロセスを制御するには、いくつかのブランチが必要です。

• 特徴：この枝はマスターから生まれます。プロジェクト管理アプリケーションを使用して、いくつかのタスクで各機能ブランチを識別します。：例ごとに、あなたはTRACを使用する場合、次のような枝場合は終了します1234-user-crud、1235-bug-delete-catalogなどがあまりにもタスク番号を使用してコミットを確認します（必要になります）マージに問題がある場合、これはあなたに大いに役立つでしょう。
• test：実行されたすべての機能ブランチがテストブランチにマージされます。あなたは、いくつかの機能ブランチにテストブランチをマージすることはありませんあなたは、生産（マスター）に含まれていない他の機能からコードをしたくないので、。同じことがreleaseブランチにも有効です。
• release：本番環境でテストできる機能を決定するとき、このブランチにこのブランチを（再び...）マージします。このマージにより新しい問題が発生する可能性があるため、すべての機能を再度テストする必要があります。リリースをテストして完了したら、このブランチをマスターにマージし、そのバージョンのマスターにタグを作成します。
• master：製品コードのみが含まれます。

gitフローを参照してください。

                              |FEAT_2|
                                  |
                             .---C06<-------.---------.
                            /                \         \
                           /   |FEAT_1|        \         \
                          /       |            \         \
                         /    .--C07<--.--------\---------\---------.
                        /    /          \        \  |TEST| \         \
                       /    /            \        \    |    \         \
                      /    /        .-----`--C09<--`--C10    \         \ |RELEASE|
                     /    /        /                          \         \    |
    <v4.6.0>        /    /        /                       .----`--C11<---`--C12<--.
       |           /    /        /                       /                         \
C01<--C02<--C04<--´----´--------´-----------------------´---------------------------`--C13
 |           |                                                                          |
<v4.5.0>  <v4.6.1>                                                                   |MASTER|
                                                                                        |
                                                                                     <v4.7.0>

環境

非常にシンプル：

• test：この環境ではtestブランチを使用します。
• release：この環境は実際のリリースブランチを使用します。

開発者は自分のマシンで作業し、それぞれが独自のデータベースを使用します。開発者ごとに個別のデータベースを用意できない場合（ライセンス、データベースのサイズなど）、開発者間でデータベースを共有する際に多くの問題が発生します。誰かが自分のブランチの列またはテーブルを削除すると、ブランチは、データベース内のこの列/テーブルでカウントされます。

問題点

このプロセスの最大の問題は、マージです。

とで同じマージを再作成する必要がtestありreleaseます。いくつかの良いリファクタリングは、コード内で行われた場合、あなたは、これは、のように、などのクラス、移動/リネームメソッドを削除痛みを伴うことになることができないからコードを取得test（またはrelease）機能ブランチへのブランチは、マージコミットだけで解決することができますtest（またはrelease）。中：だから、あなたはおそらく将来的には、各マージに異なるコードを生成して、二つの異なる支店で同じ競合を解決結局、あなたはテストチームは二度の機能をテストする必要があることを発見するでしょうtestし、release支店、各マージので、さまざまなバグが発生する可能性があります。

別の問題はtestブランチです。master古いブランチ（または古いマージ、削除されたマージされたブランチ）が新しいコードに多くの問題をもたらす可能性があるため、時々このブランチを「リサイクル」する必要があります（削除してから新しいブランチを作成します）。 〜から大きく離れるmaster。この時点で、で再度マージするブランチを制御する必要がありますtest。

本当に最適なソリューションは、ビジネスチームが次のバージョンで何を提供する必要があるかを知っており、全員が独自のブランチ（開発ブランチ）で作業することです。次のバージョンで必要な「完了」機能をいつでも選択できるのはよいことです（これはあなたのシナリオだと思います）が、これは開発者にとって（そして私は）悪夢ですテストチーム。

統合ブランチからの変更を本番ブランチにマージしているように聞こえますが、これはまさにあなたが言及した理由から、良い方法ではありません。特定のリリースの本番ブランチがメインの統合ブランチからプルされるとすぐに、統合ブランチはいつでも分岐することができます（結局、次のリリースに進化することになっています）。統合ブランチから現在のリリースブランチにマージすると、そのリリースと互換性のない変更が生じる可能性があります。

私見適切なプロセスは次のとおりです。

• 統合ブランチから本番ブランチをプルするのは、目的の品質レベルに十分近いと思われる場合にのみ、リリースを完了するためにほんの一握りの変更のみが期待されるようにします。言い換えると、本番ブランチをプルする前に、統合ブランチで機能の完了を（継続的に）評価する必要があります。
• 本番ブランチがプルされた後、チェリーピックされた変更のみがもたらされ、スタンドアロン/ポイントフィックスの変更として扱われます-つまり、実際に期待通りに動作することを検証しました別のブランチで）。

個人的には、これはツールの問題よりもプロセスの問題である可能性があります。ここで提案するいくつかのこと：

• 開発グループとQAグループが分かれているかどうかはわかりません。その場合、開発者とQAの両方がスプリントの計画と見積もりの​​会議に参加するようにしてください。私の以前の会社の1つでは、ストーリーに割り当てたストーリーポイントの数が、開発とテストの両方の作業の原因となっていることを確認しました。（理論的には、devとQAの労力について2つの別々の推定値を使用することもできますが、どちらの方法でも推定値の両方を含める必要があります。ストーリーに必要な時間は、実際に配信するのに必要な時間です）。個別のQAグループがない場合でも、テスト作業を見積もりに含めるようにしてください。
• 上記と同様の流れに沿って、特定のスプリントに含めるストーリーの数について事前に同意します。受け入れるストーリーポイントの数は、開発者がスプリントで完了できる量と、QAがスプリントでテストできるアイテムの数に基づいています。（もちろん、QAスプリントはDevスプリントの背後にあると想定していますが、これをプロセスに適合させることができます）。開発者が200ストーリーポイントを完了できるが、QAが150ストーリーポイントしか完了できない場合、作業が「蓄積」し始める前に明らかに150ストーリーポイントしか実行できず、説明したようなケースになります。（このような場合、障害を軽減するためにロードブロッキングの原因を調査することをお勧めします）。
• 現在QAにあるすべてがテストされて配信されるまで、誰もQAに何もプッシュしません。
• 完全な機能とは、テストおよび提供された機能のことです。配信されない場合は実行されません。
• 明らかに、あなたはこれを何らかの固定されたスケジュールでやろうとするでしょう。継続的インテグレーションとアジャイルの背後にあるアイデア全体の1つは、反復です。定義上、反復には頻繁な配信が必要です。頻繁な統合と配信により、それぞれのリスクが最小限に抑えられます。

正直なところ、最大のことは、あなたが提供している時間と、与えられた時間枠で実際に完全に完了できるタスクの数についての規律だと思います。

要約すると、QAに提供するのは、古い機能のテストと提供が完了したときだけです。

「すべてがテストおよび承認される」場合、テストおよび承認されたものを実稼働環境に展開します。これは特定のコミットの場合もあれば、ジェンキンスが生成した特定のビルドアーティファクトの場合もあります。

同じブランチでの以降のコミットがまだテストされていないことは問題ではありません。