同僚と私は、ビルドするたびに、現在のgitリポジトリから派生したバージョンをコードに統合することの問題/メリットについて、交互に議論/議論しています。
メリットは次のとおりです。
(私たちにとって)発生した問題は次のとおりです。
ですから、私たちは他の人がこの論争にぶつかったところに興味があります。議論が逸話になるのは本当に簡単です。エンドツーエンドの自動化にこだわり、事前の作業とそれが作成するカップリングの量を掛ける人はたくさんいます。そして、議論の反対側には、他の多くの人たちがいます。彼らは、最も簡単なことを行い、リスクを持って生きています。
どちらの側に上陸するのが最善であるかについての合理的な答えはありますか?
バージョンタグでは git describe を使用します。フローは基本的に次のとおりです。
git describe
git describe
は、タグ名、タグ以降のコミット数、およびタグのハッシュを提供します。タグの例は次のようになります。
v1.1.2-6-a3b27gae
これには開発者がハッシュを取得するという利点があるため、ビルド間で何かが壊れた場合、開発者は簡単に変更を比較できます。また、管理も簡単です。チームリーダーに新しいバグ修正ブランチでタグを作成してプッシュさせるだけで、残りはビルドシステムが処理します。
ユーザーがバージョン番号を理解しやすくなるため、ハッシュ(およびビルド番号)を削除します。これにより、リリースを設計するときに十分な関連情報を提供しながら、両方の利点を得ることができます。
現在、これはもう少し複雑なバージョンですが、アイデアは残っています。
以前はSVNショップだったので、この計算は簡単でした。ビルド番号はSVNのリビジョンでした。 DCVSへの移行を開始したとき、私たちはこれを継続しようとしましたが、いくつかの理由で失敗することがわかりました。
まず、rev 69bc333bc8d8がrev 25b0f0d1052cの前、後、または同時であるかどうかは誰が知っていますか? 101が100を超えていることを少なくとも知っていれば、SVNシステムと比較してコンテキストはほとんどありません。次に、DCVSソース管理の性質により、その後のビルドで同じボールが進行しない場合、多くの点で非線形になります。
ビルドサーバーは適切な可視性と処理能力を備えていたので、ビルドサーバーを使用してビルド番号を配布することにしました。
Git status、log、diffの出力を実行可能ファイルに直接リンクしています。次に、それを印刷するオプションがあります。利点は、バイナリのビルド元であるブランチだけでなく、コミットされていないソースコードの変更が含まれていることを把握できることです。見てください:
https://github.com/colding/MercuryFIX/tree/master/stdlib/scm_state
これら3つのファイルを使用して、独自のSCM状態libを作成できるはずです。
C#DLLのビジュアルスタジオビルドシステムに次のスキームを使用して、バージョン番号を自動的に生成します(これまで、デプロイメントが正しく実行されないという問題があったため、デプロイメントを保証するクリーンな方法が必要でした正しいバージョンが発生しました)。
これは、2つの互換性のある16ビットの符号なしの数値で遊ぶことを前提としています。より小さい数を使用する同等のシステムを作成することもできます。
また、数値以外のフィールドは、メタデータとして添付できる場合に役立ちます。たとえば、情報バージョン番号としてgitバージョン番号を追加します。
Autorevision の使用をお勧めします。
cスタイルのヘッダー など、さまざまな形式で出力を取得できます。
誰がどのように構築しているかに関係なく、tarballから構築している場合でも、常に同じバージョン情報を取得できるように、接続する方法のいくつかの例(contribs dir)もあります。
また、git
に加えて、Autorevisionはsvn
およびhg
と連携して動作するため、一度設定すると、あまり変更しなくても、svnから簡単に切り替えることができます。