ブログ

ティモシー・フィッツの継続的デプロイに関するブログは、デイブと私が継続的デリバリーについての本を出版する1年以上も前に、すでに書かれていた。そんな中でなぜ私たちは異なる名前を選んだのだろうか。実際に違いはあるのだろうか？それとも単に我々が不親切なだけなのだろうか？

我々はいくつかの理由で本の名前を「継続的デリバリー」とすることにした。まず第一に、デプロイがリリースを意味しないというちょっと学者ぶった事実。我々が本の中で言っているように、継続的に顧客受け入れ環境にデプロイすることはできるだろう。それ自体はたいしたことはない。継続的デプロイを特別なものにするのは、自動テスト(加えて非常に短いQAゲート)を通った全ての変更を本番環境にデプロイすることなのだ。継続的デプロイは全ての正しいビルドを利用者に向けてリリースすることなのだ。より正確な名前は継続的リリースかもしれない。

継続的デプロイは継続的デリバリーを意味しているが、逆は真ではない。継続的デリバリーは、リリーススケジュールをIT部門の手の内ではなくビジネスの手に委ねることに関係している。継続的デリバリーを実現することは、ソフトウェアがライフサイクル全体を通して常に本番環境へ配置する準備ができていることを確かなものにすることを意味する。全てのビルドは完全に自動化されたプロセスを起動するボタンをクリックするだけで秒とか分のうちに利用者に向けてリリースすることが潜在的には可能だ。

次に継続的デリバリーは、ビルド、テストおよびデプロイプロセスの全体的な自動化、およびデリバリーに関与する人たち(開発者、テスター、DBA、システム管理者、ユーザー、そしてビジネスサイド)の間の優れた共同作業に依存している。

継続的デリバリーの世界では、開発者はコードをテスターに渡したり、QAによる試験に通ったからといって、その機能が完了になるわけではない。本番環境で動作して初めて完了になるのだ。このことは、スクラムを使っている場合、スプリントの中でさえもテストやデプロイメントのフェーズはないことを意味する。カンバンを使っていて継続的デリバリーすることを望んでいる場合には、とりかかったストーリーが利用者にリリースされるまでは新たなストーリーに着手することはできない。

しかしながら、全ての成功したビルドを利用者にリリースするとは限らない。特に、ソフトウェアの変更とハードウェアの変更が密接に関わっているような組み込み型の製品の場合は、これは通常不可能だ。特定の期間内にリリースされたソフトウェアのバージョンを数個以上持ちたくないというマーケッティングやサポート上の理由がある。(Eclipseがリリース版でも早期プレビュー版にもアクセスできるのとは対照的だ)。恐らくそうしているのには他の合理的な理由がある–重要なポイントは、それらがビジネス的な理由であるに違いないということだ。

そうすると、継続的デリバリーを行っていると言えるのはどういうときなのだろうか？顧客に価値を届けるのに最良の方法であると決めた際に、スイッチを押して継続的デプロイができる状況だ、と言って良いだろう。全ての成功したビルドを顧客に届けることができない場合、ストーリーの完了とは何を意味しているのだろうか？思うに、少なくとも下記に挙げた条件が適用されなければならない。

• ストーリーを含んだビルドに対して完全なテストスイートを流すこと。これによってストーリーが期待されているビジネス価値を届けられることを確認できるし、開発の中でデグレが起こっていないことも確認できる。効率面を考え、ユニットテストやコンポーネントテストや受け入れテストが包括的に自動化されていることを意味する
• ストーリーは本番擬似環境で顧客にデモされる。本番擬似環境は本番環境と等しい。たとえ大規模のクラスタに対してデプロイする際でも、ブルー・グリーン・デプロイメントのような技術を使って、利用者に影響を与えることなく、本番環境上で異なるバージョンのアプリケーションを並行して稼働できるようにすることができる
• 本番環境へデプロイへの障壁はない。言いかえれば、デプロイを決定すれば、ボタンクリック１つで完全に自動化されたプロセスを通してビルドを利用者に届けることができる。これはさらにはキャパシティーや可用性やセキュリティに関する試験についても実施されていることを意味する。SOAを利用していたり、他のアプリケーションとの依存性がある場合には、結合の問題がないことを保証するということも意味する