7

Build Flowプラグインを使用していくつかの Jenkins ジョブを分割しようとしています。これにより、3 つのモノリシック ジョブの代わりに、DSL を使用してダウンストリーム ジョブをトリガーする 3 つの「開始点」が得られます。Build Pipeline プラグインではなく Build Flow を選択したのは、異なるパイプライン間でジョブを共有する (つまり、複数の開始ジョブのワークスペースを 1 つのコンパイル ジョブで共有する) のが非常に難しいように思われたためです。

以前は、Project-PR、Project-DEV、Project-PROD の 3 つのジョブを設定していました。

Project-PR は、プル リクエストが GitHub で発生するたびにビルドされ、単体テストの小さなサブセットを実行するだけで、PR がマージしても問題ないことをすばやく確認できます。

Project-DEV は、フィーチャー ブランチが GitHub でメインの開発ブランチにマージされるたびにビルドされ、手動でトリガーして別のブランチをプルすることができます。ユニットの完全なスイートを実行します-基本的に、すべてがまだ良好であることの健全性チェックです。次に、コンパイルして縮小し、テストのために QA 環境にプッシュし、その QA 環境に対して統合テストの完全なスイートを実行します。このステップは、パラメーター化されたビルドとして構成され、パラメーターは、プル、テスト、およびプッシュするブランチの名前です。そのブランチに固有の QA 環境にプッシュしてセットアップするため、開発にマージすることなく複数の機能を QA できます (つまり、 feature-one.qa.example.com 、 feature-two.qa.example.com )。 .

Project-PROD は手動でのみトリガーされ、完全なユニットと統合テスト スイートを実行し、フロントエンド コード ( Less、JS、および CSS ) をコンパイルおよび縮小し、ビルドされたコードを特別な「リリース ブランチ」にプッシュします。 Jenkins がデプロイを担当する段階にはまだ達していません。

さて、私が設定したかったのは、サブタスクを独自のジョブに分割することでした。これにより、すべてのビルド手順をコピーして貼り付ける (またはジョブをコピーしてすべてを変更する) ことなく、新しいジョブを簡単に設定できるようになります。一意である必要があるもの)。これにより、Project-DEV のコピーを作成したり、最後のジョブをクラウドにセットアップされたステージング環境に展開するジョブに切り替えたりすることができます。または、テスト結果をサード パーティ ソースに報告できるジョブを簡単に作成できます。つまり、結果を共有ネットワーク フォルダなどにコピーできます。または、いくつものこと。目標は基本的に、これらのサブタスク ジョブをビルディング ブロックとして使用して、より複雑なジョブを構築できるようにすると同時に、ビルドの一部の動作を簡単に更新できるようにすることです (たとえば、コンパイルのために別のテクノロジに切り替えるなど)。

たとえば、Project-PR は次のように分割されます。

Project-PULL -> Project-SetupBuildEnv -> Project-PartialUnitTests
(BuildFlow)     (Normal Job)             (Normal Job)        

SetupBuildEnv は、NPM または Composer の要件をプルダウンし、テストとビルドに必要なディレクトリをセットアップするだけです。その後、PartialUnitTests が実行され、その結果が

Project-DEV は次のように分割できます。

Project-DEV -> Project->SetupBuildEnv -> Project-FullUnitTests  -> Project-Compile -> Project-Minify -> Project-DeployQA -> Project-FullIntegrationTests

このようにして、共有されるビルド プロセスの部分 (この場合は Project-SetupBuildEnv ) をジョブ間で簡単に共有できるため、重複を減らし、ビルド プロセスのステップを簡単に更新できます。そのステップを使用します。

現在、共有ワークスペースを使用していますプラグインを使用して、すべてのステップで同じワークスペースを使用できるようにします。しかし、私はそれで問題に直面しています: 実際には 1 つのワークスペースを使用していません。Build Flow ジョブがディレクトリ (例: /sharedspace/shared_one ) を取得し、そこに GitHub からコードをダウンロードします。次に、「SetupBuildEnv」ジョブを開始する DSL をトリガーします。ただし、同じディレクトリ内で作業する代わりに、「/sharedspace/shared_one@2」のような名前のディレクトリを取得し、そこでビルド セットアップ タスクを実行します。次に、3 番目のステップ (単体テスト) を実行すると失敗します。これは、3 番目のディレクトリ ( /sharedspace/shared_one@3 ) があるためですが、そのディレクトリにはセットアップが実行されていないため、必要なノードとコンポーザーモジュールがありません。何'

では、質問タイム:

  1. ジョブごとに 1 つのディレクトリのみを実際に使用するように共有ワークスペース プラグインを修正する方法はありますか?
  2. そうでない場合、ドロップダウンを使用する代わりに、使用するアーカイブされたワークスペースを指定できるように、Clone Workspace プラグインに引数を持たせることは可能ですか?
  3. 別の可能性: 共有ワークスペース プラグインを使用しますが、高度な git ジョブ オプションで「レポのローカル サブディレクトリ (オプション)」オプションを使用して、使用するディレクトリを指定しますか?
  4. すべて失敗した場合、見逃した他のパイプラインとジョブを共有できるビルド パイプラインを設定する他の方法はありますか?
4

1 に答える 1

1

私の経験では、これが機能したとしても、長期的にはスケーラブルな方法ではない可能性があります共有ワークスペース プラグインは、長くて複雑なビルドでは完全に悪い考えであることがわかりました (あなたと同様の理由ですが、数十のスレーブにまたがるスケーリングが突然難しくなります)。間違いなく、このアイデアは現代のスケーラブルな CI の精神に少し反しています。

代わりに、Maven / Gradle、Ant、さらにはGruntなど、ビルドツールにもっと委任したいと思います。これらのビルドを完全にモジュール化したままにしたいが、各ステップで再構築する余裕がない場合 (完全な独立性は、ビルドごとに数分を無駄にする価値があると判断しました)、重要な段階で有用なアーティファクトを作成することを検討してください。アセットTAR、ライブラリJAR、またはおそらくwebjarsなど、それらを(Maven?)レポにデプロイします。

パイプラインの後のビルド ステップでは、この一元化されたリポジトリから最新の (または名前付きバージョンの) アセットをすばやく、簡単に、繰り返し実行してプルし、ビルド プロセスを続行できます。

別の方法 (類似点あり) は、1 つ以上のアセットをビルドすることですが、実行するテストの数を増やした後にのみそれらをプロモートします。これは、 Promoted Builds プラグインなどを使用して、ビルド フローによって調整された個別のビルドで実行できます。

于 2014-11-13T08:25:51.450 に答える