今年4月のRubyConf 2013にて、CircleCIの共同創業者であるPaul Biggar氏が "The Many Ways to Deploy Continuously" というプレゼンをした。デプロイメントの頻度は "Continuous" と言うにふさわしい資格を与えるとともに、デプロイメントの問題に直接的な影響を及ぼしている。このプレゼンはCircleCI自身の顧客、Facebook、 IMVU、Etsy、Heroku、Googleから集めたソリューションに関する情報をまとめたものだ。彼らは、いずれの会社も若干異なるデプロイメントを実施していること、継続的にデプロイするためのソリューションは1つではないことを明らかにした。
Paul氏は、いかにデプロイメントソリューションがいかに、コード、データベース変更、デプロイメント単位、デプロイメントのスピード、テスト、モニタリングを伴うプロセスになるか、詳しく説明した。そして、こうしたデプロイメントソリューションの開発に影響を及ぼす変数には、新機能のスピード、コードの複雑さ、ソフトウェアアーキテクチャ、ソフトウェアデザイン、エンジニアの数、モニタリング状態といったものが含まれると語った。
Paul氏は、プロダクションへのデプロイメント中の遷移状態を管理するのによく見られるソリューション、"Race"は新旧機能をサポートしたコードをデプロイメントすることであると説明した。これには機能をプログラムするエンジニアを必要とするが、この結果、新しいコードを古いコードと並行して安全に実行することができる。データベースには格納された状態という課題もある。データベースのバージョンを最終的に変更する前に、まずアプリのその他のところを更新し、両方のバージョンのデータベースを扱えるようにすると十分であるように見えるだろう。ところが、SQLデータベースの変更が大量のロックを引き起こすため、バージョン毎に新しいデータベーステーブルを作ってデータを移行するしか、リーズナブルな選択肢がない場合もある。アプリケーションはまず新しいテーブルをチェックし、もしデータがなければ古いテーブルにフォールバックするよう実装することになるだろう。ロッキングシナリオを回避できるという理由で、NoSQLも人気になっている。
このプレゼンでは、デプロイメント単位、スピード、テストによる検証、モニタリングによる確認といった側面についても説明している。これらはデプロイメントの非機能要件だが、そのレベルがデプロイメントの継続性度合いを決定付けている。