継続的デプロイのプラクティス

作者 Mike Bria , 翻訳者 竹中 翔 - (株)ポータルアイランド 投稿日 2010年2月4日

セクション

運用/インフラ,

プロセス/プラクティス,

設計/アーキテクチャ

トピック

デプロイ/データセンター ,

Agile ,

Delivering Quality ,

Delivering Value

タグ

Continuous Integration ,

Lean ,

Releases

原文(投稿日：2010/01/27)へのリンク

Ash Maurya氏によって、"ソフトウェアが１日に何度も（数日に１度、数週間に１度、数ヶ月に１度ではなく、数分に１度）リリースされるプロセス"と表現された継続的デプロイは、リーン開発の"仕掛排除"運動で最近注目されている。多くの人が、これについて興味を持ち、価値のある目標を見出している一方、これが実際どのように達成されたかをなかなか可視化できていない。Ash Maurya氏は会社で起こった自身の経験を説明することで、このギャップを埋めようとしている。

Maurya氏は、なぜ週単位に計画されたリリースプロセスが機能しなかったのかについて、以下のように述べている。

リリースプロセスは最低でも半日、時には丸一日かかりました。ソフトウェアのリリースに週の20%も捧げるのは、小規模なチームにとっては信じられないほどの無駄です。これには、その週に新たに重篤な問題が見つかった時に、各変更の優先順位付けが必要とされる、継続的な調整にかけた時間はカウントしていません。

彼はEric Reis氏のアドバイス、５ステップで継続的デプロイに従って徐々に改善を始めた。そこからは、彼が最も大変だと思った点である、"いつでも簡単にリリースできるようにすること"を中心にストーリーが展開していく。

最初はゆっくりと進めました。小さな変更と、これでもかというくらいのリリースプロセスのチェックを行いました。私は、機能テストを非常に信頼し始めました。というのも、それは変更に対するユーザ目線でのテストを可能にするからです。また、ひどく悪い方法に進んでいることを意味する一連の事象を特定することもでき(例えば、システムにユーザーがいない)、それらの事象をリアルタイムに警告する仕組みをnagiosやgangliaで構築しました。信頼できるものが出来上がったので、我々はより大きな変更や複数個所の変更を始め、その都度、テストやモニタリングのスクリプトを作っていきました。いくつかのイテレーションを回した後、我々が感じる不安感は、計画的なリリースの後に感じていたものよりも、ずっと小さくなっていました。なぜなら、リリース毎のコード変更が少ないので、問題とリリースを確実に対応付けられるからです。

Maurya氏は継続的デプロイプロセスについて、次のような原則／プラクティスを述べている。

• "機能を押し付けない"：リーンのモットーである。重要な顧客から新機能についてのカスタマーフィードバックを得るべきだ。
• "漸進的なコーディング"Maurya氏は、コーディングからチェックイン(自動ビルドのトリガとなる)までを２時間単位で行うようだ。
• "可能な時はいつも単体テストより機能テストを選ぶ"：Muarya氏はSeleniumを使っている。
• "ユーザアクティベーションフローを常にテストする"：ユーザに"最初の満足感を与えるためのクリティカルパス"が機能することを確実に保障すべきである。
• "ソフトウェアの自動アップデートを活用する":ユーザは可能な限りシームレスにソフトウェアを更新可能であるべきだ。Maurya氏は自身のOSGIベースのアプリケーションで、これをどう実現しているかを説明している。
• "アラートとモニタリングの仕組みを作る"：Maurya氏は、システムのおかしな使い方を通知するために、nagiosとgangliaを使っている。
• "アプリケーションレベルの診断機能を用意する"：アプリケーション自身でヘルスチェックが可能だと、ユーザからの問い合わせが減るだろう。
• "想定外のエラーは、一度は大目に見る"：根本原因の理解と、実質的な修正に時間を使う。

もしこれに興味が沸いたなら、少し時間をとってMaurya氏の完全なレポートを読んでみて欲しい。

• 次へ >