この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
おばんです、冬アニメ1話の段階ではポプテピピックが今期覇権だと思った田中です。星色ガールドロップも作って欲しい...！
最近はCIについて学んでいるのですが、なぜCIが必要かということをうまく説明できませんでした。なので、色々記事を読んで今回は以下のことについてまとめてみます。
- CIとは
- なぜCIが必要なのか
- CIサービス
- どんなプロジェクトに導入すべきか？
- 短期的なプロジェクトに必要なのか？
- 受託開発に必要なのか？
- CIが無視される問題
対象読者
- そもそもCIとななにかイメージがつかない人
- なんとなくCIが大切だとはわかるが、具体的に腑に落ちていない人
CIとは
Continuous Integration: 継続的インテグレーションのこと。 アプリケーション作成時の品質改善や作業コストの削減を目的 とし、コミット単位で以下のような作業を実行することである。
- コンパイル
- テスト
- コードやドキュメントなどの静的解析
- デプロイ(ベータ配信)
なぜCIが必要なのか
先述した通り、アプリケーション作成時の品質改善や作業コストを削減するためである。
「コミット単位で」というのは、 細かく確認することで手戻りをなくすため である。もしコミットをため込んだ状態で、いざmasterブランチにマージする前や、デプロイの直前でテストや生成物の静的解析を行って、品質に問題があることに気づいた場合、ため込んだ分だけ手戻りが大きくなってしまう。逆を言えば、 CIを導入することで大きなバグを発生することを防ぐことになる。
もしCIをルールとして守れていれば、GitHub Flowを遵守し、masterブランチが常にデプロイ可能な状態を維持することにもつながる。
CIサービス
コミットごとにフックして、上記の作業を自動的に行ってくれるCIサービスも存在する。CIサービスはCircleCIやTravisCI、iOS & Android向けのBitriseなどが挙げられる。最近のCIサービス関連のニュースとして、buddybuildがAppleに買収されたなんて話もあった。
CIは習慣であって、先述したコンパイル/テスト/静的解析/デプロイの作業を自動で行ってくれるサービスを指すものではない。
CIサービスを利用して環境を構築しておくことで、自分のローカル環境以外でも、コンパイルやテストが通る環境を構築できていると補償することにもなる。
どんなプロジェクトに導入すべきか？
ここからは個人の見解が多め。筆者もまだCIに対する経験値が高いわけではないので、今後意見が変わるかもしれない。
短期的なプロジェクトに必要なのか？
いくつかの懸念点が存在する。特にここで挙げるのは、短期的なプロジェクトの場合に気になってくると思う。
- おおげさなのではないか
- 期間に対してオーバースペックなのではないか
- そんなことより早く開発した方がよいのではないか
むしろ短期的なプロジェクトこそ必要かもしれないと思った。なぜなら、締め切りまで間もないので、 なにか大きなバグを発見したときに、致命傷になりやすいから だ。先述したように、CIの導入は大きな問題への予防につながるかもしれない。
細かい見直しによる細かい軌道修正が戦略的に行えるので、短期的なプロジェクトにこそ導入してみるべきかもしれない。
受託開発に必要なのか？
短期的なプロジェクトへの導入のほかにはこんな疑問もあるかもしれない。
- お客さんに求められているわけではないじゃないか
- 受託の場合、引き継ぎも考える必要があるかもしれない
CIの導入がお客さんに求められていなかったとしても、高い品質のプロダクトは求められているはず。CIの導入は、開発側がプロダクトの品質を保つための仕組みなので、それ自体が目的になることはない と思われる。
引き継ぎ先でCIを使うかどうかは、引き継ぎ先に考えさせればよい。必要であれば引き継ぎ側でCIサービスを契約してもらって、設定してもらえばよいし、設定ファイルもそのまま残しておくか、不要であれば削除すればよい。
CIが無視される問題
もしもCIがレッドになった場合、開発を止めて壊れたビルドを修正させる必要が出てくる。ビルドが壊れたら直ちにそれを修正し、ビルドを安定した状態に戻すことに全員が集中する必要がある。
一刻も早く機能開発がしたい場合、このレッドが無視されがちのようだ。レッドになったユニットテストを修正する暇がないからコメントアウトしたり、テストケースを削除したりすることと同じ現象だと思うが、これは自分たちが補償すべきと思った品質を投げ捨てる行為かもしれない。それでも良いかどうかは現場の判断が必要になる。
このあたりの話は以下を参考にした。
どの段階で導入すべきか？
最初に設定するべき。 なぜなら、なにか問題が起きた場合に、CIの設定間違いを疑えるから。
あとあとになって環境を構築しようとすると、やれテストが通らないだのやれローカルでは実行できるのに、といった問題が発生する。そうすると環境構築のコストは大きくなるので、構築自体が面倒になったり、状況的に優先順位が下がって、しまいには導入しなくていいかという結論に達してしまうかもしれない。
品質を短いスパンで保証するための仕組みが導入できないと、あとになって重大な問題にでくわしがちになる。なので面倒が少ない最初の段階で導入すべきだと思う。
まとめ
まとめてみると、CIを導入しない理由は特に見当たらなさそうに感じました。
つい最近、新規でiOS開発に参加することになって、学びながらCI環境を構築してみようと思ったところ、部内のiOSプロジェクトで意外とCIを導入していないようだとわかりました。文化が浸透して欲しいと思ったので書いてみました。うまく運用していけるとよいなと思っています！
3
