web-dev-qa-db-ja.com

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

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

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

                     ▲       ▲       ▲
                     │       │       │

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

                     ▲       ▲       ▲
                     │       │       │

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

各環境には、独自のブランチ（ git を使用）と、そのブランチを使用する独自のビルドがあります。ある環境から別の環境に、たとえばDEVからQAにプロモートする場合、masterブランチをqaにマージし、新しいQAビルドを開始します（これは次に自動的にデプロイされます） QA環境）。

専用のブランチを用意せずに、各環境用に構築する新しいプロセスへの移行を検討しています。代わりに、1つのリリースビルドで「展開パッケージ」が作成され、その後、任意の環境に展開できます。典型的なワークフローは次のようになると想像しています。

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

                      ▲ 
                       \ 

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

                                ▲
                                │

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

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

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

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

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

私たちが検討しているいくつかのオプション：

  • gitタグ を利用して、どのコミットがどの環境にあるかを追跡する
  • ビルドで使用されるgit commitを各デプロイメントパッケージに埋め込む
version-controlgitdevelopment-processdeploymentdevelopment-environment
14
Nathan Friend

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 plugin があり、以下を含む同様の環境変数のセットを提供します。

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

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

14
user40980

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

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

非アクティブ化/アクティブ化は 機能の切り替え によって行われます。

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

機能を一緒にマージするのに苦労はありません。なぜなら、ブランチがないため、マージする必要がないからです。どのブランチにどの機能があり、おそらく他のブランチの機能に依存したり衝突したりすることに混乱はありません。すべてのパーツを自由にアクティブ化できます。 ロールバックも不要になりました：スイッチのフリップだけです。

それがあなたのコードベースでうまくいくかどうかはわかりません：コードの品質と開発者の規律に関する前提条件は非常に高いです-機能はコア機能になり、manageする必要がありますトグルの束は、より大きな混乱を防ぎます。

おそらくそれはあなたのために働く。

3
Thomas Junk