未来のいつか/hyoshiokの日記

hyoshiokの日々思うことをあれやこれや

Continuous Deliveryを読む。


同僚と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