こんにちは、エンジニアの岡崎(@watermint)です。今回はGREEにおけるJenkinsをつかった品質管理について紹介します。

hourlyビルド

岡崎がGREEに入社したのは1年半前ですが、そのときから感じているのがGREEの開発速度は非常に速いことです。ソースコードレポジトリには多くの優秀なエンジニアが日々数百以上のコミットしています。 GREEのシステムは多くのサブシステムを組み合わせたものですが、手元の些細な変更が全く予想しない別のプロジェクトで問題を起こすことがあります。こういった問題は通常、リリース前の結合テスト等の段階で検出します。

リリース前のテストで問題が発覚すると、当然その修正をして再度修正をリリースプロセスにのせるということになるのですが、これには他のエンジニアの作業を止めてしまったりリリースの順序を調整が必要になることがあります。

こういった事態を防ぐために単体テスト／結合テストを毎時実行しレポートするような仕組みをJenkinsを用いて構築しています。

毎時実行することで、問題が発生し始めた時刻が絞り込め、原因の特定もよりスピーディーになりました。

品質管理されたブランチ

GREEではgitやsubversionにソースコードをコミットする際に、フックを利用して文法チェックしてSyntax errorがあればコミットできないような仕組みを用意しています。これによって多くのミスが事前に検出しています。 しかしながら、コミットに必要なファイルが追加されていない場合や、単体テストに失敗するようなコードがコミットされるなど不完全なコミットも可能でした。

そこで、Jenkinsを使い開発者がcommit/pushするブランチ(current)と品質管理されたブランチ(develop)を分けました。currentブランチに変更があったことをフックしてJenkinsが単体テストを実行し、テストが通った場合のみdevelopブランチにマージするようにしました。

これにより「コミット前に十二分にチェックをしろ」という精神論の品質管理から、「単体テストによってチェックは担保される」という仕組みによる品質管理に代わり、品質が向上しただけでなくエンジニアのメンタリティーも、仕組みを改善することにより集中できるように変化しました。

お知らせ

7月29日にJenkins ユーザ・カンファレンス 2012 東京が開催されます。S406-5 : 開発者とディレクターの視点を変えていく方法 (スポンサーセッション：GREE)というセッションにて登壇いたしますのでご期待ください。