3

Borland の StarTeam を介してソース管理を行う不幸な機会があります。残念ながら、うまく機能することはほとんどなく、最大の弱点の 1 つはビューの管理です。私は SVN が大好きで、SVN の考え方から来ています。私たちの問題は、ポスト プロダクション リリースで、変更を「プロダクション サポート」環境にマージするのに数え切れないほどの時間を費やしています。

嫌がらせをしないでください、これは私のしたことではありません。私はそれを継承し、リポジトリを管理するためのより良い方法を提示しようとしています. 別の SCM ツールに切り替えることはできません。

現在のセットアップ

  • Product.1.0 (TRUNK、現在の製品コード、およびこのレベルでは保留中のバグ修正)
    • Product.2.0 (真のトランク チェックインされたものはすべてテストされ、次の生産サイクルでリリースされます。このビューでは多くの変更が発生します)

私の提案は、それらを交換し、すべての開発をトランク (本番) で行い、リリースにタグを付け、必要に応じて、本番サポートのバグ修正を表す子ビューを作成することです。

  • 製造
    • Production.2.0.SP.1

上記の提案をサポートするドキュメントが見つからないため、変更が良いアイデアであるかどうか、および別の方法をお勧めするものがあるかどうかについてフィードバックを得ようとしています.

4

3 に答える 3

3

私は、HenryKnibergの記事「複数のアジャイルチームのバージョン管理」に触発された中間的なアプローチを使用しています。私は以下の小さな部分を引用しています：

大きな絵

OK、これで、このパターンを使用する方法のかなり詳細な例を確認しました。それでは、少し戻って全体像を見てみましょう。

メインラインモデルでは、ブランチはコードラインと呼ばれます（実際、ブランチはコードラインの実装と見なされます）。これらはストリームと呼ばれることもあります。

コードラインの親（つまり、コードラインの元となったコードライン）は、そのベースラインと呼ばれます。メインラインは、ベースラインのないコードラインです。

したがって、上記の例では、次のように結論付けることができます。

  • トランクは私たちのメインラインです。親権はありませんか？
  • 他のすべてのコードライン（リリース1.0、チームAの作業、チームBの作業）には、ベースラインとしてトランクがあります。

より複雑な例を次に示します。

代替テキスト
（出典：infoq.com）

この写真は次のことを示しています。

  • プロジェクトXのコードラインはメインラインから生成されました。プロジェクトが完了したので、ブランチは閉じられます。
  • チームAには、メインラインから生成されたアクティブな作業ブランチがあります。
  • チームAには、作業ブランチから生成された継続的なスパイクもあります。
  • 2.3は本番環境ではなく、保守されないため、リリース2.3ブランチは閉じられています。

各コードラインには、そのベースラインに対して相対的な堅さのレベルがあります。つまり、各コードラインは、そのベースラインよりも堅い、または固くない（柔らかい）かのいずれかです。

  • しっかりしたコードラインは安定しており、徹底的にテストされており、変更されることはめったになく、リリース間近です。
  • ソフトコードラインは不安定で、ほとんどテストされておらず、頻繁に変更され、リリースにはほど遠いです。

コードラインを描画する場合、しっかりしたコードラインは上向きに分岐し、ソフトなコードラインは下向きに分岐します。したがって、上の図を見ると、次のように結論付けることができます。

  • リリース2.3はメインラインよりも堅固です。
  • チームAの仕事はメインラインよりもソフトです。
  • チームAのスパイクは、チームAの作業よりもソフトです。

要約する：

  • トランクはDONEブランチです（常にリリース可能）
  • 作業は、トランクよりも安定性が低い可能性がある作業ブランチ（チームごとに1つ）で行われます。
  • リリースブランチは、リリース時のトランクに基づいて作成されます。

記事全体を読むことを強くお勧めします。

于 2010-04-14T02:51:35.860 に答える
2

ビルドストリームを構造化するための一般的なアドバイスは次のとおりです。

+HEAD - master -> current development 
+ tags
   + version1 
   + version1.sp1 
   + version1.sp2 
   + version2
+ branches
   + version1.sp2.fixes <- at some point, this will get promoted to version1.sp3 
   + version2.fixes <- at some point, this will get promoted to version2.sp1 
   + version2.nix.feature1 <- this is your (nix's) private version2.feature branch 
   + master.nix.feature2  <- this is your (nix's) private new development feature branch.

基本的に、.fixesまたはmasterブランチに直接コミットすることは決してありません-統合プロセスのみがそれを行います。

とにかく、ほとんどすべてのソース管理ツールがこのモデルをサポートします。

于 2010-04-12T18:39:52.740 に答える
2

あなたと Chris Kaminski のアプローチに同意します。私たちは StarTeam を使用しており、これがその使用方法です。各プロジェクトのヒントまたはメイン ビューは、現在の開発ラインです (StarTeam の用語では、これはプロジェクト名と同じ名前を持つデフォルト ビューです)。このビューでビルドを行うときはいつでも、ビルド サーバーがビルド ラベルを作成します。某ビルドレーベルにてリリースされています。

次に、そのラベルの時点で新しいビューを本番リリース ブランチとして作成し、リリースに対するバグ修正がそのビューに適用されます (バグ修正がヒント ビューで行われ、ブランチにマージされるか、またはその逆であるかは関係ありません)。 、メインの開発ビューにマージされる限り)。

また、特定のプロジェクトが長時間実行され、次の通常の本番リリースまでに完了しない場合は、Branch on Change 設定を使用して Tip ビューから分岐します。これは、完了後に多くのマージを行う必要があるため、理想的とは言えませんが、そのコードをメインの開発ラインから除外し、誤って製品リリースになってしまうことがないようにします。私たちはこれらのタイプのプロジェクトを制限しようとしていますが、時にはビジネス関係者がそれらを指示することもあります.

このセットアップは私たちにとって非常にうまく機能しており、新しい人々にとって理解しやすく、操作しやすいようです.

于 2010-04-14T02:19:32.053 に答える