継続的デリバリー読書会 3 #CDStudy -浴衣とGroovy- 参加してきた
２０１２年７月７日に行われました、「継続的デリバリー読書会 3 #CDStudy -浴衣とGroovy-」に参加してきました。
募集ページ
twitterのまとめ
前回、 前々回に引き続き参加してきました。もうメンバーは固定になってきましたね。東京の方と、大阪の方がいらっしゃるのが、頭が下がります。「せっかく来ていただいた遠方の方に、来てよかったと思ってもらえるように」とか、ただの参加者なのに思います。その分、交流をして楽しい話をしたいとは思っているのですが…
今回は、第5章と第6章でした。前回と同じように、一部を輪読しながら、議論するという形です。
前談
そうそう、私事ですが、私は 製造業からSI屋さんに転職しました。理由は、 技術的にも成長したいというのと、 システムでお金を稼ぐ会社で、そのやり方を覚えたいという理由からです。今までいろんな経験をできた元の会社にも感謝していますし、拾ってくれた今の会社に感謝しています。今回は転職してから、現在会社で行っていることの議論ができる 初めての場でした。やはり前職に所属している時よりも、皆さんの話の内容がよく理解できました。私の中でこれは大きい変化です。
第５章 デプロイメントパイプラインの解剖学
ここでは、この書籍の最も大きな主題である、 デプロイメントパイプラインについて説明されている章です。デプロイメントパイプラインとは、 「ソフトウェアをバージョン管理から取り出し、ユーザーの手に渡すまでのプロセスを自動化して表現したもの」と書かれています。開発の中心には 継続的インテグレーションの流れがあり、それに加えてリリースの管理用ツールを用いて管理することで、プロセスの進んでいく様子を見ながらコントロールする形です。
この章で特におもしろかったのは、ユニットテスト、自動受け入れテスト、手動テストのお話でした。まず、ユニットテストですが、デプロイメントパイプライン上では、 ユニットテストだけでは足りないと、はっきり書かれています。そして次の自動受け入れテストをデプロイメントパイプラインに含むことによって、 「顧客の受け入れ基準を満たしているか確認する」と書かれています。これらをつなげる事によって、開発者が行った変更が顧客の要求を満たしていることも確認できるという事が常に言える訳です。加えて、 すべて自動化できるわけではなく、手動のテストも必要な所はある。」とも明記されていました。
この章のディスカッション時には、同じテーブルの皆さんと、会社内のバリューストリームマップ*1について話し合いました。皆さんとお話ししていた所、日本のモデルでは見積り時の提案→差し戻しの流れの辺りでひどい動線になるという認識を共有できました。また、@kyon_mmさんに、進んだプロセスの例を教えていただきました。キーは設計時にそれを満たす受け入れテストをセットで考える事かな。
第６章 ビルド・デプロイメントスクリプト
この章は、ビルドやデプロイに使うツールについて具体的にかかれている章でした。ここであげられていたのは以下のツールです。 これらのツールの中で、著者はBuildrを推していましたね。理由としては、RakeのRubyをDSLとして使う扱いやすさの上に、Maven的な要素をプラスしたもので、非常に扱いやすいとの事です。その横に、私の好きなGradleについても、「GroovyでDSLを書きたいならGradleでもいいだろう。」という形で書かれていました。こういったスクリプト言語で書くDSLもひとつの時代の流れなのかもしれません。
その後のディスカッションでは、他テーブルの方の例から、最も優秀だったビルド、デプロイの仕組みを聞くことができました。ツールはMicrosoftのTFSを使っているようです。ソースのコミットからユニットテスト、デプロイを自動で行っている仕組みを聞きました。TFSは有料ですが、そのツールを購入したチーム全体の決断は素晴らしいと思います。また、全員がうまく使っていこうという意識が働くはずですので、そういった事もみんなに浸透させるキーなのかなと思ったりもしています。オープンソースのツールだとオレオレツールになりがちなので。。。*3
最後に、@kyon_mmさんに、Jenkinsのデプロイメントパイプラインプラグインの例を見せていただきました。なかなか分かりやすい見た目で、おもしろそうでした。Jenkinsに対しての評価がまた上がりました。
