Zenn
📝

なぜCI（継続的インテグレーション）を行うか

2022/02/15に公開
Angular
Capacitor
Ionic
tech

チーム開発におけるCIの導入について「設定が面倒で後回しにしてた」「今のままでも別に・・・」という話を聞くことがあります。私がコードレビューなどで参画する時にはそういう現場にも容赦なく導入するのですが、そこで話す内容を簡単にまとめておきます。

CIの目的は、開発者の負担を減らすことです。もっというと、CIを導入することで開発者が楽をすることができます。

チームメンバー全員で共有しているGitHub上のコードを主、開発者がローカルにcloneして開発しているコードを従と位置づけるなら、従から主にPull Requestするには、本来は機能要求を満たしてる前提で、以下の確認が必要です。

  • 他の環境でもビルドできるか（自分のパソコンのみの環境に依存していないか / build ）
  • チームメンバーで合意しているフォーマットでコードが書けてるか（1行あたりの文字数、カンマやシングルクォーテーションのつけ方など / prettier ）
  • チームメンバーで合意しているTypeScriptの書き方ができているか（anyの禁止や宣言だけして未使用な変数がないかなど / es-lint ）

更にいうと、 Pull Requestをレビューする人のために、以下があると望ましいです。

  • Pull Request毎の確認用URL
  • Lighthouseを用いたPull Request毎の評価

CIを導入していない場合、Pull Requestを行う者はローカルでこれらをすべて「漏れなく」確認し、確認用URLとLighthouseの結果を添えることが求められます。そして main ブランチにマージすることを判断するレビュアーはこれらが行われていることをローカル上で都度確認・・・と考えるとやってられないですよね。業務内容によっては1日何十回も！

CIを導入するのはまさにこのコストをなくすためです。GitHubにPush/Pull Requestを行うごとに、設定したActionsが自動的に実行されて結果を変えしてくれるので、開発者が上記の確認を毎回手元で行うことから開放されます。 自動化できる業務内容は自動化して、人類がしないといけない作業だけにフォーカスしていきましょう！

よく利用されるActions

  • build: アプリの npm run build に成功するか。単純ミスから特定の環境に依存していないことまでをチェック（ npm i -g で入れたパッケージがある場合起こり得る）
  • lint: チーム内で決めたコードルールを es-lint と prettier で設定した上でこれらのツールを使って違反していないかのチェック。 lint-staged でも実行できるが、うまく実行されない場合/回避した場合でもここで検出できる
  • test: ユニットテスト/e2eテストの実行
  • doc: コードから自動生成できるドキュメントの生成。 TypeDoc などが用いられることが多い。
  • hosting: Pull Request毎/最新mainブランチをFirebase HostingにあげることでURLから確認レビューできるように。
  • lighthouse: lighthouse-ciを用いて、auditの計測

Discussion