Maven、Teamcity、TFSでの分岐戦略

Question

私たちはビルドプロセスをより効率的に更新することを任されており、ベストプラクティスと戦略を読んで1週間を過ごしましたが、現在の問題の解決策はまだ見つかりませんでした。

背景

現在、我々は実際にいくつかの共有ライブラリと、少なくとも4つのアプリケーションに離れて分割する必要が1つのモノリシックビルド/アプリケーションがあります。私たちは絶対にしなければ現在は分かれていません。 TFSへの各チェックイン時に構築されるチームシップビルドがあります。リリース準備が整うと、コードフリーズが発生し、QAで見つかったバグのチェックインのみが修正されます。明らかにこれはひどい練習であり、私たちはついにそれを変更する承認を得ました。

提案されたソリューション

提案されたソリューションは、アプリケーションを分割し、各アプリケーションごとに異なるリリースサイクルを持ち、Mavenとリリースごとにブランチする蟻から移動することになります。

ブランチ - 今はソースコントロールにメイントランクがあります。リリース準備ができたらトランクから分岐し、QAで見つかったバグのブランチを更新したいと思う。ビルドがリリースされる準備ができたら、ブランチの変更をトランクにマージして戻します。

TFSを設定する方法は次のとおりです。

+Apps 
    +App1 
     +Components 
      +Core 
      +Web 
     +Branches 
    +App2 
     +Components 
      +Core 
      +Web 
     +Branches 
    +Libraries 
     +Lib1 
     +Lib2 
     +Branches 

POMのすべてのPOMとバージョンを管理することは今のところ難しいようです。私はmaven releaseプラグインを読んだことがありますが、私が望むと思っている方法で分岐できるかどうかはわかりません。

次の問題は、チームシティが働いていることです。私は、各アプリごとに3つのチームシティープロジェクトを持つことを考えていました。トランクを常に指し示す開発プロジェクト、QAビルドをテストするためのQAプロジェクト、および修正プログラムの変更をビルドするためのプロダクションプロジェクト新しいリリースがQAにな​​るたびに、QAチームシティプロジェクトを更新して、新しいリリースブランチをポイントし、チームビルのリリースビルド番号を更新する必要があります。そのリリースがQAを通過するとき、QAをちょうど通過したブランチとQAを通過したビルド番号にそのビルド番号を更新するように、プロダクションチームシティプロジェクトを更新する必要があります。

確かにこれが良い戦略です。

質問

私はこれらの枝のフォルダを置くべきか？

QAビルドは、ビルド前にスナップショットを作成する必要がありますか？

各リリースのソースパスを変更せずにこれらのブランチをピックアップするにはどうすればよいですか？

開発者がすべての依存関係をコンパイルして最新のものにするために使用する、各アプリケーションの親POMがあるべきですか？

Answer 1

私はあなたのアプリケーションが異なるリリースサイクルにあるべきであるというあなたの考えを疑問に思っています。モジュール化はコード品質にとっては良いことですが、モジュールが別々のリリースサイクルにある場合、オーバーヘッドが大きくなります。特に、バージョン管理は非常に負担になります。間違ってしまうと、ランタイムバグを導入することができます。

これらの別々のアプリケーションは、どのように互いに関連していますか？それらの間に（おそらく共有ライブラリを介して）依存関係はありますか？彼らはお互いにコミュニケーションしていますか？彼らは一緒に展開されていますか？

が必要な場合は、別々のリリースサイクルになるようにすることをお勧めします。