# 継続的インテグレーションでやってはいけないこと

f:id:numanuma08:20141107214155j:plain

JenkinsやXcode Bot,あるいは外部サービスのTravis CIやCircle CI, Girlab CIなど、継続的インテグレーションを実現するためのアプリケーションやサービスは非常に充実しています。どれを選ぶのが良いかは、チームやプロジェクト次第なので自由にすれば良いと思うのですが、やはり共通する「アンチパターン」ってあるなと思ってきたので、まとめてみます。

警告やエラー、失敗するテストを放置しない

ユニットテストなどで失敗するケースが生じた場合。本当はユニットテストなのでアプリケーション単体で閉じている必要があるかもしれませんが、場合によってはサーバーとの接続をそのままテストしているケースがあるかもしれません。それ自体は悪じゃないと思いますし。

問題は、例えば連携先サーバーの問題などでテストに失敗するケースがあった場合。「これの原因はわかっているから放置しよう」ではダメだと思います。と言うのも、警告やエラー、テスト失敗を放置していると重大な失敗を見落とすことがあるから。失敗することがわかっている/失敗することがあるテストならば、いっそ飛ばしてしまうとか、何度もやる必要が無いのであれば、１日１回だけやるように設定するなどをした方がよいかと。

あるいは、本当は外的要因でテストが失敗することは良くないので、これを機にテストを見直すのもありかもしれません。

時間がかかりすぎないようにする

ビルド、テストにかかる時間が長すぎると、CIツールを利用する人も面倒に感じます。CIツールのビルド成果物をリリースにも利用したりしている場合、ビルドを待つ無駄な時間が発生することも。マシンスペックの見直しも対応方法の候補の１つですが、それ以外にプロジェクト設定の見直しも考えた方が良いと思います。

例えば、時間のかかるテストはコミット毎ではなく１時間に１回だけにするとか。例えば静的解析やドキュメント作成も同時に行うのなら、それらは別のビルドタスクにしてパラレルに実行できるように設定するとか。

時間がかかってボトルネックになっている部分を見つけて適宜対応をする。まあ、基本ですね。問題を見つけても放置することがないように。

設定を複雑にしない

主にJenkinsなのですが・・・。Jenkinsの場合ビルド前後に実施できるタスクやビルドのタスクでも様々な設定を行うことができてしまいます。最初のうちは良いのですが、プロジェクトが大きくなったり、設定をした人が消えた時、そこに残るのは秘伝の誰にも触れない設定のみ・・・。しかもJenkinsは設定を内部でXMLで管理はしていますが、バージョン管理も（プラグイン無しには）できないし、ビルドに失敗しても何が原因か特定し難いことも。

そういった事にならないためには、ビルドタスクは極力利用しているビルドツールで簡潔させるようにするべきかと思います。Travis CIとかはこの辺りがよく出来ていると思いました。ymlを設定するだけで良いなんて・・・。

と言っても最終的にantとかmavenのややこしいビルド定義ファイルが生成される未来が見えないことも無いのですがね・・・。その辺りはドキュメント等で補完でしょうか。いいアイデアがあれば誰か教えてください。