ブログ

継続的デリバリーの8つの原則

1. ソフトウェアのリリースやデプロイのプロセスは繰り返し可能であり信頼性が高い必要がある。

このことは2つめの原則にたどり着く。

2. 全てを自動化する！

手動のデプロイは決して繰り返し可能で信頼性が高いことには成り得ない。 あなたは繰り返し行う全てのタスクを自動化することについて本気で投資する必要がある。そしてこうすることによって信頼性に繋がっていくのだ。

3. なにか難しかったり苦痛なことがあったら、それを何度もやってみる

表面的には、ばかげた話のように聞こえるかもしれない。しかし基本的にこれが意味していることは、苦痛であることを頻繁に行うことは、あなたがそれを改善し、多分自動化する方向に導いてくれるはずだ。そして最終的には苦痛がなくなり容易に行うことができるようになるだろう。 データベースのスキーマをデプロイすることを例にとってみてみよう。もしこれがトリッキーだったら、頻繁に実施しようとは思わずに先延ばしにして月に1回くらいにするだろう。本当にあなたがすべきことは、スキーマをデプロイするプロセスを改善して、それを行うことを得意にし、より頻繁ー例えば必要なら1日1回に行えるようにすることだ。 毎日同じことをやっているなら、月に1回しかやらない時よりも、より良いやり方にできるはずだ。

4. 全てをソースコード管理システムで管理する

このことは現代では当たり前に聞こえるかもしれない。ソースコード管理システムに全てを登録していないのは重大な問題だ。明らかにそんな人はいないだろう。そんな奴を知ってるかい？

5. 完了は「リリースされたこと」を意味する

このことは、ソフトウェアがユーザーの手に渡り正しく動作して初めてでき上がりだということだ。 「僕が知る限り僕のコードは動いたから完了だぜ」ってことはないのだ。 私は、チームが変更を行ったコードが本番環境に反映されて正しく動作することを確認しすることを望み、本番システムでの変更が正しく動作するかをモニタリングしていたチームと一緒に働くという大変な幸運に恵まれていた。 一方で、自分たちの責任はVCS上でコードをチェックすればおしまいだ、という考えのチームと働いたこともあった。

6. 品質をつくり込む

品質メトリクスへ投資する時間を確保しよう。 よい目標のはっきりした品質メトリクス（ユニットテストのカバレージ、コーディングスタイル、規約違反、複雑度とかとか）をもつプロジェクトはだいたいにおいて、それらがないプロジェクトよりもマシなプロジェクトだし、長期間の稼働における保守も容易だろう。

7. すべての人にリリースプロセスに対しての責任がある

企業にとって開発者のノートPC上だけで動作するソフトウェアはなんのお金も産まない。 似たように、開発に関する計画のないプロジェクトは決してリリースすることはできないし、お金を産むこともない。 企業はプロダクトを顧客にリリースすることによってお金を産み、それゆえ、このリリースプロセスは社内の万人の関心事になるべきである。 開発者は、作ったものがどのようにデプロイされるかについて意識して開発に取り組まなければならない。 プロジェクトマネージャはデプロイメントに注意を払ってプロジェクトの計画をたてなければならない。 テスターはコードの問題に対しての注意と同じくらいデプロイメントに関する問題についてテストすべきである。（そしてデプロイメントは自動化され、開発タスクの1つとしてプロジェクトに組み込まれるべきである。）

8. 継続的に改善する

時代遅れとかメンテナンスができなくなるまで自分たちのシステムを放置してはいけない。 継続的な改善が意図するところは、あなたが関わっているシステムは常に進化し、そのためには必要ならいつでも簡単に変更できるようになってなければならないということだ。

これらの原則と関連して。。。

継続的デリバリーに関する4つのプラクティス

1. バイナリは一度だけビルドする

私が様々な環境で何度も再コンパイルする様をみた回数にあなたは愕然とするだろう。バイナリは1バージョンにつき1度だけコンパイルされるべきである。バイナリはどこかあなたのデプロイメカニズムがアクセス可能な場所に配置されるべきで、デプロイシステムはこのバイナリを複数のそれぞれの環境にデプロイするべきなのだ。

2. すべての環境にデプロイするのに完全に同一のメカニズムを使う

こんなの明らかに聞こえるだろうが、QAへのデプロイは自動化されていたのに、本番へのデプロイは手動だったというケースを本当に見たことがあるんだ。 他にも、QA環境も本番環境へもデプロイは自動化されていたが、それら2つが完全に違う言語で作られていたってこともあった。狂気の沙汰としか言いようがない。

3. デプロイメントでスモークテストを実施する

あなたのデプロイが大成功になるチャンスを放置してはいけない。スモークテストを書いてデプロイプロセスの中に含めよう。 それから、いくつかの単純な診断テストを含めることも望ましい。あるべき姿をテストするような感じで、例えば本番環境のサーバにおける想定しているファイルの一覧と実際のファイルの一覧を比較したりといったものだ。私はそれを診断テストと呼んでいるのは、問題が起こっている場合に真っ先に教えてくれるものだからだ。

4. 何か問題が起こったらラインを止める

途中で失敗したらやめにして、プロセスを再度最初からやりなおすこと。パッチをあてたりハックしたりしてはいけない。 問題が起こった場合、それがどの部位だろうと、デプロイを破棄（例えばロールバック）し、問題を適切に修正し、修正内容をソース管理システムに登録してからデプロイプロセスを再度開始すること。 多くの人は、稼働しているシステムへのデプロイにおいてちょっとした停止画面が出るような場合や、問題が起こったときに修正することができる人がいないような真夜中の本番環境の変更のような場合には特に、そんなの不可能だ、とコメントするだろう。 それに対しては、私は、論点が違うと言いたい。 1つは、たった1つの停止画面が出たような場合に、本番システムをハッキングすることはもっともやってはいけないことだ。なぜならあなたが他の環境も同じようにハックしないかぎり同じ問題が他でも起こるということだからだ。 2つめに、次回デプロイをする際に、同じ問題が再度起こるであろうからだ。 3つめに、真夜中に問題を修正してくれる人が誰もいない状況下でデプロイするということは、継続的デリバリーの7つめの原則 ー全員がリリースプロセスに対して責任を持っているーに対して十分な注意を払っていないということだ。周りのサポートが受けられない状況下においてはリリースすることは推奨できない。それは常識に反している。