CI/CD 導入はどこから始めればよいのか
まだ CI/CD を導入していないチーム向けに、ソースコード管理、自動デプロイの流れ、環境変数、デプロイ先の権限管理から、再現性・追跡性・ロールバック可能性のあるリリースプロセスを作る方法を整理します。
DevOps という言葉は、もう聞き飽きたという人も多いと思います。
特に情報があふれている今、
知識を得る手段には困りません。
DevOps は文化だと言う人もいます。
DevOps は自動デプロイだと言う人もいます。
どちらの説明にも、ある程度は同意できます。
ただ、多くの人が本当に知りたいのは、
「結局、どこから始めればよいのか？」ということではないでしょうか。
もう少し具体的に言えば、
自動デプロイの仕組みをどう導入すればよいのか、という話です。
やりたくないわけではない。
ただ、最初の一歩をどこに置けばよいのかわからない。
そういうチームは少なくありません。
そのため、この記事では難しい用語を深掘りしません。
短期間で実現できるかどうかわからない文化論にも寄せません。
もっと実務寄りの観点から、
DevOps を語る前に、
まず CI/CD からどう始めるかを整理します。
日々の開発とデプロイを、少しずつ安定させ、扱いやすくしていくための話です。
なぜ CI/CD から始めるのか
CI は Continuous Integration、日本語では継続的インテグレーションと呼ばれます。
CD は Continuous Delivery または Continuous Deployment で、継続的デリバリー、または継続的デプロイを意味します。
DevOps で語れることはたくさんあります。
では、なぜ最初に CI/CD から始めるべきなのでしょうか。
あるいは、より具体的に言えば、なぜ CD、つまり自動デプロイから始めるべきなのでしょうか。
理由はシンプルです。
効果が最も見えやすいからです。
この記事をここまで読んでいるということは、
今の開発やリリースの進め方に、何かしら改善したい点があるのだと思います。
自分自身も成長したいし、
チームの開発・リリースプロセスも良くしたい。
そう感じているのではないでしょうか。
文化を変える、開発と運用の壁をなくす。
こうした話は、多くの場合、マネジメント層の理解や組織全体の協力が必要です。
基本的な仕組みがまだ整っていない段階で、
ログの一元管理、アラート設計、SLO、インシデント管理まで一気に進めるのは簡単ではありません。
この段階で必要なのは、立派な用語ではありません。
まず必要なのは自動化です。
もっと具体的に言えば、
アプリケーションのデプロイを自動化することです。
デプロイ時のミスが減り、
手作業による失敗がほとんどなくなってくると、
チームはその仕組みを信頼し始めます。
その信頼があって初めて、
DevOps、SRE、プラットフォームエンジニアリングといった次の実践を話しやすくなります。
自動デプロイをどう導入するか
ソースコードをバージョン管理に入れる
ここで驚く人もいるかもしれません。
もう AI 時代なのに、
Git なんて何年も前からあるのに、
いまさらソースコードをバージョン管理に入れる話をするのか、と。
残念ながら、必要です。
大企業以外では、
小さな会社や、エンジニアが 1 人だけのチームでは、
今でもソースコードが適切にバージョン管理されていないことがあります。
たとえば AWS Lambda の開発です。
AWS Cloud Console はとても便利で、
開発者は AWS Lambda 上で直接コードを編集できます。
Python の場合、AWSLambdaPowertoolsPythonV2 のようなパッケージを使えば、
単純なケースでは requirements.txt を明示的に書かなくても動かせてしまいます。
この便利さによって、重要なことを見落としがちです。
ソースコードが Git に入っていないかもしれない、ということです。
AWS Lambda の Versions を使っていたとしても、
実際には runtime、environment variables、Lambda の設定をスナップショットとして保存しているだけです。
これは、私たちが期待するソースコードのバージョン管理とは別物です。
環境変数を変更したり、
VPC、Security Group、IAM Role などの設定を変更したりする場合、
変更点が多くなりすぎると、ロールバック時に再設定が必要になります。
あるいは、意味を把握しづらい Version が大量に残ってしまいます。
SVN や Git が一般的ではなかった頃、 ソースコードを Git で管理していないシステムはどう運用されていたのでしょうか。 多くの場合、SSH やリモートデスクトップでサーバーに入り、 ファイルのあるディレクトリへ移動し、 その日に変更するファイルをいったんリネームしてバックアップし、 そのままサーバー上に残しておきます。 そしていつか、誰もそのファイルを消してよいのか判断できなくなります。
つまり CI/CD の第一歩は YAML を書くことではありません。
Jenkins、GitLab CI、GitHub Actions など、どのツールを選ぶかでもありません。
最初にやるべきことは、ソースコードが本当にバージョン管理されている状態にすることです。
そして Git から次のことがわかるようにする必要があります。
- 今、本番環境で動いているのはどのバージョンか
- 今回、何が変更されたのか
- 誰が、いつ、何を変更したのか
- 問題が起きたとき、どのバージョンへ戻せばよいのか
バージョン管理がなければ、
その後の CI/CD は不安定な作業を自動化しているだけになってしまいます。
自動デプロイ
自動デプロイを実装するなら、
まず次の 3 つを押さえることをおすすめします。
デプロイフロー、環境変数、デプロイ先環境へのアクセス権限 です。
デプロイフロー
デプロイフローは、繰り返し実行できる必要があります。
初回だけ成功すればよいわけではありません。
2 回目、3 回目、その後何度実行しても成功するべきです。
SIT 環境、UAT 環境、本番環境のいずれであっても、
できるだけ同じ流れでデプロイできる状態にします。
環境が違うからといって、
デプロイ手順そのものが変わるべきではありません。
また、ある環境に初期データがないだけで、
デプロイ全体が壊れるような状態も避けるべきです。
良いデプロイフローは、少なくとも次の問いに答えられる必要があります。
- どの Git branch または tag からコードを取得するのか
- 依存関係をどうインストールするのか
- テストをどう実行するのか
- artifact をどうビルド、またはパッケージングするのか
- artifact をどうデプロイ先へ反映するのか
- デプロイに失敗した場合、どう停止またはロールバックするのか
最初から完璧を目指す必要はありません。
これまで CI/CD がなかったチームなら、
最初のバージョンはとてもシンプルで構いません。
たとえば次のような流れです。
push code → テスト実行 → テスト環境へデプロイ
この流れが安定してから、
本番デプロイ、承認フロー、バージョンタグ、ロールバック戦略、通知などを少しずつ追加していけば十分です。
環境変数
通常、環境ごとに異なるデータベース接続情報を使うはずです。
コスト削減のために、
テスト環境 と 本番環境 が同じデータベースホストを共有しているとしても、
少なくともデータベース名や schema は分けるべきです。
そのため、こうした情報をコードに直接書き込むべきではありません。
よりよい方法は、設定をコードから分離することです。
設定ファイル、環境変数、Secret Manager、Parameter Store、
またはその他の構成管理の仕組みを使い、
環境ごとに異なる設定を読み込ませます。
データベース接続、API Key、外部サービスの URL などをコードに直書きしていると、
デプロイのたびに手動修正が入り、
ミスが起きやすくなります。
さらに悪い場合、
機密情報が Git に commit されてしまい、
セキュリティ上の問題になります。
初心者向けに言えば、
基本原則は次の通りです。
- コードは振る舞いを表す
- 環境変数は環境差分を表す
- Secret は Git に入れない
- テスト環境と本番環境は明確に区別する
この境界が整理できて初めて、
CI/CD は同じコードを複数環境へ安全にデプロイできるようになります。
デプロイ先環境へのアクセス権限
デプロイ先環境へのアクセス権限は、
アカウントとパスワードかもしれません。
環境ごとに異なる private key かもしれません。
あるいは、各環境に agent をインストールし、
その agent が能動的または受動的にデプロイ内容を取得する方式かもしれません。
どの方式であっても、
CI/CD システムがデプロイ先へ反映できる権限を持っている必要があります。
ただし、権限は大きければよいわけではありません。
CI/CD を導入し始めたばかりの頃は、
とりあえず pipeline を動かすために、
過剰な権限を与えてしまいがちです。
短期的には便利に見えます。
しかし長期的にはリスクになります。
よりよい方法は、最小権限の原則を守ることです。
CI/CD が Lambda をデプロイする必要があるなら、
Lambda デプロイに必要な権限だけを付与します。
CI/CD が artifact を S3 にアップロードする必要があるなら、
対象 bucket に必要な権限だけを付与します。
CI/CD が特定のサービスを再起動する必要があるなら、
そのサービスを操作する権限だけを付与します。
デプロイ権限そのものも、管理・追跡されるべきです。
CI/CD が本番環境を変更できるようになった時点で、
それは単なる開発ツールではありません。
本番環境の変更管理プロセスの一部になります。
最小構成のフローから始める
どこから始めればよいかわからない場合は、
まず最小構成のフローを最初の目標にするとよいです。
最初からすべてを自動化しようとしないことです。
最初から完成度の高いプラットフォームエンジニアリング体験を目指す必要もありません。
まず 1 つのサービスを CI/CD 経由でテスト環境へデプロイできるようにします。
その後、同じフローで本番環境へもデプロイできるようにします。
たとえば：
- ソースコードを Git に入れる
- push または merge request で pipeline を起動する
- pipeline で基本的なテストを実行する
- pipeline でデプロイ用 artifact を作成する
- テスト環境へ自動デプロイする
- 人による確認後、本番環境へデプロイする
- デプロイ結果をチームへ通知する
この流れは派手ではありません。
しかし、日常的な多くの問題を改善するには十分です。
たとえば：
- 手作業でファイルをコピーしなくてよくなる
- サーバーにログインしてコードを直接修正しなくてよくなる
- 何をデプロイしたのかを記憶に頼らなくてよくなる
- デプロイのたびに手順漏れを心配しなくてよくなる
- 問題が起きたとき、どの変更が原因か追跡しやすくなる
このフローが安定すると、
次に何を改善すべきかが自然に見えてきます。
自動テストが足りないかもしれません。
環境変数の管理が混乱しているかもしれません。
デプロイ後のヘルスチェックがないかもしれません。
アラートやログ追跡がないかもしれません。
こうした課題が見えてきたタイミングこそ、
DevOps、SRE、プラットフォームエンジニアリングへ進む良いタイミングです。
まとめ
CI/CD を導入するからといって、
最初から成熟した大規模な技術組織のように振る舞う必要はありません。
まだ始めていないチームにとって最も重要なのは、
信頼でき、繰り返し実行でき、追跡可能なデプロイフローを作ることです。
ソースコードがバージョン管理されていること。
デプロイフローが繰り返し実行できること。
環境差分が設定として管理されていること。
デプロイ先の権限が適切に制御されていること。
これらができていれば、
チームはすでに、より成熟したエンジニアリングプロセスへ大きく前進しています。
DevOps はスローガンから始まるものではありません。
開発と運用が同じデリバリーフローを信頼できるようになるところから始まります。
SRE も、最初から完全な信頼性エンジニアリング体制を作る必要はありません。
まずは一つひとつの変更を、より制御しやすく、観測しやすく、復旧しやすくすることから始まります。
プラットフォームエンジニアリングも、いきなり大きな社内プラットフォームを作ることではありません。
チームが繰り返し行っていて、ミスが起きやすい作業を、
少しずつプロダクト化し、セルフサービス化していくことです。
もし今、どこから始めればよいか迷っているなら、
DevOps、SRE、プラットフォームエンジニアリングという言葉に身構える必要はありません。
まずは最小構成の CI/CD pipeline から始めましょう。
デプロイを安定させる。
変更を追跡可能にする。
チームが少しずつ自動化を信頼できるようにする。
そこまでできて初めて、
文化、信頼性、プラットフォーム化は、
本当に根を張る土台を持てるようになります。