ビルドが成功しても成果物へ変更が反映されない
ビルドのジョブが正常終了と記録されても、成果物の保管先の指定が誤っていれば、古い版がデプロイ対象になります。変更は反映されません。
GENZ, Inc.
パイプラインの検証
CI/CDパイプラインを
パイプラインの検証
CI/CDパイプラインを第三者視点でテスト設計
パイプライン定義そのものを検証対象とし、自動テストが何を確かめ、何を確かめていないかを書面で宣言します。リリース判断の材料として提出できる第三者検証です。
支援事例
支援実績5,000件以上
CI/CDパイプラインでよくある不具合
パイプラインはジョブ定義として記述され、その定義の誤りはアプリケーション本体とは別に発生します。定義を書いた担当者が検証も担う構造では、誤りが残ったまま本番環境へのデプロイへ進みます。
ビルドが
自動テストが失敗しても後続のデプロイ処理が続行される
失敗時の停止条件がジョブ定義にないと、自動テストの失敗後も後続工程が実行されます。不具合を含む版が本番環境へ配信され、監視で検知されます。
同じ変更内容でも実行のたびにテスト結果が変わる
並列実行や外部サービスへ依存する定義では、同じ変更でも実行のたびに結果が変わります。再実行で成功する運用が続くと、失敗の見送りが習慣化します。
検証環境向けの設定値のまま本番環境へデプロイされる
環境ごとの設定値の切り替えが定義にないと、検証環境の接続先のまま本番環境へデプロイされます。デプロイは成功し、誤りは稼働後に表面化します。
切り戻しを実行しても前の版へ戻らない
切り戻しが定義されず手作業の運用手順に残ると、手順自体が検証されないまま本番障害を迎えます。復旧は手作業の対応に依存し、業務停止が長引きます。
残存した不具合により生じる問題
自動テストが通過しても、検証範囲の外の不具合は本番環境へ届きます。残った不具合が引き起こす問題を、復旧・説明責任・変更管理の面から整理します。
静的テスト（レビュー）でおさえるべき観点
パイプラインの定義を書いた担当者がその検証も担う構造では、ジョブの失敗条件やデプロイ先の誤りが確認されないまま残ります。実行せずに定義と帳票を照合するレビューで、以下の観点を押さえます。
承認前の版が本番環境へ自動で反映される。
パイプライン定義とリリース手順書の工程の順序を照合する
パイプライン定義のビルド・テスト・デプロイの順序と、リリース手順書の工程順を照合します。不整合があると、手順書どおりに作業してもデプロイが先に実行され、承認前の版が本番環境へ反映されます。
確認する資料
- パイプライン定義
- リリース手順書
- 工程順序表
検証範囲外の領域を示す根拠がなく、リリース判断が「ジョブの成功」だけに依存する。
ジョブの失敗条件とリリース判断の基準を照合する
ジョブが失敗とみなす条件と、リリース判断で使う可否の基準を照合します。失敗条件が定義側にしかないと、自動テストが通ったという結果だけが残り、何を検証範囲に含めていないかを説明できません。
確認する資料
- ジョブ定義書
- リリース基準表
- 不具合一覧
検証用の設定値のまま本番環境へデプロイされ、切り戻しが手作業での対応となる。
環境ごとの設定値一覧とデプロイ先の定義を照合する
環境ごとの設定値の一覧と、パイプライン定義が指すデプロイ先を照合します。設定値は定義の外部で管理される形が一般的で、両方を見ないと、検証用の値で本番環境へデプロイされる不整合を検知できません。
確認する資料
- 設定値一覧
- デプロイ定義
- 環境構成図
設計書を超えた権限で認証情報が参照され、システム監査で変更管理の不備を指摘される。
認証情報の参照箇所と権限設計書の付与範囲を照合する
ジョブ定義が参照する認証情報の箇所と、権限設計書の付与範囲を照合します。定義の変更が積み上がると、設計時より広い権限で認証情報を読むジョブが混在し、システム監査の指摘として表面化します。
確認する資料
- 権限設計書
- ジョブ定義書
- 認証情報一覧
自動テストが通らない範囲を説明できず、不具合を含む版がそのまま配信される。
自動テストの実行範囲とテスト計画の対象範囲を照合する
自動テストの実行範囲と、テスト計画が対象と宣言した範囲を照合します。一致しない領域は検証されないまま残り、リリース判断の根拠がジョブの成功だけに置き換わります。この範囲の明記が必要です。
確認する資料
- テスト計画書
- 自動テスト定義
- 実行結果報告
- 検証範囲宣言
動的テストの設計・実行のポイント
自動テストが通る範囲だけでは、ジョブ定義やデプロイ先の誤りは検出されません。段階ごとに何をどこまで検証するかを設計します。
STEP 01
ジョブ単位の検証失敗条件と設定値をジョブごとに確認
どう確かめるか
ジョブ定義ごとの挙動をユニットテストで検証する
ジョブ定義を書いた本人が検証も担う構造では、失敗条件や環境ごとの設定値の誤りが残ります。ユニットテストでジョブごとの入出力と失敗条件を切り分けて検証します。
- 01ジョブ定義の入力と出力の条件を整理します
- 02失敗条件ごとの挙動を検証します
- 03環境ごとの設定値の差異を確認します
OUTPUTジョブ単位の不具合の検出
STEP 02
工程間の連携の検証工程間の連携の不整合を検出
どう確かめるか
工程間の受け渡しを統合テストで検証する
ビルドからテスト、成果物保管への受け渡しでは、バージョン管理システムとの連携の不整合が起きます。統合テストで工程間のデータの受け渡しと連携の動作を検証します。
- 01バージョン管理システムとの連携を検証します
- 02工程間で受け渡す成果物の整合を確認します
- 03連携失敗時のエラー処理を検証します
OUTPUT工程間の不整合の検出
STEP 03
デプロイと切り戻しの検証復帰手順の実行可能性を確認
どう確かめるか
デプロイと切り戻しをシステムテストで検証する
本番環境へのデプロイと切り戻しは、手順自体が検証されないまま運用される場合があります。システムテストでデプロイから復帰までの一連の手順を実際に実行して検証します。
- 01デプロイ手順を本番相当の環境で検証します
- 02切り戻し手順の実行可能性を確認します
- 03承認の段の記録の残り方を確認します
OUTPUT切り戻しの失敗の検出
STEP 04
変更後の回帰テスト変更が既存処理へ及ぼす影響を確認
どう確かめるか
変更後の既存パイプラインを回帰テストで検証する
ジョブ定義の変更が積み上がると、どの変更がどの挙動を変えたかが追えなくなります。変更のたびに回帰テストを実施し、既存のパイプライン全体への影響を確認します。
- 01変更対象のジョブと影響範囲を特定します
- 02既存のジョブ全体に回帰テストを実施します
- 03変更前後の挙動の差異を確認します
OUTPUT既存ジョブへの影響の検出
GENZが代行するCI/CDパイプラインのテスト
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 検証範囲を宣言した書面がリリース判断の材料になります
- パイプライン定義を読み解き、説明の手間をかけずに検証を進めます
- リリース周期を止めずに検証を挟み込む進行ができます
- 切り戻しまで確認した記録が監査と障害対応に使えます
定義の読解から報告までを担うGENZ
自動テストが何を検証し、何を対象外とするか。GENZはパイプラインの定義そのものを検証対象とし、検証範囲を書面で宣言する第三者検証を提供します。テスト設計から実行、報告書の納品までを一貫して担います。
パイプライン定義からテスト設計へ
ジョブ定義が記述された設定ファイルを読み解き、設計書がなくてもテスト設計へ反映します。定義の作成者とは別の視点で検証します。
ビルドから切り戻しまで検証する
ビルドとデプロイだけでなく、切り戻しが実際に機能することまでを検証範囲に含め、リリース経路の全体を確認します。
既存の開発体制に合わせて伴走する
スプリントやリリースの周期を止めずに検証を挟み込みます。既存の開発チームと連携し、進行に合わせて伴走します。
監査にも使える報告書を納品
どの変更が誰の承認を経て本番環境へ反映されたかを示せる報告書を納品します。リリース判断とシステム監査の双方に使える形です。
ご相談から納品までの流れ
ご相談から報告書の納品まで、既存の開発の進行を止めずに検証へ入る流れをご紹介します。
現状のパイプラインと課題のヒアリング
ジョブ定義や運用手順書を確認し、検証範囲の外にある箇所を洗い出します。
テスト設計と見積もりのご提示
検証範囲と優先順位を書面で宣言し、稟議に使える形で見積もりを出します。
テストの実施と結果の共有
合意した範囲でテストを実施し、不具合と残存リスクを随時共有します。
報告書の納品と再確認
システム監査の指摘への回答にも使える報告書を納品し、内容を確認します。
CI/CDパイプラインの第三者検証
検証の範囲と優先順位をGENZへご相談ください
パイプラインの定義自体が検証の外にあるなら、リリース判断の根拠は残りません。GENZはビルドからデプロイ・切り戻しまでを検証範囲に含め、範囲を書面で宣言して検証を引き受けます。