私たちの開発/リリース サイクルは次のように機能します。
- 開発者は機能ブランチを作成し、機能を実装します
- 開発者は、機能が受け入れテスト (UAT) の準備ができていることを示します
- テスターがフィーチャー ブランチをデプロイし、フィーチャーを受け入れる (または拒否する)
承認された機能はテスターによってマスター ブランチにマージされ、次のリリース サイクルでリリースされます (トランク/マスター コードは毎週デプロイされます)。
テスターが機能を UAT し、それが完全にマージされないことを発見するまでに、その作業を行っていた開発者は通常、別の作業に移っているため、マージの競合に不満を感じています。
TeamCity によってすべてのフィーチャー ブランチが現在のマスター ブランチに対して自動的にマージされ、マージの競合が発生したビルドは失敗したビルドと見なされるソリューションを検討しています。これにより、問題のあるマージを早期に確認できるため、修正できます。それらをより早く。
TeamCity には、このワークフローのサポートが組み込まれているようには見えません (つまり、プッシュがブランチ X に発生した場合、マスターをチェックアウトし、ブランチ X をマージし、ビルドし、単体テストし、パッケージを作成します)。TeamCity と Github を使用して、おそらくカスタム msbuild ターゲットを使用して、同様のワークフローを作成した人はいますか?
編集: Github を使用しているが、現在プル リクエストを使用していないことを明確にする必要があります。これは調査する必要があるようです。:)