CI/CDパイプライン とは？

よくある構成は、①ソース（コードのプッシュがきっかけ）→②ビルド（コンパイルやコンテナイメージ作成）→③テスト（ユニットテスト・静的解析・E2Eテストなど）→④デプロイ（ステージング→本番）だよ。どこかで失敗したら後続を止めて知らせる「ゲート」の役目もあるんだ。

そこはチームしだいだよ。いつでも本番に出せる状態を保ち、最後の本番反映は人が判断するのが「継続的デリバリー」。テストを通った変更を自動で本番まで出すのが「継続的デプロイ」なんだ。どちらもCDと略されるから、話すときは区別しておこう。

GitHubでコードを管理しているならGitHub Actionsが始めやすいよ。.github/workflowsにYAMLでワークフローを書けば、プッシュやプルリクエストをきっかけに動くんだ。Jenkinsは自分でサーバーを用意して細かく作り込みたい場合、GitLab CI/CDはGitLabを使っている場合に候補になるね。今使っているツールとの相性で選ぶのが基本だよ。

テストの並列実行、依存関係やDockerレイヤーのキャッシュ、不要なステップの削除、変更に関係するテストだけを先に流す工夫などがあるよ。エクストリームプログラミングでは、最初のビルドを10分以内に終えるのが目安とされているんだ。速い確認を先に済ませて、時間のかかるテストは後のステージに回すと、開発者を待たせにくいよ。

入れておくと安心だよ。静的解析（SAST）、依存ライブラリの脆弱性チェック、コンテナイメージのスキャンなどをパイプラインに組み込む方法があるんだ。問題を早い段階で見つけるほど直しやすいから「シフトレフト」と呼ばれるよ。ただ、ツールで見つからない問題もあるから、レビューなど他の確認と組み合わせよう。