パイプライン完了後の処理：ポストアクション、クリーンアップ、証跡管理
パイプラインがグリーンになるのを見届けました。すべてのテストが通り、デプロイも成功し、チームチャットに「完了」のメッセージが流れました。ほとんどの人はタブを閉じて次のタスクに移ります。しかし、そこで止めてしまうと、パイプラインは半分しか完了していないことになります。
デプロイが成功したからといって、パイプラインが完了したわけではありません。最後のテストが通った後に行うべきことが3つあります。これらをスキップすると、数週間後や数ヶ月後にしか顕在化しない問題が発生します。
本当に役立つ通知
パイプラインが完了したら、まず誰かに知らせる必要があります。しかし、すべての通知が有用とは限りません。「デプロイ成功」や「ビルド失敗」とだけ書かれたメッセージはノイズです。何が起こったのかを把握するために、わざわざパイプラインのログを開かせることになります。
優れた通知にはコンテキストが含まれています。以下の情報を含めるべきです：
- 処理された変更（コミットハッシュまたはマージリクエストID）
- パイプラインをトリガーした人
- デプロイ先の環境
- すべてが成功したか、何かが失敗したか
- パイプライン実行への直接リンク
小規模チームであれば、チャットメッセージで十分です。大規模組織では、メール、課題トラッカー、監視ダッシュボードに通知を送ることもあります。媒体よりも内容が重要です。通知がアクションを起こすべきかどうかの判断に役立たなければ、単なる気晴らしに過ぎません。
本番環境がおかしくなったために午前2時に呼び出される人のことを考えてみてください。彼らはすぐに知る必要があります：最近デプロイがあったか？誰がやったか？何が変わったか？適切に構造化された通知は、誰もブラウザを開く前にこれらの質問に答えてくれます。
以下は、必要なコンテキストを含むSlack通知ステップの実用的なYAMLスニペットです：
notify-slack:
stage: post-deploy
image: curlimages/curl:latest
script:
- |
curl -X POST -H "Content-type: application/json" \
--data "{
\"text\": \"Deployment complete\",
\"blocks\": [
{
\"type\": \"section\",
\"text\": {
\"type\": \"mrkdwn\",
\"text\": \"*Pipeline finished*\nCommit: \`$CI_COMMIT_SHORT_SHA\`\nAuthor: $GITLAB_USER_LOGIN\nEnvironment: production\nStatus: $CI_JOB_STATUS\nLink: $CI_PIPELINE_URL\"
}
}
]
}" \
$SLACK_WEBHOOK_URL
only:
- main
このステップはmainブランチでのみ実行され、コミットハッシュ、作成者、環境、パイプラインへの直接リンクを送信するため、受信者はログを開かなくても状況を即座に把握できます。
一時リソースのクリーンアップ
パイプラインが実行されるたびに、一時リソースが作成されます。ランナー上のワークスペース、テスト用に起動されたコンテナ、一時ストレージボリューム、ビルドフェーズでのみ必要なビルドアーティファクト、ダウンロードされた依存関係などです。
これらをクリーンアップしないと、蓄積されていきます。ディスク容量が不足し、ランナーが遅くなります。さらに悪いことに、前回のパイプラインの残骸が次の実行に干渉する可能性があります。ローカルでは通るテストがCIで失敗するのは、ワークスペースに前回のビルドのファイルが残っているからかもしれません。
クリーンアップは自動化すべきです。誰かが手動で削除するのを覚えていることに頼ってはいけません。ほとんどのパイプラインプラットフォームには組み込みのクリーンアップ機構がありますが、それが実際にあなたの特定のセットアップで機能することを確認する必要があります。プラットフォームがクリーンアップするコンテナでも、マウントされたボリュームが残ることがあります。ワークスペースがワイプされても、キャッシュされた認証情報が残ることがあります。
最も安全なアプローチは、パイプラインの最後にクリーンアップを明示的なステップとして追加することです。作成したものを削除し、マウントしたものをアンマウントし、キャッシュしたものを削除します。パイプラインプラットフォームがこれらの一部を自動的に処理するのであれば、それで結構です。しかし、見逃す可能性のあるものについては、ステップを追加してください。
証跡の保存：誰もが忘れる部分
これは最も重要なポストアクションであり、ほとんどのチームがスキップするものです。
証跡とは、パイプライン実行中に発生したすべての完全な記録です。最終ステータスだけでなく、完全なストーリーです：
- パイプラインをトリガーしたもの
- 処理されたコミット
- ビルド出力とログ
- テスト結果（合格したテストと失敗したテストの両方を含む）
- セキュリティスキャンレポート
- 生成された正確なアーティファクト（ハッシュまたはレジストリURL付き）
- デプロイログ
- デプロイ後チェックの検証結果
これらすべてを、アクセス可能な場所に保存する必要があります。30日で期限切れになるCIプラットフォームの内部ストレージに埋もれさせてはいけません。誰かのローカルターミナル履歴に保存してもいけません。数ヶ月後や数年後でもクエリできる場所に保存します。
なぜこれが重要なのでしょうか？なぜなら、いつか誰かがこう尋ねるからです：
- 「3週間前に本番環境にデプロイしたあのバージョン、セキュリティスキャンは通ったのか？」
- 「本番インシデントが発生している。あの変更はデータベースマイグレーションに対してテストされたのか？」
- 「監査人が、すべてのデプロイが本番環境に反映される前にレビューされたという証拠を求めている。」
証跡がなければ、これらの質問に答えることはできません。推測するしかありません。そして、本番インシデントや監査で推測することは、キャリアを損なう方法です。
証跡を実用的に保存する方法
すべてを含む1つの巨大なファイルは必要ありません。すぐに管理不能になります。代わりに、参照とリンクを保存します。
パイプラインは、以下を含むサマリーを生成する必要があります：
- ビルドIDとビルドログへのリンク
- レジストリ内のアーティファクトへのURL
- テストレポートへのリンク
- セキュリティスキャン結果へのリンク
- デプロイログの場所
- 手動承認記録（該当する場合）
このサマリーは、変更管理システム、オブジェクトストレージバケット、またはデータベースに保存できます。形式はJSON、YAML、プレーンテキストのいずれでも構いません。重要なのは、人間と機械の両方が読み取れることです。
チームによっては、この証跡をコミットやマージリクエスト自体に添付することもあります。また、専用の証跡リポジトリに保存するチームもあります。どちらの方法でも構いません。検索可能で、自動的に削除されない限りは。
証跡は監査人だけのものではない
確かに、監査人は証跡を好みます。しかし、真の価値はデバッグ中に現れます。
本番環境が壊れたとき、最初の質問は常に「何が変わったのか？」です。適切な証跡があれば、最後のパイプライン実行を開いて、何が起こったのかを正確に確認できます。無視されたテストの失敗はなかったか？アーティファクトは期待と異なっていなかったか？誰も文書化していなかった設定変更はなかったか？
証跡がなければ、盲目的にデバッグすることになります。記憶、チャットログ、推測に頼ることになります。証跡があれば、実際に何が起こったのかという事実に基づいた記録があります。
パイプラインサイクルの完了
通知が送信され、リソースがクリーンアップされ、証跡が保存されると、パイプラインサイクルは真に完了します。パイプラインは次のトリガーの準備が整い、同じシーケンスが繰り返されます。
このリズムこそがCI/CDを信頼性の高いものにします。すべての変更が同じパスをたどります。すべての変更が同じ種類のトレイルを残します。すべての変更が後で検証可能な出力を生成します。
パイプラインのポストアクションステージのクイックチェックリスト
- 通知にはコミット、作成者、環境、ステータス、直接リンクが含まれている
- 一時リソースが自動的にクリーンアップされる
- ビルドログ、テスト結果、スキャンレポートが永続的に保存されている
- アーティファクト参照（レジストリURL、ハッシュ）が記録されている
- デプロイログが保存され、リンクされている
- 証跡が検索可能で期限切れにならない場所に保存されている
具体的な takeaways
「デプロイ成功」で止まるパイプラインは不完全です。デプロイ後に3つのステップを追加してください：有用なコンテキストで通知し、一時リソースをクリーンアップし、数ヶ月後でも見つけられる証跡を保存します。最後のステップこそが、問題が発生したときにあなたを救います。それがなければ、盲目的に飛ぶことになります。それがれば、デバッグを推測から調査に変える事実に基づいた記録が手に入ります。