CI/CD はどう組みますか

CI で確かめること

CI (継続的インテグレーション) は、変更を押すたびに、自動で確かめる仕組みです。

1. lint と型の検査書き方の誤りや型の食い違いを、すぐ見つけます
2. テスト単体テストや結合テストを回し、前に動いていた物が壊れていないかを確かめます
3. ビルド本番と同じ手順で組み立てられるかを確かめます

name: ci
on: pull_request
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run lint
      - run: npm test
      - run: npm run build

この検査が通らないとマージできない、という決まり (ブランチの保護) をリポジトリに設定しておくと、壊れた物が main に入りません。GitHub Actions のほかに、GitLab CI や CircleCI なども同じ形で組めます。

CD で出すこと

CD (継続的デリバリー、または継続的デプロイ) は、確かめた物を、決まった手順で出す仕組みです。

• プレビュー環境 PR ごとに、その変更だけを入れた環境を作り、URL を PR に貼ります。レビューする人が、画面を実際に触って確かめられます
• 自動の配備 main に入った物を、手を介さずにステージング、本番の順に出します。人の手順を減らすほど、出し忘れや手順の間違いが減ります
• 少しずつ出す新しい版を、まず一部の利用者や一部のサーバーにだけ出し (カナリアリリースと呼ばれます)、エラーの率や遅さを見てから広げます
• すぐ戻す前の版を残しておき、問題が出たら 1 つの操作で前の版に切り替えます。直してから出し直すより、まず戻すほうが利用者への影響が短く済みます

トレードオフ

検査を増やすほど安心ですが、CI が遅くなり、待ち時間が開発の速さを削ります。遅くて不安定な検査は、やがて誰も信用しなくなります。だから、速い検査 (lint、単体テスト) は毎回、重い検査 (画面を通した試験) は main に入る前だけ、のように分け、変わった所に関係する検査だけ回す工夫もします。

少しずつ出す仕組みも、作るのに手間がかかります。利用者が少ないうちは、プレビューで確かめてから一度に出し、すぐ戻せる手順だけ用意する、という軽い形で十分なこともあります。

話すときは、自分が関わったリポジトリで、PR を出してから本番に出るまでに何が走るかを、順に 1 つ説明できるようにしておきます。