マルチリポジトリ環境でのパッケージおよびバージョン戦略

私たちは、独自のgitリポジトリを管理する複数のチームを持つ小規模企業です。これはWebプラットフォームであり、各チームの成果物は夜間テストのために1日の終わりに展開されます。バージョン管理とパッケージングに関するプロセスを形式化しようとしています。

すべてのチームには、日々の開発を行うマスターブランチがあります。各チームの品質保証メンバーは、チームの変更による成果物を、すべてのコンポーネントがシェフによって結合されるテストベッドに展開することを望んでいます。アーティファクトはtarballですが、それらをRPMに変換して、バージョンについて正しく考え、推論できるようにします。

リリースプロセスには、各gitリポジトリの開発ブランチ（ほとんどの場合マスター）からリリースブランチを切り離すことが含まれます。これは、成果物のセットでテストとサインオフを実行する品質保証に与えられます。

たとえば、これは関連するリリースブランチを持つ典型的なgitリポジトリです。

 0-0-0-0-0-0-0-0-0-0 (master)
   |           |
   0           0
 (rel-1)       |
               0
            (rel-2)

開発ブランチから来るパッケージのバージョン管理を実行するスキームを見つけようとして立ち往生しています。各リポジトリのmasterブランチに過度にタグを付けたり、タグをリリースブランチのみに制限したりするのは望ましくありません。ただし、標準のyum / rpmセマンティクスを使用して、テストマシンにデプロイされたパッケージを照会できる必要があります。masterブランチにタグがない場合、開発バージョンはどのようになりますか？私git describeはビルドバージョンの有用な表現を提供できることを理解していますが、ブランチ上のさまざまなリリースポイントがタグ付けされている場合はうまく機能します。

EDIT1：@ Urban48の回答に応えて

リリースプロセスについてもう少し説明する必要があると考えました。この議論のためにmaster、すべてのリポジトリにブランチがあると仮定しましょう。このmasterブランチは開発ブランチと見なされ、CI-CD対応の自動化されたQA環境に展開されます。これは、マスターの安定性を確保するために夜間テストのサブセットが実行される場所です。リリースブランチをカットする前に、このジョブのパイプラインを確認します。リリースブランチは短命です。リリースブランチを（安定したマスターから）カットした後、完全なリグレッションが実行され、修正が行われ、運用環境に展開されたとします。これには約1週間かかります。ほぼ2週間ごとに実稼働環境にリリースします。

機能ブランチは常にマスターから切り離され、CI-CD安定性チェックを受けるマスターとマージする前に、ある程度の開発者テストを受けます。

修正プログラムは（リリースブランチからカットされた）修正プログラムブランチで作成され、本番環境への影響を最小限に抑えて展開されます。

リリースおよびホットフィックスブランチのバージョン管理戦略は、semverに従います。QAサイクル中のリリースブランチはv2.0.0-rc1、v2.0.0-rc2などのバージョンを通過し、最終的にQAサインオフがになりv2.0.0ます。

バージョンがになるリリースブランチ（およびマスター）にマージされる小さな機能のドットリリースを行うことがありますv2.1.0。また、ホットフィックスはv2.1.1パターンを想定しています。

ただし、問題はこれらのブランチをバージョン管理することではありません。このバージョン管理スキームをまったく変更しないことをお勧めします。唯一の変更点は、開発ブランチ、つまり 主人。CI-CD環境で、以前のリリースから実稼働環境に存在するバージョンを確実に示す方法を教えてください。これは、理想的にはスマートgitタグ付けによって行われますが、masterブランチに過度にタグ付けしないものが推奨されます。

うーん、まあ、テクノロジーにとらわれないかもしれない.netの例があります。

簡単に要約します。

• gitflow分岐戦略を使用したコンポーネントごとのgitリポジトリ

• 開発するすべてのコミットメントは、チーム都市の構築をトリガー

• teamcityビルドは、手動メジャーマイナー+ AssemblyInfo.csのビルド番号、つまり1.1.hotfix.buildでバージョンを修正します

• teamcityは、nuget公開ライブラリと同じバージョン番号を使用してnugetパッケージ化をトリガーします

• octopusは手動テストのために完成したビルドをqaにデプロイします（すべてのテストに合格したと仮定）

