2

環境：

  • 約 12 のサービス: WAR と JAR の両方 (Tanuki ラッパーで実行)
  • 各サービスは、開発、ステージング、および本番にデプロイされています。環境は、異なる web.xml ファイル、Spring プロファイル (Tanuki ラッパーで設定) などを使用します。
  • AWS S3 にアーティファクトを保存して、EC2 インスタンスで簡単に取得できるようにしたいと考えています。一部のサービスは複数のマシンで実行され、AutoScaling インスタンスは起動後に自動的に最新バージョンを取得し、開発アーティファクトは更新後に自動的にデプロイされる必要があります。 ..

現在の展開プロセスは次のようになります。

  1. Jenkins はコードをビルドしてテストします
  2. 満足したら、Artifactory プラグインを使用してリリースを行います(本番環境のデプロイのみ。開発およびステージング アーティファクトはプレーンな Jenkins ビルドに基づいています)。
  3. 各プロジェクト (開発、ステージング、本番) の 3 つの異なるプロモーション ジョブでプロモーテッド ビルド プラグインを使用して、目的の環境のアーティファクトをビルドし、S3 にアップロードします。

これはほとんど問題なく動作しますが、複数の煩わしさに遭遇しました。

  1. Artifactory プラグインは、リポジトリにコミットできないため、ソース コードにタグを付けて更新することができません (これは、当社の Jenkins プロバイダーであるCloudBeesに固有のものである可能性があります)。気にしないでください。手動で行うことができます。
  2. Jenkins S3 プラグインは、複数のアップロード ターゲットでは正しく動作しません (環境ごとに 1 つ使用しています) - 設定を保存すると、それらすべてにアップロードして設定を複製しようとします: JENKINS-18563。アップロードにはシェル スクリプトを使用していますが、問題なく動作しています。
  3. プロモーション ジョブは、元のビルドとは異なるインスタンスで実行される可能性があるため、失敗することがあります。失敗する (ファイルが見つからないためにビルドされる) か、古いビルドになる (古いバージョンが使用されているため)。繰り返しますが、これは CloudBees が提供する特定のセットアップが原因で発生する可能性があります。これはビルドを再度実行することで修正でき、うまくいけば今回のビルドと同じインスタンスでプロモーション ジョブを実行することができます (これは私の理解では運が良かっただけです)。

ワークスペースは一時的なものであり、ワークスペースが存在することや最新であることが保証されていないため、プロモーション ジョブを実行する前にコード チェックアウトを行うように CloudBees からアドバイスを受けました。ただし、プロモーション ジョブのシェル スクリプトは、textarea フィールドの下にリンクされていても、別のStackOverflow スレッドに記載されているように環境変数を尊重していないようです。だからうまくいきsvn checkout ${SVN_URL} -r ${SVN_REVISION}ません。

これは何らかの回避策で修正できると確信していますが、確かに私は何かひどく間違ったことをしているに違いありません. 他の多くの人が同様の方法でアプリケーションを展開していると思いますが、さまざまな回避策や煩わしさのない、より良い方法があるに違いありません。

最後まですべてを読んでくれてありがとう！

4

1 に答える 1

