はじめに
Moss & Mallow は、架空の地域のギフトショップです。新しい栽培キットのコレクションでも、既存のまとめ買い割引と配送料のルールを維持する必要があります。ショップはすでに動いていますが、用意された Jenkins Pipeline では、実際の価格テストが失敗してもリリース候補を公開できてしまいます。
この実習では、実際のテスト失敗を読み取り、Jenkins のビルド状態をリリースの判断に結び付けて、正常に動く候補を公開します。Jenkins の基本的な画面操作と、短い Declarative Pipeline を見て理解できることを前提としています。新たに使うテストレポートとゲートの設定は、この実習で説明します。アプリケーションのプログラミング、インストール、クラウドアカウント、実際の購入は必要ありません。
顧客としての操作には Gift Shop、設定とビルドには Jenkins を使います。これらは準備済みの 1 台の VM 上で動く 2 つのサービスです。broken と fixed は、用意された 2 つのテスト用リリース候補です。各単元は独立した状態で始まります。所要時間の目安には読解と通常の操作ミスへの対応も含まれますが、初心者による実測値ではありません。
失敗したテストが実際に何を止めるかを確認する
このステップでは、正常な価格と実際のテスト失敗を比較し、不安定な状態の Jenkins ビルドでも公開が行われる理由を確認します。Gift Shop から始めてください。
Find a little gift、またはナビゲーションの Shop を選びます。栽培キットは 1 個 £12 です。3 個以上の栽培キットを購入すると、10% のまとめ買い割引が適用されます。配送料は £4 で、商品合計が £40 以上になると無料になります。表示価格は見積もりであり、このショップで支払いは行いません。
栽培キットの Quantity を 3 にして、Check basket を選びます。正常な商品代金は £32.40、配送料は £4.00、総額は £36.40 です。Shop で戻ります。ピクニックボックス 2 個の場合も確認してください。商品代金は £40.00 で、配送料は無料です。Visit を開き、種の育て方カードをダウンロードして、保存されたテキストファイルを読んでください。最後まで、これらの通常の機能を利用できる状態に保つ必要があります。
リリース候補（candidate）は、公開を検討しているバージョンです。ビルド（build）は Jenkins の 1 回の実行で、それぞれに番号、パラメーター、結果があります。Jenkins タブに切り替えます。shop-update を開き、Build with Parameters を選びます。RELEASE は broken のままにして、Build を選んでください。問題を観察するため、この最初の実行では、誤りのある練習用候補を意図的に公開します。実際の顧客への影響はありません。
ビルドが完了するまで待ちます。Builds の下にある番号付きの項目を開き、Console Output を開きます。Pipeline には 3 つのステージがあります。Prepare は選択した候補をビルドのワークスペースにコピーし、Test は用意された価格チェックを実行し、Publish はパッケージをショップに届けます。
コンソールには、次の固定の行が含まれているはずです。
Pricing failures: 1
Release received
Finished: UNSTABLE
UNSTABLE は、テスト失敗など、ビルドに品質上の問題があることを意味します。この状態だけで、後続のすべてのステージが実行されなくなるわけではありません。Release received は、この Pipeline が依然として公開を実行したことを示しています。
そのビルドの Tests を開きます。失敗した seed_bundle テストを開き、失敗の詳細を読んでください。
Expected 3240 400; got 2880 400
数値の単位はペンスです。テストでは商品代金 £32.40 と配送料 £4 を期待していましたが、候補は商品代金を £28.80 と計算しました。ほかの 3 つのテストは成功しました。これらは候補の実際の価格計算プログラムを実行した結果であり、XML レポートはその比較結果から生成されています。
Gift Shop に切り替え、Shop で栽培キット 3 個の価格をもう一度確認します。必要に応じてページを再読み込みしてください。誤った総額 £32.80 が表示されるようになっています。警告色だけでなく、実際に誤ったリリースが公開されたことを観察できました。このステップのチェックを使う前に、Jenkins の番号付きビルドに戻ってください。
テスト結果を公開の判断に結び付ける
このステップでは Pipeline を変更し、失敗したテストを表示したまま、Publish ステージの実行を防ぎます。Jenkins から始め、パンくずリストのリンクで shop-update のジョブページを開いてください。
Configure を選び、Pipeline セクションに進みます。Script エディターには Declarative Pipeline が入っています。agent any は利用可能な Jenkins エグゼキューターを選択します。この入門用の準備済み環境では、コントローラーのコンテナー内で実行されます。ワークスペースとは、そのビルドに割り当てられたディレクトリです。独立したエージェントについては、別のプロジェクトで学びます。
Test ステージを読んでください。用意された行 sh returnStatus: true, script: ... はテストスクリプトを実行し、直ちに Pipeline エラーを発生させる代わりに、終了ステータスを返します。これにより、次の junit ステップでテストの詳細を公開できます。終了ステータスがゼロならスクリプトは成功、ゼロ以外なら成功しなかったことを意味します。junit は XML の結果ファイルを読み込み、このビルドにテスト結果を関連付け、通常はテストが失敗するとビルドを UNSTABLE にします。
Pipeline のオプション（option）は、Jenkins による Pipeline の実行方法を変える設定です。agent any の直後に、次の行を追加してください。波括弧はオプションをひとまとまりにします。開き括弧と閉じ括弧の両方を、示されているとおりに保ってください。
options { skipStagesAfterUnstable() }
スクリプトの先頭は、次のようになるはずです。受信先アドレスと、用意された Prepare、Test、Publish ステージを含め、ほかの既存の行はすべて残してください。
pipeline {
agent any
options { skipStagesAfterUnstable() }
このオプションは、ビルドが不安定な状態になると、後続のステージをスキップします。失敗したテストを成功に変えるものではありません。標準のレポート公開処理を残してください。
junit testResults: 'reports/pricing.xml'
候補のコピー、test-shop.sh の実行、パッケージの公開に使う、用意されたシェル呼び出しを残してください。テストレポートはそのテストランナーで生成する必要があります。レポートを書き出すステップに置き換えたり、別のシェルコマンドを追加したりしないでください。
skipMarkingBuildUnstable: true は追加しないでください。この設定は、ゲートが判断に使うビルド状態の設定を抑制してしまいます。テストの削除、期待する価格の変更、用意された候補や公開処理の変更、すべての候補での公開のスキップも行わないでください。
Save を選びます。Build with Parameters を選び、broken のままで Build を選びます。新しい番号のビルドが完了するまで待ち、Console Output を開きます。今回は次のように表示されるはずです。
Pricing failures: 1
Stage "Publish" skipped due to earlier stage(s) marking the build as unstable
Finished: UNSTABLE
Tests を開きます。同じ失敗テストと、成功した 3 つのテストが引き続き表示されているはずです。新しいビルドに Release received が含まれていてはいけません。ショップには、先ほど公開した誤ったリリースがまだ表示されることがあります。新しい公開を阻止しても、過去の公開が自動的に元に戻るわけではありません。次に、正常な候補で置き換えます。
代わりに Groovy の構文エラーが表示された場合は、もう一度 Configure を開きます。追加した options の行が pipeline の内側で agent any のすぐ下にあり、波括弧の対応が取れていることを確認してください。修正して Save を選び、broken を再実行します。構文エラーで失敗しただけでは、このステップは完了しません。Jenkins は Checks API publisher に関する通知を表示することがあります。このローカルのコースではホスティングされた Git サービスを使わないため、その通知を実際のテスト結果の代わりに判断材料にしないでください。
正常に動くリリース候補を公開する
このステップでは、同じ Pipeline で正しい更新を届け、通常の顧客の利用手順を維持できることを確かめます。Jenkins の shop-update ジョブページから始めてください。
Build with Parameters を選びます。RELEASE を fixed に設定して、Build を選びます。これにより、用意された正常な候補が選択されます。先ほどテストした Pipeline は変わりません。完了するまで待ち、新しいビルドの Console Output を開きます。
Pricing failures: 0
Release received
Finished: SUCCESS
Tests を開きます。4 つの価格テストがすべて成功しているはずです。そのビルドの状態ページに戻り、Build Artifacts を探します。shop-release.tar.gz をダウンロードしてください。アーティファクトとは、そのビルドのために Jenkins が保存するファイルです。この圧縮アーカイブには、価格計算プログラム、リリースのメタデータ、育て方カードが含まれています。このアーカイブはショップに送られた実際のパッケージでもあり、別途ビルドし直したコピーではありません。
Gift Shop に切り替え、ブランド名のリンクでホームに戻り、再読み込みします。コレクションは Gifts to grow together に変わっています。Shop を開き、栽培キット 3 個の価格を確認します。商品代金は £32.40、配送料は £4.00、総額は £36.40 です。ピクニックボックス 2 個の配送料は、引き続き無料でなければなりません。Delivery と Visit を開き、育て方カードをもう一度ダウンロードして、内容がすべてそろっていることを確認してください。
最後のチェックでは、実際に失敗したビルドと成功したビルドを、現在保存されている Pipeline とデプロイされたファイルのバイト内容に結び付けて確認します。これらの実行後に Pipeline を編集した場合は、broken、次に fixed の順で再実行し、両方の結果が提出するバージョンの結果になるようにしてください。以前のビルドとショップの元のリソースは残してください。レポートを書いたり、コンソールの内容をファイルにコピーしたりする必要はありません。
誤って再び broken を選んだ場合は、ゲートをそのままにして fixed を実行してください。Jenkins がまだビルド中の場合は、ビルドを何度も追加するのではなく、その番号のビルドの最終結果を待ちます。ホームページが正常に表示されるだけでは不十分です。買い物かごの価格とダウンロードも、完成した成果の一部です。
まとめ
実際の価格テストの失敗を観察し、不安定なビルドでも公開が行われる理由を確認して、Jenkins のテスト結果をリリースゲートに結び付けました。その後、同じ Pipeline で正常な候補を届け、実際の価格、アーカイブされたパッケージ、通常のショップ機能を確認しました。
