継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

発売日は3/5なのですが僕はレビューに参加したのですでに読み終えてます。忘れないうちにエントリを書きたいと思います。

「イントロ」、「本書を読んだだいたいの感想」、「抽象化によるブランチ」、「誤字脱字、訳質」、「対象読者」、「最後に」と続きます。長いので最初の２つだけ読むと良いかも。

イントロ

最近は
アジャイル開発と継続的デリバリー | NTTデータ
だったり
明日から始まるデブサミでの川口さんのセッションにあるようにContinuous Delivery（継続的デリバリー）というキーワードがホットになってきていると思います。

このContinuous Delivery（継続的デリバリー）というキーワードを聞くようになったのは本書からのような気がします。

原書はこちら

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))

Jolt Awards 2011にも選出されたMartin Fowlerシリーズです。翻訳はいつかは出ると思いましたが早かったですね。

参考
この1年の優れたIT系書籍はどれか？「Jolt Awards 2011」が6冊を発表。 － Publickey
なおこのエントリを読むとMartin Fowler氏がContinuous Deliveryを書いたように読めますが著者はDavid Farley氏とJez Humble氏です。

チケットがプラチナ化してダフ屋がいるという噂（嘘）のJenkins勉強会でも原書の話があります。
第5回Jenkins勉強会 - connpass

いちおう僕も本書は原書が出たときから注目していました。
Continuous Deliveryをポチッた - wyukawa’s blog

ただ英語があんまり理解できなかったのでほとんど頭に入っていない状態でした。

そしたら翻訳が出るというので早速レビューに参加させていただきました。

実は僕自身ここ１年近く構成管理、バグ管理、継続的インテグレーションといった開発プロセス系からは離れているのでレビューアーとして適切かどうかちょっとだけ悩みました。ただ何より面白そうなのでそんなことはあまり気にせず参加してみましたが正解でした！

本書を読んだだいたいの感想

本書は500ページを超える大著で扱っている内容も継続的インテグレーション、分散バージョン管理、テスト、デプロイ、インフラ、データベースと非常に多岐にわたっています。

3部構成となっており、個人的には最後の3部が一番面白かったです。

最初から読んでいくと、まず著者の思いというか情熱みたいなのが伝わってきて、「おおー、これは面白そうだ。wktk」とか思っているうちに、２部に入って段々飽きてきます（失礼w）。

しかし3部に入ってインフラを構成管理しましょうみたいな話が出てきてktkrとか思っているうちに、ブランチを切るというのは本質的に継続的インテグレーションに反しますという直球がきます。

そしてリリースブランチはいいけど機能ごとのブランチいわゆるフィーチャブランチはあんまおすすめできなくて抽象化によるブランチのほうがいいよーとつながります。

抽象化によるブランチ

ここが一番面白かったのでもっと詳しく書いてみます。余計なことも書いているので長いですw

開発を進めて行く中でメインラインは常にリリース可能にしたいわけです。そうじゃないと継続的にデリバリーできないしね。結合試験までコンパイル通らないとかだと話にならないわけです。これは極端かw

しかし大きな機能追加をしたいケースというのはあります。

こんなイメージ。青い部分が新機能部分で凸凹部分がインターフェースだと思ってください。

この場合ブランチを切って機能追加はそちらで行いメインラインには影響を与えないようにすることでマージ前までは平和な状態になります。そうマージするまではね。

こんなイメージ

コードを大幅にいじっているはずなのでマージは困難なはずです。これはGitだから楽とかそういう話にはならない。コンフリクトがおこらなかったとしても（そんなことはないだろうけど）、意味的なコンフリクトがおこっている可能性があります。

こういうケースだってありえますよね。
コンフリクトが発生しなくても壊れる場合 - ぐるぐる～