3

  • あなたが直面する最大の問題は、実際にプロモーションの一環としてビルドを行いたいということです。昇格されたビルド プラグインは、主にビルド​​のアーカイブされたアーティファクトに対していくつかの小さなアクションを実行するか、タグ付けなどのアクションを実行するように設計されています。

    • この設計により、スレーブ上でワークスペースが確実に取得されます。しかし (これは CloudBees 固有ではなく一般的な Jenkins の問題です) まず、取得するワークスペースは、プロモートしようとしているビルドに使用されたワークスペースである必要はありません。かもしれない：

      1. 空のワークスペース
      2. プロジェクトの最新ビルドのワークスペース (プロモートしようとしているビルドよりも新しいビルドである可能性があります)
      3. プロジェクトの古いビルドのワークスペース (プロジェクトの最新のビルドを持つスレーブにアクセスできない場合)

      これらのうちどれが得られるかは、Jenkins クラスターの負荷に完全に依存します。CloudBees で実行している場合、通常、上記の最初の 2 つの状況のいずれかに遭遇する可能性が最も高くなります。

    • したがって、プロモーションに配置するアクションは「自給自足」でなければなりません。たとえば、アーカイブされたアーティファクトを特定のディレクトリにコピーし、コピーされたアーティファクトを使用して「処理」を行います。または、昇格されたビルドからパラメーターを通過するダウンストリーム ビルドをトリガーします。または、ローカル状態を使用せずにリモート サーバーで何らかのアクションを実行します (つまり、ブルー グリーン展開でスイッチを切り替える)。

  • あなたの場合、複数の戦線で戦っています。あなたが戦っている 2 番目の前線は、あなたが Maven と戦っているということです。

    • Maven は、アクティブなビルド プロファイルが異なる、同等ではないアーティファクトを生成することを好みません。
    • Maven はおそらくrelease、JavaScript が縮小され、おそらくデバッグ情報が削除されたアーティファクトのバージョンを生成するプロファイルを使用できます (回避できればより良いでしょう)... しかし、それは 2 つのアーティファクトが同等であるためです。JavaScript が縮小された Web アプリは、縮小されていないものと同様に機能するはずです (縮小によってバグが発生しない限り)。
    • プロファイルを使用して、まったく異なる成果物を構築します。Maven リポジトリにデプロイされる情報の一部としてアクティブなプロファイルが Maven に保存されないため、これは問題です。したがって、アーティファクトの 1 つに対する依存関係を宣言すると、そのアーティファクトがビルドされたときにどのプロファイルがアクティブであったかわかりません。これの一般的な副作用は、複合アーティファクトの一部が開発 DB と通信し、他の部分が本番 DB と通信する、スプリットブレイン アーティファクトになることです。開発者が定期的に実行すると、この悪いコードの匂いがすることがわかりますmvn clean install -Pprod && mvn clean install -Pprod過去にスプリットブレイン アーティファクトによって焼失したため、製品ビルドのビルドに切り替えたい場合。これは悪い設計の兆候であり、Maven の問題ではありません (Maven アーティファクトのアーキテクチャ固有のビルドを作成できるのは良いことですが、それらは独自の問題を引き起こす可能性があります)。
    • 異なるデプロイメント環境用の異なるアーティファクトの作成を処理する「Maven の方法」は、別のモジュールを使用して「汎用」アーティファクトを再パックすることです。悪いアーキテクチャを処理するための Maven の巧妙なアプローチの典型であるように、ターゲットにする環境ごとにリパック モジュールを追加する必要があります...これは、多くの異なるターゲット環境を持つことを思いとどまらせます... (つまり、10 個の webapps/services がある場合デプロイ環境と 3 つのターゲット デプロイ環境では、10 個の汎用モジュールと 3x10 個のターゲット固有モジュールが... 40 個のモジュール ビルドが得られます)、うまくいけば、アーティファクトがデプロイ時に正しい構成を自己検出する方法を見つけることをお勧めします。

  • ソリューションをハッキングする最も安全な方法は、アーカイブされたアーティファクトのコピーに頼ることだと思います。

    1. メインのビルド中に、ビルド中と同じリビジョンをチェックアウトするファイルを作成します。

      echo '#!/usr/bin/env sh' > checkout.sh
echo "svn revert . -R" >> checkout.sh
echo "svn update --force -r ${SVN_REVISION}" >> checkout.sh

      SVN 作業コピーにいることを確認する、作業コピーが正しいリモート URI を使用していることを確認する、不要なファイルを削除するなど、もう少し堅牢なものを書きたいと思うかもしれませんが、

    2. 作成したスクリプトがアーカイブされていることを確認してください。

    3. 昇格プロセスの最初に、アーカイブcheckout.shをワークスペースにコピーしてから、そのスクリプトを実行します。その後のすべてのプロモーション手順を以前と同じように実行できるはずです。

  • より良い解決策は、プロモーション プロセスごとにビルド ジョブを作成し、ビルド パラメーターとして SVN リビジョンを渡すことです (ただし、プロモーション プロセスが既にセットアップされているため、セットアップにはさらに多くの作業が必要になります)。

  • 最善の解決策は、ターゲット環境から正しい構成を検出するアーティファクトを生成するようにアーキテクチャを修正することです。これにより、アーティファクトをまったく再構築する必要なく、必要な各環境に同じアーティファクトをデプロイできます。

于 2013-07-29T09:52:13.840 に答える