DevOpsの次フェーズ

ある記事がDevOpsムーブメントをまとめ、そこには2つのフェーズがあると述べた。第1フェーズは、従来のサイロ化したエンジニアリングチーム（開発、QA、運用）間のコラボレーション向上に注目したものだ。これに対し、第2フェーズは現在登場してきたもので、第1フェーズを確立したものとして、エンジニアリングチームと非エンジニアリングチーム（セールスやマーケティングなど）との間のコラボレーション改善を狙ったものだ。

DevOpsを単なる流行以上のものだと認めた2011年のレポートによると、その公式な起源は2008年までさかのぼる。1.0ムーブメントと呼ばれているものは、コラボレーションと信頼の向上とそれを手助けするプラクティスの導入にフォーカスし、継続的ソフトウェアデリバリーのモデルを合理化しようとしてきた。今あるプラクティスとツールは、そのムーブメントの成熟度を反映している。

昨年のState of DevOps Reportでは、プロダクションへの高速で頻繁なデプロイメント、失敗の見える化、高速な復旧などを、現状のキーポイントとして挙げている。

DevOpsの次フェーズは、エンジニア部門とセールスのような非エンジニア部門との間の密接な連携によってもたらされる。顧客とマーケットは常に変化し続ける。エンジニアリングチームは、セールスおよびマーケティングキャンペーンと連動してフィーチャーをデプロイ可能にすることで、この継続的変化に対応する必要がある。

第1フェーズと同様に、これを手助けするプラクティスとツールの組み合わせが登場している。ChatOps、フィーチャー/タスク管理ツール、ダッシュボードなどだ。焦点は、システムの安定性を妥協することなく高速であることにある。

こうした要求についていくための重要な仕組みのひとつがフィーチャーフラグだと見なされている。従来のソフトウェアリリースは、プロダクションへのコードプッシュとエンドユーザが利用できるフィーチャーとの間に、1対1の関係がある。フィーチャーフラグは、フラグをセットしない限り特定のフィーチャーを無効にする機能を追加することで、この関係を分離する。フラグの設定は実行時に行える。

フィーチャーのロールアウトとコードのデプロイメントを分離することには、メリットがある。

• あるフィーチャーが未完成でも、コードをまとめてリリースできる。そのフィーチャーは単にオフにしておけばよい。
• A/Bテストやベータテスト
• エンドユーザーをグループにまとめることができる。例えば、パワーユーザーと通常のユーザー、有料ユーザーと無料ユーザー、など。

フィーチャーフラグには、エンジニアリングチームとソフトウェアの綿密な設計に規律を必要とする。FacebookやEtsyなど、大規模なデプロイメントを行っている多くの組織がフィーチャーフラグを活用している。