継続的インテグレーション(デリバリー)サービス を利用するようになって思ったことを、いまさらながら記す。
継続的インテグレーション(デリバリー)サービスを利用しないという罪悪
手動でのテストを各人のローカル環境で実行することの問題点
- ものごとは、数量が10倍になるとやり方を変えなければならないことは多い。
- 同時開発する開発者の数が増えてくれば、自分の変更の数よりも、他の人の変更の数が格段に増えてくる。
- その分、自分の理解していない部分で変更が加わって、いつの間にか破綻する可能性は出てくる。
- 手作業でそれぞれの人の環境でテストしていると、テストにかかる時間が増大していって、自分の担当しているコード自体の作業よりも、それ以外のテストを通すことの工数が増えることになりかねない。
いま利用できる状況
- ソースコードから自動ビルドと自動テストの実行をしてくれるサービスがある。
- 利点：
- 自動ビルドと自動テストをチームとして必ず実行できる。
- その結果を、変更の担当者とチームに反映できる。
- 自動テストを自分のローカルPCで行う必要がないので、その間に次のコードの改変に着手できる。
私の開発ターゲットでは自動化テストを利用できないという思い違い
自動ビルド・自動テストを活用している雑誌の記事が、web系の記事であったりすると、「そういうのが利用できるのは、web系の開発だけだよね」などと早合点する人もいるだろう。
しかし、自動化テストできる部分は必ずある。
自動化テストできる部分を引き出せないとしたら、それは設計が間違っている。
たとえOSなしの組み込み系であっても、そのソースコードの中には、自動化テストできる部分がある。
その部分を、継続的インテグレーション(デリバリー)サービスに利用すればいいのです。
車載系の開発のなかでは、ある部品の制御に関わる開発をする際にも、自動化テストをしているようです。
モデルベース開発移行ソリューション 「モデルベース開発とは」 などはその一例です。
自分の担当モジュール以外の部分の実機であるはずの部分(エンジンや、ブレーキなどという物理的な実体を含む場合も)を、それを同等の動作をするソフトウェアでシミュレートすることで、開発を加速している。
だから、「私の開発ターゲットでは自動化テストを利用できない」などという決め付けはしないことです。