GREEにおけるJenkins, その2 | GREE Engineering

こんにちは、エンジニアの岡崎(@watermint)です。今回はGREEにおけるJenkinsをつかった品質管理について紹介します。 hourlyビルド 岡崎がGREEに入社したのは1年半前ですが、そのときから感じているのがGREEの開発速度は非常に速いことです。ソースコードレポジトリには多くの優秀なエンジニアが日々数百以上のコミットしています。 GREEのシステムは多くのサブシステムを組み合わせたものですが、手元の些細な変更が全く予想しない別のプロジェクトで問題を起こすことがあります。こういった問題は通常、リリース前の結合テスト等の段階で検出します。 リリース前のテストで問題が発覚すると、当然その修正をして再度修正をリリースプロセスにのせるということになるのですが、これには他のエンジニアの作業を止めてしまったりリリースの順序を調整が必要になることがあります。 こういった事態を防ぐために単

[griefworker]

(引用)「「コミット前に十二分にチェックをしろ」という精神論の品質管理から、「単体テストによってチェックは担保される」という仕組みによる品質管理に代わり、品質が向上した」

[ainame]

良い話 > 「コミット前に十二分にチェックをしろ」という精神論の品質管理から、「単体テストによってチェックは担保される」という仕組みによる品質管理に代わり

[tachesimazzoca]

「コミット前に十二分にチェックをしろ」という精神論の品質管理から、「単体テストによってチェックは担保される」という仕組み

[yamaeda]

GREEにおけるJenkins, その2

[hagihide]

Jenkins

[YaSuYuKi]

理想は、常に、すべてのテストケースを実行しながら開発することだけど、実際はテスト速度の問題で無理があるので、コミット時テストが自動化されると、かなり楽になるのは間違いない

[y-kawaz]

なるほど『「コミット前に十二分にチェックをしろ」という精神論の品質管理から、「単体テストによってチェックは担保される」という仕組みによる品質管理に』は確かに精神的負担が減りそうで良いね。