知ったかぶろう。Jenkins編

ジェンキンス！

ね、聞くでしょこの名前。あなたの職場でも。

ゲームQAという職種では、あまり使うことはないかもしれませんが(web系とかIT系のQAエンジニア職だと、使うこともあるようですが。求人の募集要項とか見る感じだと)、一緒にお仕事しているエンジニアや企画の人は、このツールを使ってるわけなので、話を合わせられるくらいには知ったかぶれる方が、デキるゲームQAだと思ってもらえると思うわけです。

ということで、この本をサラっと眺めてみました。さぁ、Jenkinsのことを知ったかぶりましょう。

[改訂第3版]Jenkins実践入門 ――ビルド・テスト・デプロイを自動化する技術 (WEB+DB PRESS plus)

jenkinsのことを、IT用語で説明しても結局ちんぷんかんぷんになると思うので、ここは思い切ってラーメンで話を進めみたい。そう、この世のほとんどは、ラーメンで例えられるのだ。

ということで、君は新作のラーメンを開発している店長だ。君の店にはスープ担当、面担当、具担当のスタッフがいる。こういうイメージ。

まずはジェンキンス導入前の新作ラーメンの開発フローは以下の通り。

試作のラーメンを作るのは18時。この時間に、それぞれのスタッフから、麺、スープ、具を受け取り、店長のあなたが一杯のラーメンを作り上げる。そして、試食をし、改良点があればスタッフに伝え、明日の同じ時間までに、改良したモノを持ってきてもらうようにする。これを繰り返すことで、至高の一杯を作り上げる。

このフローもシンプルで悪くはないんだけど、弱点は試作のラーメンを一日一回しか作れない事だ。そのため、満足のいく一杯が出来上がるのに、日数がかかってしまう。世はラーメン戦国時代。スピード感無きものは、いずれ消え行く運命にある…。

ここでジェンキンスだ。

店長のあなたは、ジェンキンスと名乗る初老の男性を雇うことにする。彼に「へいジェンキンス、ラーメン作って」と言うと、麺、スープ、具担当のスタッフから、それぞれ最新の素材をもらってきて、ラーメンを作り、あなたの前に差し出してくれる。

これのいいことは、時間を選ばずに、いつでも最新の状態のラーメンを試食出来ることにある。つまり試食とフィードバックの回数を劇的に増やすことができるのだ。それはすなわち、品質の高いラーメンを短期間で完成させることが出来ることを意味する。

ジェンキンスの仕事はそれだけにとどまらない。正確な舌で味見もしてくれるのだ。例えば、スープ担当スタッフが、手違いで砂糖と塩の分量をテレコにしてしまったとしよう。このときジェンキンスがいれば、このスープがラーメンとして誰かの口に入ってしまう前に、「このスープ、砂糖と塩の分量が間違えてるよ。作り直してちょ」と、スープ担当に伝えてくれるのである。つまり、ミスの早期発見もしてくれる。

おわかりだろうか。ジェンキンスが居れば、ミスも早期発見でき、開発サイクルのスピードも上がり、品質の高い新作がいつもよりも早く完成するのである。

群雄割拠のラーメン業界。質の高い新作を出し続けることが、生き残る道であり、ジェンキンスはその一翼を担ってくれる頼もしい相棒というわけなのだ。

と、イメージはざっくり、こんな感じなのですが、実際のIT用語にも置き換えておきましょう。

素材を集めて1杯のラーメンを作り上げることを、IT用語では「デプロイ」といいます(試作品にかぎらず、実際の販売商品も含む)。

気軽に試食品を作って(デプロイして)改善をスピーディに進めることを、「継続的インテグレーション（CI、と約される）」といいます。世の中的にジェンキンスは、CIを促進するためのツールとして扱われているようです。

勝手に味見をしてダメ出ししてくれることは、「自動テスト」と言います。

例え話では、「ジェンキンス導入前は18時という決められた時間に作る」と書きましたが、実際、10年ほど前に私が居た現場ではそんな感じでした。テストROMのROM焼きを、9時と15時にやってたなぁ。

ラーメン食いたくなってきた。