Gitバージョンをビルド番号として統合するかどうか

同僚と私は、現在のgitリポジトリから派生したバージョンをビルドするたびにコードに統合することの問題/メリットを交互に議論/議論しています。

メリットは次のとおりです。

• バージョン番号を更新する際に人的エラーを心配する必要はありません
• デバイスで見つかったものと、そのソースコードのソースコードとの間のトレーサビリティ

（私たちにとって）発生した問題は次のとおりです。

• IDE派生ビルドシステム（MPLABXなど）は、これらの種類のフックをどこに配置するのかを把握するのを難しくする可能性があります（最終的にはかなり安っぽくなります）
• これをビルドスクリプト/メイクファイルに実際に統合するためのさらなる作業
• 特定のビルドアプローチ（たとえば、1人がXCodeと他のMPLABXを使用してビルドした場合）へのカップリングは、ダウンストリームのサプライズを作成する可能性があります

だから私たちは他の人がこの議論に上陸した場所に興味があります。議論が逸話になるのは本当に簡単です。エンドツーエンドの自動化に固執し、先行作業とそれが生み出すカップリングの量を掛ける人が大勢います。そして、議論の反対側には多くの人がいます。彼らは、最も簡単なことをして、リスクを抱えて生きています。

どの側に着陸するのが最適であるかについて、合理的な答えはありますか？

バージョンタグでgit describeを使用します。フローは基本的に次のとおりです。

• 作業中のバージョンのタグを作成します（例v1.1.2）
• すべてのビルド実行 git describe
• 出荷時には、タグ名を使用します

git describeタグ名、タグ以降のコミット数、タグのハッシュを提供します。サンプルタグは次のようになります。

v1.1.2-6-a3b27gae

これには、開発者がハッシュを取得するという利点があります。そのため、ビルド間で何かが壊れた場合、開発者は変更を簡単に比較できます。また、管理するのも愚かです。チームリーダーにタグを作成して新しいバグ修正ブランチにプッシュさせるだけで、残りはビルドシステムが処理します。

ユーザーがバージョン番号を理解しやすくするため、ハッシュ（およびビルド番号）を削除します。これにより、リリースのエンジニアリング時に十分な関連情報を提供しながら、両方の長所を活用できることがわかりました。

現在、これのもう少し複雑なバージョンがありますが、アイデアは残ります。

以前はSVNショップだったため、この計算は簡単でした。ビルド番号はSVN revでした。DCVSへの移行を開始したときにこれを継続しようとしましたが、いくつかの理由で失敗することがわかりました。

まず、rev 69bc333bc8d8がrev 25b0f0d1052cの前、後、または同時であるかどうかを誰が知っていますか？少なくとも101が100の後だったことを知っていた場合、SVNシステムに比べてコンテキストはほとんどありません。次に、DCVSソース管理の性質により、後続のビルドが同じボールを進めない場合、多くの点で物事が非線形になります。

ビルドサーバーを使用して、ビルド番号を適切な可視性と処理能力を持っていたため、ようやくビルド番号を配布することになりました。

C＃DLLのVisual Studioビルドシステムに次のスキームを使用して、バージョン番号を自動生成します（これまで、展開が正しく実行されないという問題があったため、正しいバージョンの展開を保証するクリーンな方法が必要でした）。

• メジャー-ハードコード1、通常はビジネス側で決定
• マイナー-ハードコードされた0、通常はビジネス側によって決定されます
• 改訂-2010年1月1日以降の日数（またはその他の任意の開始日）
• ビルド-真夜中からの秒数の半分（16ビットの符号なしの数値なので）

これは、再生可能な2つの16ビットの符号なし数字を使用できることを前提としていることに注意してください。より小さい数値を使用する同等のシステムを作成することもできます。

また、非数値フィールドは、メタデータとして添付できる場合に役立ちます。たとえば、gitバージョン番号を情報バージョン番号として追加します。

git status、log、diffの出力を実行可能ファイルに直接リンクしています。次に、それを印刷するオプションがあります。利点は、バイナリがどのブランチからビルドされたかを把握できるだけでなく、コミットされていないソースコードの変更が含まれていることです。見てください：

https://github.com/colding/MercuryFIX/tree/master/stdlib/scm_state

これら3つのファイルを使用して、独自のSCM状態ライブラリを作成できるはずです。

Autorevisionの使用をお勧めします。

cスタイルヘッダーなど、さまざまな形式で出力を取得できます。

また、tarballからビルドしている場合でも、誰がどのようにビルドしているかに関係なく、常に同じバージョン情報を取得できるように、物事をフックする方法の例（contrib dir）があります。

また、に加えて以来、gitAutorevisionで動作svnし、hgそれはあなたがそれを設定したら、あまり変更することなく、SVNから離れて切り替えることが容易になります。