継続的デリバリー

90年代後半、私は当時スイスの保険会社で働いていたKent Beckを訪ねました。彼はプロジェクトを案内してくれましたが、彼の非常に規律正しいチームの興味深い側面の一つに、毎晩ソフトウェアを本番環境にデプロイしていたことがありました。この定期的なデプロイによって、彼らは多くの利点を得ていました。作成されたソフトウェアが無駄に待たされることがなく、問題や機会に迅速に対応でき、迅速なサイクルにより、彼ら、ビジネス顧客、そして最終顧客の間でより深い関係が築かれました。

過去10年間、私はThoughtworksで働き、私たちのプロジェクトの共通のテーマは、アイデアから使用可能なソフトウェアまでのサイクルタイムを短縮することでした。多くのプロジェクト事例を見てきましたが、ほとんど全てがそのサイクルの短縮に重点を置いています。毎日本番環境にデリバリーすることは通常ありませんが、2週間ごとのリリースを行うチームが増えています。

DaveとJezは、その大きな変化に積極的に関わっており、頻繁で信頼性の高いデリバリーの文化を築いたプロジェクトに携わってきました。彼らと私たちの同僚は、年に一度しかソフトウェアをデプロイできなかった組織を、リリースが日常業務となる継続的デリバリーの世界へと導いてきました。

少なくとも開発チームにとって、このアプローチの基礎は継続的インテグレーション（CI）です。CIは開発チームを同期させ、統合の問題による遅延を解消します。数年前にPaul Duvallはこのシリーズの中でCIに関する書籍を執筆しました。しかし、CIは最初のステップに過ぎません。メインラインコードストリームに正常に統合されたソフトウェアは、本番環境で動作しているソフトウェアではありません。DaveとJezの書籍は、CIからその「最後の1マイル」に取り組み、統合されたコードを本番ソフトウェアに変換するデプロイパイプラインの構築方法を説明しています。

このようなデリバリーに関する考え方は、ソフトウェア開発において長い間忘れられた隅に追いやられており、開発チームと運用チームの間に溝が生じていました。そのため、本書の手法がこれらのチームを結びつけることに重点を置いていることは驚くべきことではありません。これは、生まれたばかりだが成長している「DevOps」ムーブメントの先駆けとなっています。このプロセスにはテスターも関与しており、テストはエラーのないリリースを保証する重要な要素です。全体を通して、高いレベルの自動化が行われているため、迅速かつエラーなく作業を行うことができます。

これら全てを機能させるには努力が必要ですが、そのメリットは計り知れません。長く、高強度のリリースは過去のものになります。ソフトウェアの顧客は、毎日使用できる動作するコードにアイデアが迅速に変換される様子を見ることができます。おそらく最も重要なのは、ソフトウェア開発における最大のストレス源の一つを取り除くことです。誰もが、月曜日の朝までにシステムアップグレードのリリースに苦労する緊張した週末を好むわけではありません。

頻繁に、そして通常のストレスなしにソフトウェアをデリバリーする方法を示すことができる本は、読むべきであることは明らかです。あなたのチームのためにも、あなたも同意してくれることを願っています。