継続的インテグレーション
〜コードに対する早いフィードバック〜
継続的インテグレーション（CI: continuous integration）とは
ソフトウェアの開発プロセスの中で、定期的、自動的にビルド、テストを実施するプラクティスです。
なぜ継続的インテグレーションをするのか
ソフトウェアを常に動く状態になっているのを保証する
ソフトウェアの開発終盤にいきなり統合し、
動かすのはとてもリスキーですし、まともに動かない場合もあるでしょう。
継続的インテグレーションで開発の初期から定期的にビルドを行い、
ソフトウェアを常に動く状態を保ち、それを保証します。
品質を作り込む
開発プロセスの中で品質を作り込み、製品にバグを出さないようにするために行います。
開発後にまとめてテストをするのではなく、
開発中から品質を担保することで無駄を無くします。
どうやっておこなうのか
前提条件
自動化されたテストが必要です。
テスト駆動開発などのプラクティスを使うことで
意識せずとも自動テストをアプリケーションに組み込むことができます。
CIパイプラインの構築
ソフトウェアの開発プロセスの中で、定期的、自動的にビルド、テストを実施するようなCIパイプラインを構築します。
次に紹介するCIツールを使うのが一般的です。
CIツール
具体的なツールに関してはご自身で調べて実施してみてください。
かなり普及しているプラクティスなので
ネット上にたくさんの情報があります。
例を挙げると
- Jenkins
- Travis
- GitLab CI
- CircleCI
- TeamCity
- Bamboo
などがあります。
失敗にすぐに気づけるようにする
失敗に気づけるようにしましょう。
失敗に気づくのが1週間後とかになってしまったら
それまで作ったものに不具合がないのかどうかが不明確になってしまいます。
CIの実行が終わった直後に気づけるようにしましょう。
最近のCIツールではメールやチャットなどに送ってくれるものもあります。
おすすめは常にディスプレイに表示しておいて、
失敗したら画面が真っ赤になったり、大きな音が出るなどをしておくことです。
また、場合によっては
- 失敗した時には全員が手を止めて修正する
ようなルールを追加しても良いと思います。
CIを正常に保つ意識をチーム全員が持つことができます。
注意点
CIツールを入れることが継続的インテグレーションをやっていることにはならない
「CIツールを入れること＝継続的インテグレーションができていること」にはなりません。
継続的インテグレーションはプラクティスであり、文化です。
失敗に気づいて、改善していくサイクルができないのであれば、
CIツールを入れてもあまり意味がなくなってしまいます。
開発を開始する前に継続的インテグレーションを準備する
理想ではありますが、
できれば開発を開始する前に継続的インテグレーションが実施できるようにしましょう。
なぜ継続的インテグレーションをするのかの部分でも書きましたが、
品質を作り込むことが大事になります。
テストがなくても実施する
現状、テストが書かれていないアプリケーションであっても、
ビルドだけでもしておく価値はあります。
コードの修正により、ビルドができなくなるリスクを回避できます。
また、徐々にテストを増やしていくことで品質が向上していきます。
改善をする
CI自体の改善をしましょう。
普段手作業でやっているようなことを
自動化できないか考えてみましょう。
例えば、下記のような改善です。
- テストが遅ければ失敗させて気づけるようにする
- 静的解析に問題があれば失敗させて気づけるようにする
- パフォーマンス、セキュリティ、障害など各種自動化されたテストを組み込み、品質を作り込む
参考資料
さいごに
文章の改善のため、フィードバックがありましたら、こちらからお願いいたします。