枝が積み重ならないようにする
大きくなるにつれて問題が発生し始めています。機能はテスト用にステージングされますが、すべてがテストされ、承認された新しい機能がテスト用にステージングされています。
これにより、テスト済みの機能とテストされていない機能の組み合わせがあるため、本番環境にほとんどプッシュできない環境が作成されています。これはよくある問題だと思いますが、私たちに役立つリソースはまだ見つかっていません。
いくつかの詳細：
- BitBucketのGIT
- AzureへのスクリプトによるデプロイメントのためのJenkins
私が望んでいるのは、機能が環境を移動するときに機能を分離し、準備ができているものだけをプッシュする方法です。
ここにいくつかの問題があるようです：
1.特定のリリースの機能を識別する
これはプロジェクト管理の問題であり、調整の問題です。 this 機能は、この other 機能の前、同時、または後にリリースされますか？リリースが一度に1つの機能で発生したい場合は、それを特定します。機能がリリースにグループ化される場合は、グループが何であるかを理解し、開発者and意思決定者にそれを適用します。問題追跡システムまたは発券システムを使用して、リリースにタグを付けます。特定のリリースの1つの機能が不合格である場合、それらすべてが不合格であることを明確にしてください。
2.分岐戦略
Git-flow は、このような問題に対する簡単な答えであり、多くの場合、それが何であるかを知らなくても、git-flowのバリアントを使用します。すべての問題を網羅するものだとは言いませんが、それは非常に役立ちます。
非確定的なリリース戦略で問題が発生しているようです。機能は承認済みのスキャッターショットであり、開発がかなり前に開始されたものは、最近開始されたもの-リープフロッグ機能の後にリリースされる可能性があります。
存続期間の長い機能ブランチまたは同時リリースブランチは、おそらくこの種の問題に対する最良の答えです。最新のfrom masterを長期実行ブランチにマージします（必要に応じてリベースします）。 only Merge in features are already lived、さもないと、今まで抱えていた問題にぶつかります（1つのブランチに多すぎる機能が混在しています）。
「ホットフィックス」または「バグフィックス」ブランチは、このプロセスの重要な部分です。 QAサイクルが短い小さな1回限りの修正に使用します。
あなたの説明から、公式の「開発」ブランチをnot維持するほうがよいかもしれません。むしろ、マスターからすべての機能を分岐し、リリースが識別されたらマージされたリリースブランチを作成します。
3.環境
本番==マスターを除いて、gitブランチを環境に一致させないでください。 「開発」ブランチは壊れていると想定する必要があります。リリースブランチは、QA環境でもステージング環境でも、テスト環境にプッシュされます。必要に応じて、特定の機能ブランチを環境にプッシュします。
個別にリリースする必要があるが、同時にテストされている機能ブランチが複数ある場合.....¯\ _（ツ）_ /¯....別のサーバーを起動しますか？おそらく、それらをスローアウェイブランチにマージしてください...修正/変更を元のブランチにコミットし、スローアウェイブランチに再度マージします。個々のリリースブランチで最終承認とUATを行います。
4.承認されていない機能をブランチから削除する
これは上記の考えが避けようとしていることです。これは間違いなく試行錯誤するのに最も苦痛なことだからです。運が良ければ、マージコミットを使用して、機能が開発ブランチまたはテストブランチにアトミックにマージされています。運が悪い場合、開発者は開発/テストブランチに直接コミットしています。
どちらの方法でも、リリースの準備をしていて、承認されていない変更がある場合は、Gitを使用して back out リリースブランチからの承認されていないコミットを実行する必要があります。最良のアイデアは、リリースをテストする前にすることです。
幸運を祈ります。
リリースブランチの使用を停止します。代わりに、 feature toggles でビルドを開始し、構成を介して管理します。こうすることで、機能ブランチを常にマスターにマージすることができ、どのバージョンがテスト版または製品版であるかについての質問はありません。環境でアクティブになっている機能/実装について質問がある場合は、構成ファイルを確認してください。
これは、テストと本番の間の調整の単純な問題でなければなりません。 Gitで機能ブランチを使用している場合は、テストサイクル中に完了した機能ブランチのTestへのプッシュを停止し、テストが完了したら再開します。
これよりも優れた制御が必要な場合は、テストを開発サーバーと受け入れテストサーバーに分離し、受け入れチームに受け入れられるブランチをテストチームと調整します。その後、誰かが受け入れテストから本番環境への最終的な展開を開始する責任があります。
積み重なる
これは私の経験では普遍的な問題です。私はそれに対処します：
- 製品所有者による機能リリースの強力な管理
- マージ時にブランチが削除されるようにする
- 進行中の作業を制限する（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）でのみ解決できます。したがって、2つの異なるブランチで同じ競合を解決し、おそらくマージごとに異なるコードを生成することになります。将来的に、テストチームが機能を2回テストする必要があることがわかります：testreleaseブランチ。マージごとに異なるバグが発生する可能性があるためです。
もう1つの問題はtestブランチです。時々このブランチを「リサイクル」（masterから削除して新しいブランチを作成）する必要があります。古いブランチ（または古いマージ、削除されたマージされたブランチ）は、新しいコードの問題、masterの内容とは大きく異なる。このとき、testで再びマージするブランチを制御する必要があります。
本当に最善の解決策は、ビジネスチームが次のバージョンで何を提供する必要があるかを理解し、全員が独自のブランチ（開発ブランチ）で作業することです。彼らにとっては、いつでも次のバージョンに含めたい「完了した」機能を選択できる可能性があります（これはあなたのシナリオだと思います）が、これは開発者にとっては悪夢であり、テストチーム。
あなたのように聞こえますmerging統合ブランチから本番ブランチへの変更です。あなたが言及した理由から、IMHOは良い習慣ではありません。特定のリリースの本番ブランチがメインの統合ブランチからプルされるとすぐに、統合ブランチはいつでも分岐できます（すべてが次のリリースに進化するはずですが）。統合ブランチから現在のリリースブランチにマージすると、そのリリースと互換性のない変更が発生する可能性があります。
私見適切なプロセスは次のとおりです。
- 望ましいレベルの品質に十分に近いと思われる場合にのみ、統合ブランチから本番ブランチをプルします。これにより、ほんの一部の変更のみがリリースを完了することがさらに期待されます。つまり、本番ブランチをプルする前に、統合ブランチで機能の完了を（継続的に）評価する必要があります。
- 本番ブランチがプルされた後、チェリーピックの変更のみがもたらされ、スタンドアロン/ポイントフィックスの変更として扱われます。つまり、実際に期待どおりに機能することを確認します（1つのブランチで変更が機能しても、必ずしも機能するわけではありません）別のブランチで）。
個人的には、これはツールの問題ではなく、プロセスの問題である可能性があるようです。ここで私が提案するいくつかのこと：
- 開発グループとQAグループが別々かどうかはわかりません。その場合は、DevとQAの両方がスプリントの計画と見積もりの会議に参加していることを確認してください。私の以前の会社の1つでは、ストーリーに割り当てたストーリーポイントの数が、開発とテストの両方の労力を占めていることを確認しました。 （理論的には、開発とQAの作業について2つの別個の見積もりを行うこともできますが、どちらの方法でも見積もりに両方を含める必要があります。ストーリーに必要な時間は、実際に配信するために必要な時間です）。個別のQAグループがない場合でも、テスト作業を見積もりに含めるようにしてください。
- 上記と同様に、特定のスプリントに含めるストーリーの数について事前に合意します。受け入れるストーリーポイントの数は、開発者がスプリントで終了できる量およびに基づいて、QAがスプリントでテストできるアイテムの数に基づいています。 （もちろん、QAスプリントはDevスプリントの背後にあると想定していますが、これをプロセスに適合させることができます）。開発者が200ストーリーポイントを完了できても、QAが150ストーリーポイントしか完了できない場合、作業が「山積み」になり、説明したようなケースに終わる前に、150ストーリーポイントしか実行できないことは明らかです。 （このような場合、ロードブロッキングの原因を調査して、それを軽減しようとすることができます）。
- 現在QAにあるすべてがテストされるまで、誰もQAに何かをプッシュすることはありませんおよび配信。
- 完全な機能は、テストされ、提供された機能の1つです。配信されない場合は行われません。
- 明らかに、これをある種の固定されたスケジュールで実行したいと考えています。継続的インテグレーションとアジャイルの背後にある全体的なアイデアの1つは反復です。定義により、反復は頻繁な配信を伴います。頻繁な統合と配信により、それぞれのリスクが最小限に抑えられます。
正直なところ、最大のことは、いつ配信するか、特定の時間内に実際に完全に完了することができるタスクの数についての規律だと思います。
まとめると、古い機能のテストと配信が完了したときにのみ、QAに配信します。