CI/CD — 変更を自動でテストして届ける

上級のCI/CDでは、パイプラインを画面でポチポチ組む設定ではなく、リポジトリに置いたコード（パイプライン・アズ・コード）として書きます。これはIaCと同じ発想の応用です。

• バージョン管理される — パイプラインの定義がGitの履歴に載り、いつ誰が段取りを変えたか追える
• レビューできる — 「テストを一段飛ばす」ような変更も、コード差分として事前に見える
• 再現できる — 同じ定義から同じ流れが再生される。担当者の手順の記憶に依存しない

登場人物メモ:

• ※1 パイプライン・アズ・コード — CI/CDの段取りを設定ファイルとして記述し、履歴管理する書き方
• ※2 昇格（プロモート） — 同じ成果物を、下の環境から上の環境へ順に進めること
• ※3 出所（provenance） — その成果物が「どのソースから・どの手順で作られたか」の証明

流れを速く・安全にする鍵は、作り直さないことです。

• 一度ビルドしてどこでも使う — Dockerイメージなどの成果物（アーティファクト）を1回だけ作り、各環境へは同じ物を昇格させる。環境ごとに作り直すと「本番だけ別物」が生まれる
• キャッシュ — 依存ライブラリや中間生成物を保存し、変わっていない部分の再取得・再ビルドを省く。ただしキャッシュのキーがずれると古い物を掴むので、鍵の付け方が肝
• べき等なデプロイ — 同じ成果物を同じ環境へ何度配っても結果が同じになるように設計する。途中で失敗しても、もう一度流せば安全に立て直せる

いきなり全利用者へ出すのは危険です。段階を踏み、切り替え方そのものを選びます。

• 環境の昇格 — 開発→ステージング→本番と、同じ成果物を順に進める。各段でテストや承認を挟む
• ローリング — サーバを少しずつ新版へ入れ替える。落とさず進むが、新旧が一時混在する
• ブルーグリーン — 新版の環境（緑）を丸ごと用意し、入口を一斉に切り替える。問題が出たら入口を戻すだけで即ロールバック
• カナリア — 新版をまず一部の利用者にだけ配り、指標を見て問題なければ徐々に広げる。異常を小さな範囲で早く掴める
• ロールバック — どの戦略でも「すぐ前の版へ戻せる」備えを前提にする。Kubernetesなどは版を記録し、戻す操作を一手で行える

パイプラインはデプロイ鍵やAPIキーに触れます。ここが漏れると全体が崩れます。

• コードに直書きしない — 秘密は専用の金庫に置き、実行時に環境変数などで注入する
• ログのマスキング — 秘密が出力に紛れても伏せ字にする。うっかり表示で漏らさない
• 最小権限 — そのジョブに必要な権限だけを、必要な時だけ与える
• 短命トークン — 長期の固定鍵より、その実行だけ有効な使い捨てトークン（OIDC連携など）が安全。盗まれても寿命が尽きている

「自分のコードは安全」でも、取り込む部品や配布経路が汚染されれば台無しです。近年ここが攻撃の的になっています。

• SBOM — 成果物に含まれる部品の一覧表（Software Bill of Materials）。どのライブラリのどの版が入っているか分かれば、脆弱性が出たとき影響範囲を即座に洗える
• 署名 — 成果物に電子署名を付け、受け取り側が改ざんされていないことを確認できるようにする
• 出所検証（provenance） — 「この成果物は正規のパイプラインで、このソースから作られた」という証明を残し、検証する。横から差し込まれた偽物を弾く

• 環境ごとの作り直し — 同一成果物を昇格せず作り直すと、テストで確かめた物と本番の物が食い違う
• キャッシュの取り違え — 鍵の設計が甘いと古い依存を掴み、「手元では直ったのにCIで再発」する
• 戻せないデプロイ — ロールバック手段のない切り替えは、障害時に復旧が長引く
• 秘密のログ流出 — マスキング漏れや冗長なデバッグ出力で、鍵が履歴に残ってしまう