未来のいつか/hyoshiokの日記 このページをアンテナに追加 RSSフィード Twitter

2011-11-06

Continuous Deliveryを読む。

f:id:hyoshiok:20111106134742j:image:right

f:id:hyoshiok:20111106134951j:image:right

同僚とContinuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))読書会をやっている。

英語の本なので、一人で読むにはちょっと敷居が高くても何人かで読めばどうにかこうにか読了できるような気がする。きっかけとして読書会というのはいいメソッドである

読書会メリットは、わたしのようなものぐさでもある種のプレッシャーがかかるので、どうにかこうにか続けられるというのがあるが、それ以外でもいろいろある。

何といっても読書会のメンバー間では、言葉定義というか概念について共通の理解が深まる。

前回レガシーコード改善ガイドを読んだときレガシーコードというのは、テストのないコードのことを言うという非常に明確な定義読書会メンバーで共有できたのは大きな成果であった。細かいレガシーコード改善メソッドは忘却の彼方であるが、その定義を深く理解できたことは大きな喜びであった。*1

Continuous Delivery(継続的デリバリー)というのは、ソフトウェアリリース継続的に行う方法であるソフトウェアを修正してからそれがリリースされるまでの各種プロセスを高品質コストを安く、安全リリースするには、どのようにすればよいのかを本書では議論している。

ビルドプロセス自動化する方法論としてContinuous Integration(CI-継続的インテグレーション)が知られている。プログラムを修正しビルドをする部分を自動化したものである。通常はビルドの後にテスト自動実行も含む。CIによって修正のコストは劇的に下がった。

デプロイするプロセスを手動でやるとどうなるか。

CI最初の3つのステップ自動化する。開発環境からステージング環境へのインストールが手動だと、様々な設定、操作を逐一ドキュメントする必要があり、作業は細心の注意が必要になる。時には、何百というステップを手で行う。そのような作業は緊張を伴うし多くの場合コストも高く、エラーが起こりやすく、再現可能ではない。ステージング環境から本番環境へのインストールはそれ以上にコストがかかる作業になる。問題が発生した場合コストはそれ以前のコストよりはるかに高くなる。

リリース予測不可能(うまく行くこともあれば、うまく行かないこともある)だし、再現可能ではない。

本書は、リリースまでのプロセスをどのようにして自動化するかということを示している。Continuous Deliveryはまさに、そのようなプロセス自動化することをいう。

どの原理原則も極めてシンプルである。そして強力だ。

例えば、すべての変更は記録する。当たり前すぎる。だけど、実践はどうだ。あなたは、本番環境コンフィグファイルviで変更していないか。オブジェクトファイルパッチを当てて、ソースには変更を反映しないことはないか。本番環境ビルドして、それをインストールしていないか。その一つにでもイエスならば、すべての変更を記録するという大原から既に逸脱している。

フィードバックは可能な限り素早く受け取れなければならない(The Feedback Must be Received as Soon as Possible)。素早いフィードバックポイント自動である自動化されていないと、手動でビルドして、テストしないといけない。そのプロセスは人手を必要として、エラーが入りやすく、楽しくない。もっとも貴重な資源である人々を浪費する。

本書を肴に議論するのが楽しい

読書会でいろいろなグループのエンジニアと議論するのが楽しいビルドプロセス自動化されているかテスト自動化されているか。されていないとしたらそれはなぜなのか。プロセスは再現可能かなどなど、あーだこーだ議論をする。それを自動化するには、どうしたらいいのか。グループによって、うまく行っているところ、うまく行っていないところいろいろあって様々な発見がある。

デリバリーのプロセスが十分自動化されていないグループのエンジニアが、「自動化するにはそれなりのコストがかかるわけで、それを事業側に説明するのがうまくいっていないから、なかなかそれが進まない」というコメントをしたところ、別のエンジニアが、「それって事業側に説明することなのかなー」という発言が出た。その真意は、開発のプロセス自動化するのは、当たり前の話で、ソフトウェアをどのように開発するかということをいちいち詳細にわたって、そこまで説明する必要はないし、事業側もそれを求めているわけではない、そうじゃなくて、我々の仕事は、低コストで高品質サービスタイムリー提供することなのではないか。そのために手動なプロセスはありえなくて、自動化する以外にはないのじゃないのか、などという議論が出て非常におもしろかった。

まあ、自動化についてそのメリット方法論を自分たち自身も十分言語化できていないという反省もあるが、自動化したことがない開発者に向かって、どのようにそれを達成するか逐一説明し、方法をしめしている本書は多くのエンジニアおすすめである。そして、日々トラブルに悩まされている中間管理職課長とかGMとか呼ばれている人々)の人々にこそ読んでほしい一冊である

おまけ

本書は、「この1年の優れたIT系書籍はどれか?「Jolt Awards 2011」が6冊を発表http://www.publickey1.jp/blog/11/1itjolt_awards_20116.html 」で紹介されていたのをみて、社内SNS(Yammer)に書き込んだところ、読書会をやろうという話になって、巻き込まれた。わたし自身は、他の本を読みたいと思っていたのだけど、本書は予想以上におもしろくて、巻き込まれてよかったよかったと思っている。

あと、翻訳されているのを待っている人がいるけど、良書を原書で読むというのは時間節約以上に、自分知的体力向上に役に立つのではなんていらんお節介を言ってみたりして。というか、会社公用語英語になるので、日本語の本を読むモチベーションが沸かないという事情もある。

*1レガシーコード南斗聖拳(外から攻める)。新規開発は北斗神拳(内から攻める)、レガシーコード改善ガイド読書会ふりかえり http://d.hatena.ne.jp/hyoshiok/20100625#p1