各環境にあるコードのバージョンをどのように追跡できますか？

私のチームは現在、次のような非常に単純な分岐/展開プロセスを使用しています。

                ┌────────┐ ┌────┐ ┌──────┐
 Environments:  │  DEV   │ │ QA │ │ PROD │
                └────────┘ └────┘ └──────┘

                     ▲       ▲       ▲
                     │       │       │

                ┌────────┐ ┌────┐ ┌──────┐
 Builds:        │  DEV   │ │ QA │ │ PROD │
                └────────┘ └────┘ └──────┘

                     ▲       ▲       ▲
                     │       │       │

                ┌────────┐ ┌────┐ ┌──────┐
 Branches:      │ master │ │ qa │ │ prod │
                └────────┘ └────┘ └──────┘

各環境には独自のブランチ（gitを使用）と、そのブランチを使用する独自のビルドがあります。ある環境から別の環境、たとえばDEVからQAに昇格させる場合、新しいQAビルドにmasterブランチをマージしqaてキックオフします（QA環境に自動的に展開されます）。

私たちは、それぞれの環境に専用のブランチとビルドを持たない新しいプロセスへの移行を検討しています。代わりに、単一のリリースビルドで「展開パッケージ」を作成し、それを任意の環境に展開できます。典型的なワークフローは次のようになります。

                ┌────────┐     ┌────┐     ┌──────┐
 Environments:  │  DEV   │ ──► │ QA │ ──► │ PROD │
                └────────┘     └────┘     └──────┘

                      ▲ 
                       \ 

                        ┌───────────────┐
 Builds:                │ release build │
                        └───────────────┘

                                ▲
                                │

                ┌────────┐ ┌─────────┐
 Branches:      │ master │ │ release │
                └────────┘ └─────────┘

ある環境から別の環境への昇格は、ソース管理で処理されなくなります。むしろ、すでに構築されているバイナリ（「展開パッケージ」）を取得し、それを新しい環境にドロップします。

この新しいシステムにより、ビルドを環境に展開できるようになり、いくつかの利点があります。たとえば、DEVとQAでPRODのバグ修正をテストするのは簡単です。現在のシステムでは、ブランチをロールバックせずにこれを行う簡単な方法を提供していません。これは明らかに避けたいものです。

この新しいシステムの最大の欠点は、どのコードがどの環境にあるかを自動的に追跡する方法がなくなったことです。PRODで修正を行う必要がある場合、現在の運用コードベースと同期する専用ブランチはありません。同じことがQA masterにも当てはまります。進行中の作業をdrせずにQAに迅速な変更をプッシュしたい場合、QA環境の現在の状態を反映するブランチはもうありません。

各環境にどのようなコードがあるのか​​を追跡するにはどうすればよいですか？

検討中のオプション：

• gitタグを使用して、どのコミットがどの環境にあるかを追跡します
• ビルドで使用されるgitコミットを各展開パッケージに埋め込む

Gitタグは、リリースを指定するために本当に使用したいものです。理由は、それらがあなたにとって意味を持ち、状態がデプロイされたコードとビルドサーバーが持つかもしれない情報（ビルド番号など）の間のリンクを素早く認識するために使用できるからです。

それがあなたが探している答えですが、それは問題の半分しか解決しません。もう1つは、「ねえ、これは.[wje]arサーバーにデプロイされたものです。どのビルドから来たのですか？」devとqaまたはprodに異なるバージョンのアプリケーションをデプロイすることは決してありません。正しい？

質問のその部分の解決策は、ビルドサーバーに情報をマニフェストに入れさせることです。私の目の前にあるMavenとsvnの例から来ます。

<manifestEntries>
    <Specification-Title>${project.name}</Specification-Title>
    <Specification-Version>${project.version}</Specification-Version>
    <Build-Number>${build.number}</Build-Number>
    <Build-Id>${build.id}</Build-Id>
    <Svn-Revison>${svn.revision}</Svn-Revison>
</manifestEntries>

これは、maven-war-pluginアーカイブ構成にあります。しかし、他のプラグインでも見つけることができます。次に、ハドソンでは、mavenビルド呼び出しの一部は次のとおりです。

-Dbuild.number=${BUILD_NUMBER}
-Dsvn.revision=${SVN_REVISION}
-Dbuild.id=${BUILD_ID}

これらの定義を設定すると、Mavenがピックアップします。そして、サーバーに展開されているMANIFEST.MFファイルを調べて、そのバージョンを確認するだけです。

gitプラグインがあります。これには、以下を含む同様の環境変数セットがあります。

• GIT_COMMIT -現在のSHA
• GIT_BRANCH -リモートリポジトリの名前（デフォルトはorigin）、その後に現在使用されているブランチの名前（「origin / master」または「origin / foo」など）

これら2つのプラクティスの組み合わせにより、ビルド（shaチェックサムとは異なり、ビルド番号が前に進み、意味を持つため）と、ビルド元の特定のgitコミットを簡単に識別できます。

完全に異なるアプローチは、versions完全にという考えを却下することです。構成可能な動作が異なる「1つのバージョン」しかありません。唯一の違いは、共通のコードベースがあることです。実稼働環境でも、進行中の作業を展開しますが、アクティブ化されません。

違いは、お使いの製品で有効になっている機能の異なるセットに要約されます。

無効化/有効化は、機能切り替えで行います。

利点：リリースプロセス全体が簡素化されます。常にソフトウェアの統合バージョンを提供しています。すべての機能はで常に利用可能ですmaster。追加のブランチは必要ありません。

機能を一緒にマージすることに苦痛はありません。なぜなら、ブランチはマージの必要がないからです。どの機能がどのブランチにあり、他のブランチの機能に依存したり競合したりするのか、混乱はありません。すべての部分を自由にアクティブ化できます。ロールバックでさえ不要になりました。スイッチを切り替えるだけです。

あなたのコードベースでそれが機能するかどうかはわかりません：コード品質と開発者の規律に関する前提条件は非常に高いです- 機能がコア機能になった後、「クリーンアップ」に対処し、トグルの束を管理する必要があります大きな混乱を防ぐ。

おそらくあなたのために動作します。

Mavenを使用して、バージョンをマニフェストファイルに入れます。次に、アプリケーションにWebアプリの場合はバージョンを表示させるか、Webサービスの/ versionエンドポイントを用意します。