ちょっと話がそれるけど、大きな機能追加をブランチで行う具体例としてHadoop 0.23で加わったMapReduce 2.0が挙げられると思う。
詳しく見てないんだけど
[MAPREDUCE-279] Map-Reduce 2.0 - ASF JIRA
を見るとブランチ
http://svn.apache.org/repos/asf/hadoop/common/branches/MR-279/
で機能追加してtrunkに大量マージしたっぽい。

ここまで大きな機能追加じゃなくても機能単位にブランチ切って作業するというのはDVCSの発展でOSSの世界では一般的になってきた感じがします。

しかし本書ではOSS以外でのフィーチャブランチはあんまりすすめていません。しかも上記で述べたマージの辛さ以外の理由からです。じゃあなんでマージの辛さを書いたかというと書きたかったからだ。キリ。

開発者がブランチ切って作業を進める。リリース間近になってマージする。ここで初めてテストチームはリリース用に統合された状態を見ることになります。これだとちゃんとバグフィックスする時間も無くなりユーザに低品質なものをデリバリーしちゃうよね。これが本書でフィーチャブランチがおすすめされていない理由です。

なので別のやり方は無いかということですが、ブランチは切らずにコードラインは1本にしてそのかわり開発中の機能をユーザからは見えないようにすることで上記の問題を解決します。

要は構成管理上の話ではなく設計の話に持っていきます。

機能追加する際に変更しなければいけない接合部を抽象化してレイヤをかませてプラッガブルな状態にします。DIコンテナとか使えるかもしれません。

こんなイメージ

さながらEclipseのプラグインアーキテクチャのようにして新機能が完成するまでは設定ファイルなどでその機能を無効にしておきます。そうすれば既存の機能に悪影響を及ぼすことはありません。新機能が完成したら設定ファイルを変更して機能を有効にすればいいという話です。これならブランチも切らないのでマージする必要はありません。しかもインクリメンタルに開発できます。

これを読んで僕はなるほどなーと感心するとともにプラグインアーキテクチャを作るのは難しいだろうなーとも思いました。最初から未来を予想してプラグインアーキテクチャを設計するのは難しいので、似たような機能が出てきたら後でリファクタリングして設計するような気がしますがそれでも難しいだろうな。。。

設計スキルの問題はおいといても、受託開発だとそんなリファクタリング工数はおそらく取れないので新機能追加は既存機能をコピペして修正とかになりそう。自社サービス開発ならまだできるかもしれない。

Eclipse, Trac, Redmine, Jenkinsなど有名なOSSプロダクトはプラグインアーキテクチャを持っていて開発者が自由にプラグインを書けるようになっています。このプラグイン文化が本体の発展にも大きく寄与しています。この辺を学ぶ価値はありそうですね。

抽象化によるブランチの話は以上です。

誤字脱字、訳質

個人的な感覚でいうとIT書籍というとまず誤字脱字が多いと思っています。小説を読んでいて誤字脱字を見つけたことは無いですがIT書籍だとざらです。初見で3,4個なら良い方で多いのだと10個以上あったりします。これは名著といわれるものでも変わりません。

本書は僕を含めて何人かのレビューアーがいたのでその問題は大分無くなっていると思います。さすがに誤字脱字が全く無いとは言い切れないですが。

つづいて訳質が気になる人も多いでしょうが、これは訳者を見れば問題無いと思う人は多いかもしれない。実際に本文を読んだ僕も訳はこなれていて良いと思っています。それにこの辺もレビューアーが結構突っ込んだのでブラッシュアップされています。

対象読者

「全ての開発者が読むべき本だ！」と言うのは簡単ですが、それだと「全てのJava開発者が読むべき100冊の本」みたいで、もっと絞れやゴラア！だと思うのでw　もっと絞ると構成管理者でしょうね。もっと言うとShibuya.trac勉強会やJenkins勉強会に参加するような人が読むと参考になると思います。

最後に

最後にこんな素敵な本を執筆したDavid Farley氏とJez Humble氏、さらにすてきな翻訳をデリバリーしてくれた和智 右桂さんと高木 正弘さんに感謝します。ありがとうございました！