継続的デプロイ
文責：丸山直樹
デプロイとは？
システムは作ったら終わりではなく、ユーザーが利用できる状態になる必要があります。
この「利用できる状態」にする事をデプロイと呼びます。
システムの作りによって違いますが、サーバーの設定を行ったり、作ったシステムを配置したり、必要なソフトウェアをインストールする、設定を切り替えるなど、デプロイには様々な工程があります。
継続的デプロイがなぜ重要か？
完成したソースコードを自動的かつ簡単・安全にサービスインするための仕組みです。
この環境が整っていない場合、リリースのたびにシステムが停止してユーザーが利用できなかったり、デプロイには様々な工程があるため非常に時間がかかります。
よって、仮説検証や品質改善が効率的に行えない、リスク発生時にすぐに切り戻せないなど様々な弊害をもたらします。
デプロイ工程の自動化
まず、工程を自動化することがスタートです。
バージョン管理システムのイベントをトリガーとして、継続的インテグレーションと共に自動デプロイさせるのが一般的になっています。
デプロイのような複雑でリスクのある工程は、自動化の中でもとても優先度が高いものです。
デプロイの度に手順が変わるような設計では、自動化することができないため、まずデプロイに一貫性のある作りにしていく必要があります。
安全なデプロイ
デプロイを自動化することができれば、デプロイ頻度をあげることができますが、
安全でないリリースが増え、事故が発生する度に人の手がはいっていては、自動化の意味がなくなってしまいます。
安全にデプロイ頻度をあげられるような状態を目指します。
- 特定の利用者のみに公開、または一部のサーバーのみに公開して少数のユーザーのみ利用できる状態でデプロイし、問題がないことを確認してから全体公開する
- カナリアリリースと呼ばれる手法
- リスク発生時にすぐに前のバージョンに戻せる
- 切り戻す判断基準を用意し、意思決定後は即座に治すための仕組み作り
- スモークテストなどでインフラ環境のテストを実施する
- 基本的な機能が動作するかなどを自動的に実行する
ダウンタイムを短くする
デプロイ頻度があがり、デプロイのたびにシステムが止まってしまっていては、ユーザーの体験を損なってしまいます。
そこで、稼働中のサーバーへデプロイするのではなく、別の環境へデプロイを行い、そちらの環境にロードバランサーの接続先を切り替えるなどでリリースする方法です。
この方法であれば一瞬で切り替わるので、ユーザーはデプロイを意識することなくシステムを使い続けることができます。
また、障害発生時にも元のサーバーに切り替えれば良いため、その点もメリットがあります。
この手法は”ブルーグリーンデプロイメント”と呼ばれます。
継続的に改善していくために
計測
まずは、デプロイの頻度とデプロイの成功率を測定しましょう。
デプロイが成功し、それによってユーザーが新しい機能を利用できるようになることが、直接的な価値提供に直結するため、これらの指標は非常に重要です。
継続的にこれらの値を測定し、改善していくことによって、価値提供・仮説検証のサイクルを高速化できます。
他チームとの連携
デプロイ頻度・成功率が上がってくると、開発者に閉じたデプロイ工程の話だけではなく、新機能のアナウンスであったり、サポートチームのマニュアル作成など、関連するチームへの影響が大きくなってきます。
結果、デプロイが早くなっても周りが追いつかずに公開できないなどのような課題が発生します。
あらかじめ何がいつリリースされるのか自動的に広報する仕組みなど、関係各所とのコラボレーションが重要になっていきます。
改善例
- 疎結合アーキテクチャを取り入れることで、デプロイの範囲を縮小する
- フィーチャーチームより適切な権限委譲を行い、開発者自身でリリースできるようにする
デプロイが不要な仕組みの選択肢
デプロイにはある程度リスクが存在するため、そもそもデプロイしない選択肢も用意することも重要です。
例えば、環境変数やデータベースなどを利用して、デプロイせずとも機能をオンオフできるような仕組みを入れるなどの手法もあります。