0

そのため、管理は Git で販売されています。現在、Perforce を使用して、準備ができたら変更リストをステージからリリース ブランチにマージします。現在のワークフローの利点は、どの機能を製品にするかを選択できることであり、リリース サイクルについて心配する必要はありません。テストが終わるとすぐにすべてが進みます。

Git を使用すると、開発者は開発ブランチまたは独自のブランチで作業します。次に、変更をステージ (テスト) ブランチにマージして、QA がテストできるようにします。
QA のテストが完了すると、PM はこれらの変更をリリース ブランチにマージし、本番環境にデプロイする必要があります。秘訣は、Stage ブランチでおそらく 10 個のテストを行っており、Release にマージする準備ができているのは 1 つだけです。

Stage ブランチ全体をマージしてリリースするのは簡単だとわかっていますが、これは決して起こりません。また、Git のチェリー ピックを使用するのは最悪です。ブランチでマージできなければ、Git を使用する意味はあまりありません。強制的に、チャングルリストをステージからリリースにマージしました。

Git でこれを行うにはどうすればよいでしょうか。
例を挙げていただけますか？

4

1 に答える 1

2

技術的な解決策とその対処方法

ステージ ブランチへのマージを行うときに dev ブランチを保持し、本番環境で必要になったらすぐにその dev ブランチをマージできます。これにより、ステージ ブランチが「ダンプ」ブランチになることに注意してください。そのブランチでのみ行われた変更は、本番環境に到達することはありません。したがって、関連する dev ブランチで修正を行う必要があり、2 つの機能で統合の問題 (マージの競合または論理的な競合) が発生した場合は、それらの dev ブランチをマージする別のブランチが必要になる場合があります。後者の場合、これらの変更は一緒にのみ本番環境にマージできます (競合ソリューションを含むブランチを使用します)。

この方法の欠点

とはいえ、ステージ ブランチにはテストに有効な状態が含まれないことに注意してください。何らかの形で他の機能と関係している機能が存在する可能性があるため、それらの 1 つを他の機能なしでマージすると機能しません。マージ エラーのためにこれを認識している場合もありますが、認識していない場合もあります。

代替: 分離されたテスト

このため、互いに分離された機能をテストすることをお勧めします (たとえば、他のブランチからの変更なしで、その dev ブランチ内の各機能)。そのための環境を含む完全な個別のテストが必要なため、これを行うには余分な労力が必要になる場合があります。ただし、本番環境にマージする方法で機能をテストするのに役立ちます。一方、何かを本番環境にマージしたらすぐに、他の機能を再度テストする必要があります。テスト ベースが大幅に変更されている可能性があります。

結論

次に本番環境にマージされ、この組み合わせでテストできる機能の特定のリストを定義していない限り、私が想像できる完璧な技術的解決策はありません。将来のすべての機能を一緒にテストします。この場合、テスト中に干渉が発生し、機能がマージされるとすぐに失われる可能性があります。または、個別の機能のテストを行い、2 つの機能にマイナスの競合がないことを確認するために、本番環境にマージするたびにそれらを再テストする必要があります。

チームの働き方によっては、開発者が干渉の可能性を念頭に置いておく能力を信頼できる可能性があります。しかし、遅かれ早かれ、これが機能せず、ワークフローが原因でエラーが発生することが起こります。

于 2015-11-18T00:04:49.100 に答える