7

バックグラウンド：

Production毎晩成果物を作成するためのJenkinsの仕事（）が1つあります。ProductionPush翌日、プロプライエタリプロトコルを介して成果物を本番マシンにプッシュする別の仕事（ ）があります。これは、一部の実稼働マシンが1日の特定の時間にのみ使用可能であるためです（これにより、土壇場でのビルドの中断を修正する機会も得られます）。 ジョブProductionPushによって作成された成果物にアクセスする必要があります（したがって、同じワークスペースにアクセスする必要があります）。Production複数のノードと同時ビルド（したがって予測できないワークスペース）があり、リソースがいくらか制限されているため、ジョブを固定ノード/ワークスペースに結び付けないことを好みます。

質問：

  1. 両方のジョブが同じワークスペースを共有し、成功ProductionPushした場合にのみ翌日の決まった時間Productionに実行されるようにするには、両方のジョブを同じノード/ワークスペースで実行するように修正する必要はありませんか？パラメータ化されたトリガープラグインがこれの一部に役立つ可能性があることは知っていますが、時間遅延機能がないようで、12時間は静かな期間には長すぎるようです。

  2. ワークスペースを共有するのは悪い考えですか？

4

2 に答える 2

25

回答2：はい、ワークスペースを共有することは悪い考えです。ファイルロックの可能性があります。ワークスペースが消去されるという問題があります。しないでください...

回答1：必要なのは、ビルドのアーティファクトをアーカイブすることです。このように、特定のビルドのアーティファクト（ビルド番号別）は、別のビルドが実行されているかどうか、またはワークスペースがどのような状態にあるかに関係なく、常に利用可能です。

アーティファクトをアーカイブするには

  • ビルドジョブの[ビルド後のアクション]で、[アーティファクトのアーカイブ]を選択します
  • アーカイブするアーティファクトを指定します（以下の組み合わせを使用できます） a）
    すべてをアーカイブできます：*.*
    b）ワイルドカードを使用して特定のファイルをアーカイブできます：/path/to/file_version*.zip
    c）次のような中間ディレクトリは無視できます：**/file_version*.zip
  • 多くのアーティファクトに関するストレージの問題を回避するには、構成の上部で[古いビルドを破棄]を選択し、[詳細設定]ボタンをクリックして、アーティファクトを保持する日数とアーティファクトを保持するビルドの最大数を試してみてください。これらの2つの設定は、実際のビルドが保持される期間を制御しないことに注意してください（他の設定がそれを制御します）

Jenkinsのアーティファクトにアクセスするには

  • ビルド履歴で、必要な以前のビルドを選択します。
  • SCMの変更およびリビジョンデータに加えて、ビルドアーティファクトリンクがあり、その下にその特定のビルドのすべてのアーティファクトがあります。
  • たとえば、Jenkinsのパーマリンクを使用してそれらにアクセスし
    http://JENKINS_URL/job/JOB_NAME/lastSuccessfulBuild/artifact/、次にアーティファクトの名前を使用することもできます。

別のジョブのアーティファクトにアクセスするには

ここでは、別のデプロイジョブ（この例ではProductionPush）から以前のアーティファクトにアクセスする方法について詳しく説明しました：
Jenkinsの別のジョブから特定のビルド番号をプロモートする方法は？

要件が常に最新のビルドを本番環境にデプロイすることである場合は、上記のリンクでプロモーションの構成をスキップできます。デプロイジョブの設定手順に従ってください。デプロイジョブを取得したら、それが常に同時に実行される場合は、定期的にビルドパラメーターを構成するだけです。または、必要な条件に基づいてデプロイジョブをトリガーする別のジョブを作成することもできます。

上記のいずれの場合でも、デフォルトセレクターが最新の正常なビルドに設定されている場合（上記のリンクで説明されているように）、最新のビルドが本番環境にプッシュされます

于 2013-03-04T18:46:23.873 に答える
0

アーティファクトをアーカイブすることが本当に良い考えかどうかはわかりません。ステージングリポジトリは、Mavenのsettings.xmlファイルを微調整することで、必要に応じて部門の枠を超えたチームが異なるビルド間でアーティファクトを共有できるため、より優れている可能性があります。

ビルドされ、テストされ、ビルドの信頼性が高くなった時点で本番環境にプロモートされるものとして、デプロイ可能な（ear / war）が本当に必要です。

デプロイ可能なビルド番号（major.minor.buildnumber）を使用します。これは、テストが信頼できるものであれば、本番環境にプロモートするものです。マイナーをビルド番号で区切るためにハイフンを使用しないでください。Mavenが字句比較を実行するように強制されます...小数点を使用すると数値比較が強制され、頭痛の種がはるかに少なくなります。

また、ターゲットプラットフォームについては言及していませんが、Maven APT/RPMプラグインを使用してAPT/RPMを本番ボックスで使用可能なAPT/YUMリポジトリにプッシュする（テストが成功した後！）ので、適切です。業界標準ごと？

于 2014-03-30T00:09:37.130 に答える