概要

最近はAIを使ってコードを書く機会が増えてきました。

AIのおかげで実装速度は上がりましたが、一方で生成された変更をどのように検証するかという課題も出てきています。
特にTerraformのようなインフラコードは、ちょっとした設定ミスが本番環境へ影響することもあります。

AIは変更を作ることは得意ですが、その変更を安全に受け入れる仕組みは別で考える必要があります。
そのため、AIを活用する機会が増えるほど、CI/CDの重要性は高まっていくと感じています。

ただ、CI/CDが重要だと分かっていても、なかなか導入できないという話もよく聞きます。

今回は、案件支援や社内教育の中で感じている「最小構成から始めるCI/CD」について書いてみます。

最初の一歩が重くなる理由

CI/CDについて学んだり、実際に構築したりする中で感じるのは、CI/CDそのものが難しいというより、最初の一歩を踏み出すのが意外と難しいということです。

CI/CDを導入できていないプロジェクトを見ると、次のようなパターンがよくあります。

パターン	内容
完璧を目指す	最初から理想的なパイプラインを作ろうとする
要件が曖昧	何を自動化したいのか整理できていない
準備待ち	テスト整備や運用整理が終わってから導入しようとする
経験不足	何から始めればよいか分からない

特に「ちゃんと設計してから始めよう」と考え始めると、なかなか手を付けられなくなることがあります。

もちろん、最初からしっかり設計することが悪いわけではありません。

例えば、

品質要件が明確
セキュリティ要件が明確
運用ルールが決まっている
CI/CD構築経験がある

といった場合は、最初からある程度作り込む方が効率的なこともあります。

一方で、

CI/CDをまだ導入できていない
何を組み込むべきか見えていない
GitHub ActionsやGitLab CIを触り始めたばかり

という場合は、まず動くものを作る方が進みやすいです。

後からCI/CDを導入するのは意外と大変

Terraformを利用しているプロジェクトであれば、CI/CDがなくても最低限の運用はできます。例えば、ローカルで terraform plan を実行し、変更内容をレビューしてから terraform apply するような流れです。

ただ、運用が長くなると、環境数や関係者が増え、確認すべき観点も増えていきます。

この状態になってからCI/CDを導入しようとすると、単にパイプラインを作るだけでは済まないことがあります。

どこまで自動化するか
plan結果をどう共有するか
誰が承認するか
セキュリティチェックをどこで実施するか

といった運用ルールも一緒に整理する必要があります。

そのため、最初は terraform fmt や terraform validate だけでもCIに組み込んでおくと、後から機能を追加しやすくなります。

Terraformで考える最小構成

Terraform CI/CDというと、次のような構成をイメージする人も多いと思います。

もちろん最終的にはこうした構成を目指すこともあります。

ただ、最初からここまで実装する必要はありません。

まずは以下だけでも十分です。

GitHub Actionsで書くとこんな感じです。

name: terraform-ci

on:
  pull_request:

jobs:
  validate:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v3

      - name: Terraform fmt
        run: terraform fmt -check -recursive

      - name: Terraform init
        run: terraform init -backend=false

      - name: Terraform validate
        run: terraform validate

この段階でも、

フォーマット崩れの検知
Terraform構文エラーの検知
CI実行の習慣化

といった効果があります。

CI/CDは運用しながら育てる

案件によって必要なチェックは変わります。

例えば、

fmtとvalidateだけで十分なケース
planまで必要なケース
セキュリティチェックが必要なケース
本番適用まで自動化するケース

などさまざまです。

そのため、最初から全てを組み込むよりも、必要になったタイミングで追加していくことが多いです。

例えばTerraform CIであれば、以下のように段階的に成長させることができます。
実際には、最初からLv4を作るよりも、Lv1を運用へ乗せる方が進みやすいケースが多いです。

実際に感じていること

GitHub Actionsの教育やTerraform CI/CDの構築支援をしていると、最初から複雑な承認フローやReusable Workflowを考えるより、まず1つのJobを動かす方が進みやすいと感じることがあります。

CI/CDは作って終わりではなく、運用しながら改善していくものです。最初の段階では「理想のパイプライン」を考えすぎるより、「まず運用に乗せる」ことを優先する方が進めやすいと思っています。

まとめ

CI/CDの導入を検討している人へ伝えたいことは3つです。

AI時代だからこそCI/CDの重要性は高まっている
やりたいことが明確なら最初から作り込んでもよい
まだ導入できていないなら最小構成から始める方が進めやすい

Terraformであれば、まずは fmt と validate だけでも十分です。

CI/CDは一度作って終わりではなく、運用しながら改善していくものです。

まずは fmt や validate だけでもCIに組み込んでみる。
そこから plan、Security Scan、approval、apply と少しずつ追加していく。

CI/CDをまだ導入できていない場合は、そのくらい小さく始める方が進めやすいと思います。