確認した変更を本番へ届ける

テストに合格した変更も、利用者が使うサーバーへ置くまではサービスに反映されません。 アプリや設定を、利用者が使える環境へ配置して動かす作業をデプロイと呼びます。

デプロイを毎回手作業で行うと、ファイルの選び間違いや手順の抜けが起きます。 CIが作った成果物を、決められた順番で試験用の環境と本番環境へ進めます。

テストした成果物をそのまま使う

試験用の環境と本番環境で別々に成果物を作ると、本番で動かすものがテスト済みの内容と変わる場合があります。 Gitへ記録した一つの変更から成果物を一度だけ作り、同じ成果物を各環境へ配置します。

データベースの接続先など、環境ごとに変わる値は成果物へ埋め込まず、起動時の設定として渡します。

本番へ出す判断をどこに置くか

継続的デリバリー（Continuous Delivery）は、テストを通った成果物を、いつでも本番へ出せる状態に保つ方法です。 担当者が結果を確認し、本番へ出す操作を行います。

継続的デプロイ（Continuous Deployment）は、すべての確認に合格した成果物を自動で本番まで届ける方法です。 サービスを止めたときの影響や、問題発生時に対応できる時間を考えて、自動化する範囲を決めます。

どちらもCDと略されるため、「本番へ出す判断を人が行うか、自動で進めるか」まで確認します。

公開後に利用者と同じ入口から確認する

デプロイ後は、プロセスが起動したことに加えて、利用者がWebサイトを正常に使えることを確認します。

• Webサイトへ接続できるか
• 新しい画面や処理が期待どおり動くか
• エラーの割合や応答時間が悪化していないか
• 古い版のプロセスが残っていないか

監視する値と確認時間をデプロイ前に決めておくと、公開を続けるか戻すか判断できます。

前の版へ戻す準備

新しい版で問題が起きたとき、前の成果物をもう一度配置する操作をロールバックと呼びます。 前の成果物、使っていた設定、戻す手順を残します。

データベースの列を削除したあとでは、アプリだけを前の版へ戻しても動かない場合があります。 データベースを変更するときは、変更前と変更後のアプリが一時的に同じデータを使える順番を決めます。