システム運用アンチパターン ―エンジニアがDevOpsで解決する組織・自動化・コミュニケーション

8章業務時間外のデプロイ

本章の内容

• リリースサイクルの長期化と、それがデプロイの信頼性に与える影響
• デプロイの自動化技術
• デプロイアーティファクトの価値
• 未完成のコードをリリースするための機能フラグ

デプロイは時に大きくて怖いイベントです。そのためデプロイにまつわる儀式のようなものが正当化されていることもあります。しかしデプロイがおおごとになっているのは、デプロイ戦略に何か深刻な問題があることを示している場合が多いです。業務時間外のデプロイは、組織を守るためとして正当化されがちなアンチパターンです。このパターンを採用しても問題の根本解決にはならず、単なる対症療法にしかなりません。普段のデプロイのためにわざわざカレンダーの招待が送られてくるなら、それはデプロイが大きなイベントになっていることを示しています。しかし、もっと良い方法があります。

8.1　苦労話

パトリックは、ファンコ社でプロダクト組織を運営しています。ある日、営業部のジャヒームから彼に電話がかかってきました。ジャヒームは大手のクアンティシス社との商談を進めていました。彼はついにクアンティシス社の経営チームの前でソフトウェアのデモを行う機会を得て、彼らはこのソフトウェアを気に入ってくれました。

しかし夢のような話には裏がありました。このソフトウェアは、クアンティシス社の現在の課金システムと連携する必要があったのです。ジャヒームは、開発チームが取り組んでいる機能の中で課金システムとの連携が上位にあることを知っていました。彼はクアンティシス社が必要としている連携機能が優先されて迅速に実装できれば、契約を有利に進めることができるのではないかと期待していました。

ジャヒームの話を聞いて、パトリックもこれは非常に大きなチャンスだと同意しました。このような大口顧客を獲得するために、優先順位の変更は可能でした。しかし、そこには1つ問題がありました。たとえ2週間後に機能が完成したとしても、このプロダクトは四半期ごとのリリースサイクルで動いていたのです。今は2月で、次のリリースは4月中旬の予定です。パトリックは開発チームと協力して、この機能だけをターゲットにしたリリースができないかと考えました。しかし残念ながら、コードベースにはすでに多数のコミットがあり、安全性を確保しながらその機能だけをリリースすることは困難でした。 ...