CI/CDパイプラインの設計｜成果物・段階・停止条件を決める

CI/CDパイプラインは、変更をビルド・検査・配信へ進める工程をつなぐものです。設計では、コマンドの順番だけでなく、各段階が何を受け取り、何を確認し、どの成果物を次へ渡すかを決めます。

この記事では、工程を組み立てる開発・運用担当者に向けて、成果物の対応と停止条件を整理します。特定ツールへ貼り付ける設定例ではなく、実装前の設計メモとして使う内容です。

段階ごとに入力と成果物を決める

まず、ソースコードの版から本番確認までを表にします。次は一つのアプリケーションを想定した設計例です。

GitHub Actionsではジョブ間の依存関係を指定でき、依存するジョブの完了を待って次へ進めます。このような機能を使う場合も、どの検査を必須とするかは設計側で決める必要があります。GitHub「Understanding GitHub Actions」

試験した成果物と配信する成果物をつなぐ

試験環境と本番で別々にビルドするときは、同じコードの版でも依存や設定が変わっていないか確認が必要です。可能なら同じ配布物を次段階へ渡し、環境ごとの設定を別に管理する方法を検討します。

記録する対象は、コミットIDだけでなく、配布物の識別子やハッシュ、生成した処理の記録です。どの検査結果がどの配布物に対応するかをたどれるようにします。

GitHubのartifact機能には、アップロード時とダウンロード時のSHA256 digestを照合する仕組みがあります。ただし、公式資料が示す不一致時の挙動は警告表示です。警告があるだけで公開が止まると考えず、停止条件を別に確かめてください。GitHub「Store and share data with workflow artifacts」

失敗と承認待ちで止まる場所を分ける

テスト失敗と、業務上の公開承認待ちは別の状態です。再実行すれば解決するとは限らないため、停止理由、確認担当、再開条件をそれぞれ残します。

GitHubのenvironmentには保護ルールを設けられ、対象ジョブは条件を通過するまで実行や環境のsecret利用へ進めません。利用できる機能はリポジトリの公開範囲やプランで異なります。GitHub「Managing environments for deployment」

これは製品例です。使う基盤では、誰が承認できるか、どの版を承認したか、承認後に対象が変わったらどうするかを確認します。設定画面に項目があるだけで運用が成立したとは判断しません。

配信後の確認と戻す条件を設計する

デプロイ処理の終了と、利用者が新しい版を使えることは分けて確認します。配信した版、主要操作、エラーの状態など、システムに合う確認対象を定めます。

問題が出たときは、前の配布物へ戻せるかだけでなく、その間に変更されたデータや設定も確認します。データ構造を変更するリリースでは、コードだけ戻して成立するかを事前に検討してください。

戻す条件、判断者、戻した後の確認を、正常な公開経路と同じ設計メモへ残します。具体的な操作は、運用手順書の作り方に沿って別の担当者が使える形にできます。

一変更の記録を端から端までたどる

試行では、意図的に検査を不合格にしたケースや、承認待ちのケースを含め、想定した場所で止まるかを確認します。本番環境へ影響しない試験用の経路で行ってください。

最後に、ソース、配布物、検査、承認、配信結果が一つの変更としてつながるかを読み合わせます。ツールの比較へ進む場合は、必要になった実行環境・権限・保管条件をCI/CDツールの比較の項目へ渡すと、製品名だけの検討を避けられます。