• すべてが正常であれば、タコを介して手動でバージョンを本番に展開します。

これは、多くのバージョン管理されたパッケージが浮かんでくるという意味です。-prereleaseフラグを使用して実験を行いましたが、これには、preleaseから「通常の」ステップへのパッケージの手動移動と、それらに依存するコンポーネントの再ビルドの要件が必要でした。

重要なことは、すべてのビルドを何らかの中央プロセスを介して一意にバージョン管理することです。

次に、「omg、どのバージョンを持っていますか？」ではなく、「うーん、どのバージョンが欲しいですか」という状況にあります。

編集：コメントを再。

その重要なことを本当に強調するためです。完成したソフトウェアを構成するブランチと、ALLがコミットするバージョンを決定します。このブランチからバージョン管理されたソフトウェアのみを展開します。

しかし、私の考えでは、分岐戦略に取り組む必要があります。

• 機能（または開発）ブランチをバージョン管理しないでください。
• バージョンマスターを行う
• マスターからのパッケージのみを使用する

バージョン管理の問題を解決したり、ソリューションに向けてより多くの方法を考えたりするのに役立つ代替ワークフローを提供します。

最初に少し哲学を..
（あなたのワークフローについていくつかの仮定をしている、私が間違っている場合は私を修正してください）

1. テストは遡及的に実行されます：

   外ブランチmaser、機能ブランチに続いQAでテストするために人工物にそれを回します。
   問題は次のとおりです。テストが失敗した場合master壊れる可能性があります！

   副作用：

   • 開発者が信頼できないようにする master

   • マスターブランチからリリースブランチに分岐しているので、以前のリリースが壊れている場合はどうなりますか？マスターが再び修正されるまで、新しい機能の統合を停止します。

   • リリースブランチでバグが修正されたmaster場合、マージしてからマージの競合が発生する可能性があります。（そして、私たちは対立が好きではありません）

2. 小さなコードのマージと修正：

   master特定の機能の一部ではない小さな修正や変更など、にマージされるすべてのコードを追跡するのは困難です。

   副作用：

   • 開発者は、この小さな修正を今すぐマージするか、後でマージするかはわかりません。

   • この新しい小さな修正もバージョン管理する必要がありますか？

   • どの時点でも、masterブランチの状態と、そこに浮遊しているコードは明確ではありません

   • 何かがビルドを壊したが、それは新機能の一部ではない。それがどこから来たのかを追跡するのは本当に難しい

gitワークフローの私のアイデアは次のとおりです。

master既に行っているように、新しい機能の開発のために分岐します。しかし、この新しく作成されたブランチからリリースする代わりに、この機能を選択してreleaseブランチにマージします。

これで、特定のリリースに含まれる内容をより適切に制御できます。
開発バージョンと安定バージョンを簡単に分離できるようになりました。

QAのために、これらの機能ブランチから成果物を構築し続けることができます。
すべて問題なければ、その機能をマージしてmaster、この機能/バグ修正/ホット修正をリリースブランチにチェリーピックします。

バージョン管理
機能ブランチのバージョンでは、次のような名前規則を使用できます。1.2.3-rc.12345

releaseブランチ内のバージョンは使用するだけです1.2.3 （1.2.3> 1.2.3-rc.12345心配することも1つ少ない）

このワークフローは、上記の問題などを修正します。
また、健全なバージョン管理戦略を提案し、このリリースサイクルのほとんどを自動化できます。

私はそれが何らかの形であなたを助けることを願っています、私はあなたが思いつくことができるどんなエッジケースも喜んで議論します。

ps：
私の主言語ではなく、英語をおpoびします。

あなたのプロセスは非常に複雑で、ビット数のタグを取得することは避けられないようです。

2つのアイデアが思い浮かびます。

1. 「マスター」ブランチは、通常「開発」ブランチにあるものとして扱います。これにより、メッセージブランチが大幅に汚染されます。

2. QAがジョブを完了すると、使用中のすべてのリポジトリのタグを含むレポート（テキストファイルなど）をビルド/ CIサーバーに作成させることができます。これで、リポジトリに投稿できるバージョンのファイルが作成されます。次に、リリースバージョンのみでブランチにタグを付けます。個々のコンポーネントのバージョンを確認する場合は、レポートを確認できます。