「継続的デリバリー」から考えるソフトウェア開発の入り口、出口問題

「継続的デリバリー」(*1)の章の構成はとても興味深い。第一章では「The problem of deriverling software」というタイトルで、ソフトウェア開発の目的を顧客に価値をデリバリーする事とし、その上でリリースにまつわるアンチパターン３つの紹介から始まる。

* Deploying software manually

* Deploying to a Production-like Environment Only after Development Is Complete

* Manual Configuration Management of Production Environments

これは「継続的デリバリー」というタイトルから考えるに妥当に感じるかもしれないが、一度考えてみて欲しい。

何故リリースにまつわるアンチパターンの紹介から始まるのか？

それはソフトウェア開発に関する問題の多くが顧客に価値を届けるvalue streamの入り口と出口に潜んでいるから。

ここで素晴らしい事は入り口に関する問題の解決方法は多くの良書で語られている事。アジャイル関連の本には特に多い。残念な事は出口に関する問題の解決方法を語っている本は「継続的デリバリー」くらいしかない事。「継続的デリバリー」自身が第一章1pで語っている。

There are many software development methodologies, but they focus primarily on requirement management and its impact on the development effort. There are many excellent books that cover in detail different approaches to software design, development, and testing; but these, too, cover only a fragment of the value stream that delivers value to the people and organizations that sponsor our efforts.

「継続的デリバリー」が出版された頃と比較して、CIツールや自動テストツール等、デプロイメントパイプラインを構成する技術要素が進化、普及し簡単に継続的デリバリーを実現出来るようになった。AntやMavenでビルドを自動化する事、Seleniumを使って画面テストを自動化する事、Jenkinsを使ってそれらの自動実行をスケジューリングする事、ChefやFabricでprovisioningやdeployを自動化する事。どれも手軽に出来る。

その一方で、ウォーターフォールへのテーラリングやお手軽なテスト自動化などが進み、変な継続的デリバリーが増えてしまっているように思う。変な継続的デリバリーは出口の問題を解決しないので、開発もテストも運用もどんどん疲弊していく。単体テストでコードカバレッジ100%を目指す「自動化ハイ」なんかはその典型的な例だろう。

継続的デリバリーが手軽に実現出来るようになった今では、冒頭で紹介されているリリースにまつわるアンチパターンは、継続的デリバリー実現のアンチパターンと読み替えてもいいかもしれない。

プロビジョニングに関する環境の構成管理とデプロイ方法を自動化する事で、疑似本番環境へのデプロイを毎週、または毎日行っていますか？
毎週、または毎日デプロイを行う事で、デリバリーが成功すると自信を持って言えていますか？

「リリース」というソフトウェア開発プロジェクトの中で大きなリスクを伴うプロセスを擬似的にプロジェクトの初期から継続的に実施する。それによってそのリスクを大幅に減らす事が出来る。そういう世界だからこそ、開発者はその設計や実装のスキルを発揮出来るし、テスターや運用者は要求や設計に関わるフィードバックを回す事が出来る。「デプロイメントパイプライン」の中での品質の作り込みを実現していく事が可能になる。