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

Question

私たちは、独自の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)

開発ブランチからのパッケージのバージョン管理を実行するためのスキームを見つけようとするのに行き詰まっています。各リポジトリのマスターブランチに過度のタグを付けたくないので、タグをリリースブランチのみに制限します。しかし、標準の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 taggingを介して行われますが、masterブランチに過度にタグを付けないものが好ましいです。

Ewan · Answer

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

簡単な要約をします。

gitflow分岐戦略を使用したコンポーネントごとのgit repo
開発へのすべてのコミットがチーム都市の構築をトリガーする
teamcityビルドは、バージョンを手動のメジャーマイナー+ AssemblyInfo.csのビルド番号、つまり1.1.hotfix.buildで修正します。
teamcityは、nuget公開ライブラリに同じバージョン番号を使用してnugetパッケージをトリガーします
タコは完成したビルドを手動でテストするためにqaにデプロイします（すべてのテストに合格した場合）
すべてが良ければ、タコを介して手動でバージョンを本番環境にデプロイします。

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

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

次に、「うーん、どのバージョンを手に入れましたか？」ではなく、「どのバージョンが欲しいですか」という状況になります。

編集：再コメント。

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

私の見解では、分岐戦略に取り組む必要があると思います。

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

Urban48 · Answer

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

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

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

maserから機能ブランチに分岐し、それをアーティファクトに変換してQAでテストします。
問題は：テストが失敗した場合、masterが壊れている可能性があります！

副作用：
- 開発者を信用しないmaster
- マスターからリリースブランチに分岐するので、以前のリリースが壊れた場合はどうなりますか？マスターが再度修正されるまで、新しい機能の統合を停止します。
- リリースブランチでバグが修正された場合、masterにマージすると、マージの競合が発生する可能性があります。（そして私たちは対立を好まない）
小さなコードのマージと修正：

特定の機能の一部ではない小さな修正や変更など、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つ少なくなります）

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

何らかの形でお役に立てば幸いです。考えられるEdgeのケースについては、喜んで話し合います。

pS：
英語をお詫び申し上げます。英語は私の主要言語ではありません。

John Kouraklis · Answer

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

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

「master」ブランチは、通常「develop」ブランチにあるものとして扱います。これはメッセージブランチを非常に汚染します。
QAがジョブを完了すると、ビルド/ CIサーバーで、使用中のすべてのリポジトリのタグを含むレポート（テキストファイルなど）を作成できます。これで、リポジトリに投稿できるバージョンのファイルが作成されます。次に、ブランチにリリースバージョンのみのタグを付け、個々のコンポーネントのバージョンを確認する場合は、レポートを確認できます。