新規プロダクトでのCIの重要性

2023-07-15

こんにちは。

今回は新規で開発が始まるというタイミングでどこでCIを構築するべきなのかということについて考えてみたいと思います。

多くのプロジェクトではCI環境が既に整備されていると思います。

CIによって自動でテストが回ったり、コードの静的チェックが自動で行われたりすることでプロダクトの品質を保つことができます。

一方で、新規でプロダクトを作るとなった場合、もちろんテストコードもソース自体もありませんからチェックするものがありません。

なので、新規プロジェクトの場合、どのタイミングでCIを構築するべきか悩むことがあると思います。

今回は、そのことについて考えてみたいと思います。

個人的にはこれをオススメしたいです。

新規プロジェクトで仕様も固まり、技術選定も終わり、よしコード書いていくぞってなったときにプロダクトコードを書く前にCI環境を構築するということです。

僕自身、仕事の新規プロジェクトで0からシステムを作ったことがあるのですが、その一つで一番最初にCIを構築したケースがあります。

最初に構築しておくことで良い点は、最初のタイミングから単体テストを書く意識が生まれることだと思います。

コーディングの初期では、単体テストを書くことを後回しにしがちです。

単体テストを後でまとめて書くと実装の時に単体テストでカバーしておきたかった部分などを忘れてしまって、カバレッジを上げるためのテストケースになりがちだと思います。

一方で、最初からCI環境を準備しておき、単体テストも都度書かないといけない状態を作ることで、品質を上げることができると思います。

また、個人レベルで開発をするケースについても、例えばGitHub Actionsなどを使うことで簡単にCI環境を作成することができます。

個人レベルでも同様に、最初のタイミングでテストが自動で回る環境を作っておくことが良いと思います。

例えばWebサービスでは、ある程度動くようになったタイミングでサーバーにデプロイすることになると思います。

そのとき、デプロイに関してはCD環境を作ることがほとんどなのではないかと思います。

このタイミングで同時にCI環境も構築するというパターンも良いと思います。

CIもCDもですが、使うサービスによっては有料になることがあります。

例えば、GitHub Actionsもプライベートリポジトリでは一定時間を超えると有料になりますし、AWSのCode DeployやCode Buildなども利用時間で課金がされます。

そのため、最初の開発タイミングでCI環境を作成するとコストがかかってしまいます。

できるだけコストをかけたくない場合に関しては、実際にインフラ環境を構築し、テストフェーズに移るタイミングでCIとCDにを構築するというのもアリではないかと思います。

しかし、このパターンでも、単体テストに関しては都度書いておくことは大切だと思います。

強制力がなく、チーム内でのルールということにはなりますが、プルリクエスト単位でしっかりと単体テストを書くことは大切だと強調しておきます。

今回は、新規プロジェクトの場合にどのタイミングでCI環境を構築するかということについて考えてみました。

CI環境はとても大切だと思っています。

また、現在ではGitHub Actionsのような手軽にCI環境を作れるものも出てきているため、敷居はとても下がっていると思います。

そのため、仕事以外でも個人開発でもCIを導入することで「テスト」を意識に植え付けることができると思います。

新規プロジェクト時の参考になれば幸いです。