webサイトやシステムの本番リリースで失敗しないための4つの手順について
ルート・シーでは、本番環境へのリリース手順を徹底して管理し、システムの安定運用を確保しています。高い技術力と運用管理能力があり、お客さまに安心してシステムを利用していただけるよう努めています。
本記事では、WordPressを例にしてルート・シーの本番リリース手順を詳しく紹介します。
リリース手順は、システムの種類や変更の内容に応じて異なりますが、主に以下の４つのパターンに分類されます。それぞれの手順は以下の通りです。
1. WordPressのバージョンアップ
セキュリティの向上や新機能の追加のために、WordPressのバージョンアップを定期的に行う必要があります。以下の手順で進めます。
1-1. 実装
- 新しいバージョンに含まれる変更点や新機能を確認し、必要に応じてカスタマイズや追加機能を実装します。
- プラグインの更新があれば、下記を実施します。
・現在のphpのバージョンで動くかどうかなどリストを作成して確認します。
・プラグインを使用しているページや機能の動作確認をします。
1-2. テストアップ
1-2-1. 社内テスト環境の反映
- ローカル環境での動作確認を行い、開発が完了したコードを社内のテスト環境にアップロードします。
1-2-2. ステージング環境の反映
- バックアップを取得してから、ステージング環境のWordPressを新しいバージョンへアップデートします。
- プラグインやテーマの互換性を確認し、必要に応じて修正します。
- 大きな改修がある場合、ステージング環境を使用して本番と同じ状況でリハーサルを行います。
1-3. 本番リリース
- リリース作業の前にタイムスケジュールの最終確認を行い、チェックリストを使って作業の抜け・漏れがないことを確認します。
- 各作業の際、社内の作業責任者やお客さまの担当者に開始連絡と終了連絡を行います。
- 問題が発生した場合は、すぐにお客さまへ報告し、必要であればお客さまの了承を得た上で戻し作業を行います。
1-3-1. 本番のデータベース（DB）とソースバックアップ
DB
- phpMyAdminがある場合は、phpMyAdminを利用してエクスポートします。
- phpMyAdminがない場合は、下記のいずれかを実施します。
・SSHのTUNNELでDB接続アプリ（A5-MK2、mysqlのWorkbench、pgadminなど）を利用してエクスポートします。
・TeratermでSSHに接続して、コマンドラインからエクスポートサーバー内にバックアップすると同時に、FTPを利用してサーバー内からローカルにも保存します。
（例：mysqldump -u [ユーザー名] -p[パスワード] [データベース名] > backup.sql）
ソース
- FTPを使用してバックアップします。
- バックアップはサーバー内のドキュメントルートに保存しないようにし、一定期間（1ヶ月後など）経過後に削除します。
- サーバーのディスク容量が少ない場合、ローカルのバックアップのみ実行します。
1-3-2. 反映
- WordPressの管理画面から更新する場合、ステージング環境のWordPressのバージョンアップをした後、本番環境の更新実施までの間にWordPressの新たなアップデートがあった場合は、再度ステージング環境のWordPressのバージョンアップと動作確認をした上で本番環境のアップデートを行う必要があります
- WordPressの管理画面を使用せずに、WordPressのソースコードを直接更新する場合、下記の内容を順番に実施します。
（1）FTPでサーバーに接続してサーバー内に「wordpress-new」フォルダーと「wordpress-old」フォルダーを作成します。
（2）新しいバージョンのWordPressのソースコード一式（wp-contentsフォルダーとwp-config.phpファイルは除く）を「wordpress-new」フォルダーへアップロードします。
（3）現在のWordPressのソースコード一式（wp-contentsフォルダーとwp-config.phpファイルは除く）を「wordpress-old」へ移動します。
（4）「wordpress-new」フォルダーの内容を元のWordPressフォルダーへ移動します。
（5）「wordpress-old」フォルダーを削除します。
1-3-3. 問題があれば戻し
- 問題が発生した場合、直ちにバックアップから復元します。
1-3-4. 動作確認
- サイト全体の動作確認をします。重要な機能については事前に取り決めたやり方（ダブルチェックをするなど）で問題がないか入念に確認します。
2. データベースとソースコードのリリース
データベース（DB）の変更を伴うリリースは、慎重に計画・実施する必要があります。
WordPressのバージョンアップ作業と基本的な流れは同じですが異なる点もあります。手順は以下のとおりです。
2-1. 実装
- 新しいバージョンに含まれる変更点や新機能を確認し、必要に応じてカスタマイズや追加機能を実装します。
- SmartyやPearなどのライブラリーの更新があれば、下記を実施します。
・現在のphpのバージョンで動くかどうかなどリストを作成して確認します。
・ライブラリーを使用しているページや機能の動作確認をします。
2-2. テストアップ
2-2-1. 社内テスト環境の反映
- ローカル環境での動作確認を行い、開発が完了したコードを社内のテスト環境にアップロードします。
2-2-2. ステージング環境の反映
- バックアップを取得してから、ステージング環境へ反映します。
- プラグインやテーマの互換性を確認し、必要に応じて修正します。
- 大きな改修がある場合、ステージング環境を使用して本番と同じ状況でリハーサルを行います。
2-3. 本番リリース
- リリース作業の前にタイムスケジュールの最終確認を行い、チェックリストを使って作業の抜け・漏れがないことを確認します。
- 各作業の際、社内の作業責任者やお客さまの担当者に開始連絡と終了連絡を行います。
- 問題が発生した場合は、すぐにお客さまへ報告し、必要であればお客さまの了承を得た上で戻し作業を行います。
- 大きな改修の反映や、反映後の設定に時間がかかる場合、メンテナンス実施中の専用画面を表示します。
2-3-1. 本番のDBとソースバックアップ
DB
- phpMyAdminがある場合は、phpMyAdminを利用してエクスポートします。
- phpMyAdminがない場合は、下記のいずれかを実施します。
・SSHのTUNNELでDB接続アプリ（A5-MK2、mysqlのWorkbench、pgadminなど）を利用してエクスポートします。
・TeratermでSSHに接続して、コマンドラインからエクスポートサーバー内にバックアップすると同時に、FTPを利用してサーバー内からローカルにも保存します。
（例：mysqldump -u [ユーザー名] -p[パスワード] [データベース名] > backup.sql）
ソース
- FTPを使用してバックアップします。
- バックアップはサーバー内のドキュメントルートに保存しないようにし、一定期間（1ヶ月後など）経過後に削除します。
- サーバーのディスク容量が少ない場合、ローカルのバックアップのみ実行します。
- 設定ファイルの更新がある場合、本番環境とテスト環境では設定が異なるため、テスト環境の設定ファイルは使わずに本番環境の設定ファイルを差分更新します。GITなどのリポジトリツールで管理する場合、本番環境とテスト環境の設定ファイルは別で管理します。お客さまや別の開発ベンダーが本番の設定ファイルを直に更新している可能性を考慮し、必ず差分チェックを行った上で更新します。
2-3-2. 反映
- FTPを利用してファイルをアップロードします。
- ソース反映後管理画面の設定が必要であれば、更新を行います。
2-3-3. 問題があれば戻し
- 問題が発生した場合、直ちにバックアップから復元します。
2-3-4. 動作確認
- サイト全体の動作確認をします。重要な機能については事前に取り決めたやり方（ダブルチェックをするなど）で問題がないか入念に確認します。
（例：サイト全体のナビゲーション、フォーム送信、プラグインの動作をチェック） - メンテナンス時の専用画面がある場合、リリース作業の最後に必ず専用画面の表示の解除を行い、メンテナンス画面が表示されないことを確認します。
3. .htaccessファイルの更新
.htaccessファイルは、サイトの設定変更やリダイレクトの追加などに用いられます。以下の手順で進めます。
3-1. 実装
- 必要な設定をして、ローカル環境で正しく動作するかを確認します。
3-2. テストアップ
.htaccessファイルは、apacheのバージョンで設定の仕方が異なるものがあります。
（例：「Deny from all」と「Require all denied」の違いなど）
設定ファイルを何度も書き換えて確認していると、キャッシュの影響により設定した内容が反映されているか判断できなくなることがあります。この場合、.htaccessファイルをリネームしたり、エラーが発生する設定を意図的に混入させたりすることで、設定の有効性を確認できます。
3-2-1. 社内テスト環境の反映
- ローカル環境での動作確認を行い、変更が完了したコードを社内のテスト環境にアップロードします。
3-2-2. ステージング環境の反映
- ステージング環境に変更を反映し、動作確認を行います。
3-3. 本番リリース
- リリース作業の前にタイムスケジュールの最終確認を行い、チェックリストを使って作業の抜け・漏れがないことを確認します。
- 各作業の際、社内の作業責任者やお客さまの担当者に開始連絡と終了連絡を行います。
- 問題が発生した場合は、すぐにお客さまへ報告し、必要であればお客さまの了承を得た上で戻し作業を行います。
3-3-1. 本番のバックアップ
- ソース
・FTPを使用してバックアップします。
・バックアップはサーバー内のドキュメントルートに保存しないようにし、一定期間（1ヶ月後など）経過後に削除します。
・本番用の設定があるので、本番のバックアップと確認して差分を確認します。差がある場合はマージして反映します。
3-3-2. 反映
- ステージング環境と同じ構成のサーバーである場合、ステージング環境と同じく、htaccessファイルの更新を実施します。
- ステージング環境と同じ構成のサーバーでない場合、サーバー内に仮フォルダーを作成して、そのフォルダーへ.htaccessファイルをアップロードし、動作確認をします。動作確認をして問題がない場合、対象の.htaccessファイルを更新して、仮フォルダーを削除します。
3-3-3. 問題があれば戻し
- .htaccessファイルの更新後にエラーが発生するなど何かしらの問題が発生した場合は、バックアップから元の状態に復元します。
3-3-4. 動作確認
- リダイレクトルールに関する確認、IPアドレスの制限に関する確認、BASIC認証の確認など、サイト全体の動作確認を行います。
4. サーバーのミドルウェア更新
サーバーのミドルウェア（Apache、PHP、MySQLなど）の更新は、システムの安定性やセキュリティを維持するために重要です。以下の手順で進めます。
4-1. 実装
- 本番環境がVPSサーバーの場合、ローカル環境で下記のようにvirtualhostを構築して確認します。
- 本番環境と同じシステム構成をvirtualhost環境に構築します。その上でvirtualhost環境のバックアップを取得します。
- ミドルウェアを更新します。
- 更新が必要なミドルウェアのバージョンを確認し、更新手順を準備します。
- バックアップのvirtualhost環境を使用して、更新手順を2回以上実施し、問題ないことを確認します。
- 元に戻す手順も確認します。
- バージョンアップに関するシステム改修の内容を確認します。
4-2. テストアップ
4-2-1. 社内テスト環境の反映
- テスト環境でミドルウェアの更新を実施し、動作確認を行います。
4-2-2. ステージング環境の反映
- ステージング環境でミドルウェアの更新を実施し、本番環境と同じ条件でテストを行います。
4-3. 本番リリース
- リリース作業の前にタイムスケジュールの最終確認を行い、チェックリストを使って作業の抜け・漏れがないことを確認します。
- 各作業の際、社内の作業責任者やお客さまの担当者に開始連絡と終了連絡を行います。
- 問題が発生した場合は、すぐにお客さまへ報告し、必要であればお客さまの了承を得た上で戻し作業を行います。
- 大きな改修の反映や、反映後の設定に時間がかかる場合、メンテナンス実施中の専用画面を表示します。
4-3-1. 本番のDBとソースバックアップ
クラウド環境の場合、サーバーを構築しているインスタンスのバックアップを取得します。
（例：AWSの場合、EC2インスタンスのスナップショットを取得）
DB
- phpMyAdminがある場合は、phpMyAdminを利用してエクスポートします。
- phpMyAdminがない場合は、下記のいずれかを実施します。
・SSHのTUNNELでDB接続アプリ（A5-MK2、mysqlのWorkbench、pgadminなど）を利用してエクスポートします。
・TeratermでSSHに接続して、コマンドラインからエクスポートサーバー内にバックアップすると同時に、FTPを利用してサーバー内からローカルにも保存します。
（例：mysqldump -u [ユーザー名] -p[パスワード] [データベース名] > backup.sql）
ソース
- FTPを使用してバックアップします。
- バックアップはサーバー内のドキュメントルートに保存しないようにし、一定期間（1ヶ月後など）経過後に削除します。
- サーバーのディスク容量が少ない場合、ローカルのバックアップのみ実行します。
- 設定ファイルの更新がある場合、本番環境とテスト環境では設定が異なるため、テスト環境の設定ファイルは使わずに本番環境の設定ファイルを差分更新します。GITなどのリポジトリツールで管理する場合、本番環境とテスト環境の設定ファイルは別で管理します。お客さまや別の開発ベンダーが本番の設定ファイルを直に更新している可能性を考慮し、必ず差分チェックを行った上で更新します。
4-3-2. 反映
- レンタルサーバーであれば、コントロールパネルでバージョン設定して、htaccessファイルを更新します。
- VPSサーバーの場合、TeratermでSSHに接続して本番環境でミドルウェアの更新を実施します。
4-3-3. 問題があれば戻し
- 問題が発生した場合、直ちにバックアップから復元します。
4-3-4. 動作確認
- アプリケーション全体の動作を確認し、新しいバージョンのミドルウェアが正しく動作しているかをチェックします。
- メンテナンス時の専用画面がある場合、リリース作業の最後に必ず専用画面の表示の解除を行い、メンテナンス画面が表示されないことを確認します。
5. まとめ
ルート・シーでは、上記のリリース手順を徹底的に管理することで、システムの安定運用を確保し、お客さまに高品質なサービスを提供しています。リリースの各ステップで厳格なテストと確認を行うことで、予期せぬ障害を未然に防ぎ、迅速かつ安全なデプロイを実現しています。また、リリース後の監視体制を整え、万が一問題が発生した場合には迅速に対応できるよう備えています。
WordPressのバージョンアップ、データベースの変更、.htaccessファイルの更新、サーバーのミドルウェアの更新など、各種リリースに対する万全の準備と実行により、お客さまのビジネスの成長と成功を支えるシステム運用を実現します。常に最新の技術とベストプラクティスを取り入れ、安心してご利用いただけるシステム環境を提供することをお約束いたします。
ルート・シーは今後も継続的にリリース手順の見直しと改善を行い、より効率的で信頼性の高いシステム運用を目指します。お客さまに安心してご利用いただけるシステム環境を提供するために、最善を尽くしてまいります。