CI/CDに取り組むポイント
ここからはCI/CDに取り組むときに押さえておくと良いであろうポイントをいくつか紹介します。プロダクトの内容や規模、メンバーによっても異なる部分ではありますが、参考にしてみてください。
小さく始めて育てる
特にプロジェクト開始時はCI/CDを導入しやすいタイミングです。ぜひプロダクトがHello World状態の内にCI/CDを組み込むことを検討してみてください。Hello Worldレベルの単体テストで良いですし、静的解析をかけられるファイルが2〜3しかなくても問題ありません。
プロダクトの初期からCI/CDを組み込むことで、CI/CDの導入自体がしやすいです。プロダクト自体がまっさらな状態のため、公式ドキュメント通りの方法で導入できるでしょう。そしてプロダクトの成長と共に育てていくことができます。CI/CDを考慮したプロダクトの構成も意識できるでしょう。
すでに開発が進んでいるプロダクトにCI/CDを導入したい場合も、同じように小さく始めることを意識すると良いと思います。「コードをpushしたら静的解析と自動テストが実行されて、プルリクエストがマージされたらデプロイされる」という状況をいきなり目指すのはとても難しいですし、時間もかかります。
まずは1件の自動テストを動かすところを目指しましょう。静的解析を実行するだけでも良いですし、ビルドができることを確かめるだけでも良いです。大事なことは、小さく始めて継続して育てていくことです。
改善する
静的解析を入れてみたもののチェック内容が期待しているものではなかった、失敗時の通知内容が役に立っていない、ほとんど起きえないだろうと思っていた失敗が意外とよく起こる、などやってみてわかることはたくさんあります。
毎日感じる手間や、やっている意味がないと思っているものを残しておくと、段々と使われなくなっていきます。放置され始めると最新コードへの追従も行われなくなりエラーも発生するようになりますが、そのエラーさえも放置され始めてしまいます。
特に「度々発生するけど原因はよくわからないしプロダクト本体には影響がない」というエラーは厄介です。改善するモチベーションがなかなかあがらず、ついつい放置してしまうといったことがあるでしょう。これの何が問題かというと「エラーが起こることが通常の状態となり、重要なエラーが発生したときに見逃してしまうかもしれない」ことです。「いつものあれだな」と見誤ることです。
「解決が難しい」という状況は確かにある一方で、そのエラーが残ることで他に与える影響を可能な限り小さくすることも考えてみましょう。例えば通常のエラーとは通知の見た目を変える、といったこともできるかもしれません。
CI/CDのプロセスを継続していくには、CI/CD自体を日々改善することも重要です。小さな改善を積み重ねていきましょう。
トラブルに備える
CI/CDは失敗します。正しくチェックに引っかかってくれた、という場合はさておき、ネットワークエラーのような意図しないエラーが原因で発生する失敗も意外とよく起こります。さらにエラーを検知できておらず、期待する処理はできていないにもかかわらずワークフロー全体としては成功しているように見える場合もあります。
プロダクトの実装と同じように、例外的なエラーは起こり得ないか、起こった場合はどう処理するべきか、ユーザーへの通知（ここでは開発者への通知）をどうするべきかを検討し入れ込みましょう。
そして失敗したときのリカバリーも大事なポイントです。次の自動実行に備えて作られてしまったデータを消す必要がある、手動でデプロイし直さないといけない、などの対応が必要になることもあります。最初から全てのエラーにもれなく対応したワークフローを作ることはとても難しいですが、ひとつひとつ対応してCI/CDを育てていきましょう。
早く失敗できる構成にする
CI/CDの全体のプロセスとして、早く失敗できる構成にしましょう。
例えば、「自動テストも成功したしビルドができることもわかっている、mainブランチにマージもできたし、次はデプロイだ」という段階になって初めて静的解析でエラーがでていることがわかるのは遅いでしょう。静的解析の対応はコードに手を入れるものですし、自動テストやビルドはもう一度確かめておきたくなります。
どのタイミングでどのタスクを行うのか、というCI/CD全体のプロセスを考えることはとても重要です。このプロセスはCI/CDのワークフローの内容の順番だけでなく、開発者の手が入るプロセス、例えばレビューなども含みます。レビューの前に静的解析や自動テスト実行は終わっていて欲しいですよね。
できる限り早い段階で失敗がわかる構成にすることは、失敗時の修正コストを小さくすることにつながりますし、これが積み重なれば開発のサイクルを早めることにもなります。
CI/CDはチームみんなで育てるもの
CI/CDだけに限った話ではありませんが、チーム全員で取り組むことをおすすめします。特定のメンバーだけがCI/CDを改善・修正できるのではなく、複数人、できればみんなで何かしら関わっていくことが、継続的にCI/CDを育てていくことにつながります。
そのためにもCI/CDをわかりやすくしておくことは重要です。CI/CDはコマンドの連続やymlファイルなどで記述することも多く、説明的な文章ではありません。だからこそドキュメントを整備したり、命名規則を工夫したりしましょう。
仕組み化の第一歩
CI/CDをやってみよう！ と思ったものの、何から手をつければいいのかわからない方もいるでしょう。
もし今、手作業で行っているコマンド実行がある場合、スクリプト化してワンコマンドで実行できるようにしてみましょう。自動化への大きな第一歩です。実際にGitHub Actionsなどで自動化しようと思ったときに、スクリプトファイルになっていればそれを呼び出すだけですむため、自動化に手をつけやすくなります。
筆者は実行コマンドが少なくてもスクリプト化などをしてワンコマンドで実行できるようにしておくことをおすすめしています。今はコマンド数も少なく、オプションも必要ないかもしれません。プロダクトが育ってくると、前処理を入れたくなったり、コマンドのオプションが増えたり、やらなくてはいけない処理がどんどん増えていきます。ひと塊の処理として一箇所にまとまっていれば、変更もやりやすくなります。
開発中のプロダクトの場合は、リポジトリの整理から手をつけてみるのも良いと思います。例えば、READMEをしっかり書いてみる、設定ファイルをまとめてみる、ディレクトリ構造をわかりやすく変えてみる、スクリプトにコメントを入れて処理をわかりやすくしてみる、などは手をつけやすいのではないでしょうか。少しずつ環境を整えていくことで、自動化しやすい場所も見つけやすくなり、イメージがつくようになってきます。
AIとCI/CD
少し話は変わりますが、筆者自身も最近よく考える「AIとCI/CD」の関係について、最後に触れておきたいと思います。AIツールが登場している今、CI/CDは今後どうなっていくのでしょうか?
大きく2つに分けて考えてみます。まずは「CI/CDにAIを組み込む」という観点です。AIを使ってCI/CDを構築する、といったことから、CI/CDの中の1つのタスクとしてAIを利用することも今後もっと増えていくでしょう。
例えば、前節で話をした仕組み化の第一歩はAIツールを使うことでより簡単に行えます（第一歩として「AIツールを使う」のも良いですね）。CI/CD全体のプロセスの中のタスクであるレビューに関してはGitHub Copilotのコードレビュー機能も登場しています。
AIを組み込むことで早く作業ができるだけでなく、人間が今まで見逃しがちだった点や手が回らなかった点をチェックをしてくれるほか、品質にも良い影響を与えるのではないかと思います。発展途上な部分はありますが、筆者はこれからも積極的に使っていきたいです。
もう1つ、「AIツールを使って作られたコードをCI/CDで取り扱う」という観点もあります。AIツールによって大量に作られるプロダクトコードやテストコードを今までのようにレビューしているのではいつか人間が参ってしまうでしょう。AI時代のプロダクトの品質保証やリリースはどうあるべきなのか、現時点では筆者も「これだ」という答えがありませんが、特に注目して考え続けていきたいです。
また、MCPサーバーなどの登場によってもわかるように、人間が何かしらのツールを使ってCI/CDを構築することは確実に減っていくだろうと筆者は考えています。
だからといって、いますぐCI/CDのプロセスが不要になることはないでしょう。特にこの過渡期にあっては、ガードレールや最終関門として、今まで以上に重要な役割を担っていくのではないかと考えています。
筆者自身も、これからの「AIとCI/CD」の関係を日々の業務の中で見つめつつ、試行錯誤を続けていきたいと思います。
まとめ
今回は以下の内容を取り上げました。
- CI/CDとは
- CI/CDに取り組むポイント
本連載はこれで以上となります。ここまで読んでいただきありがとうございました。
参考書籍
- 『入門 継続的デリバリー』（Christie Wilson 著、Jez Humble、Eric Brewer 序文、渡辺 光一 監訳、井上 渉、庄司 祐馬、遠山 雄二 訳）
