Kinstaのステージング環境は、WordPress開発ワークフローとDevOpsライフサイクル両方をカバーする便利な存在です。Kinstaのステージング環境を使って、最初の計画から運用フェーズまでのワークフローを効率化することができます。これには、WordPressのローカルでの作業、バージョン管理の活用、そしてサイクル内で行う他のあらゆるタスクが含まれます。
この記事では、Kinstaのステージング環境を活用してサイトを開発することのメリットや流れについてご紹介します。この概念をあらゆるDevOpsライフサイクルに統合することができるはずです。Kinstaのステージング環境の基本から始めましょう。
Kinstaのステージング環境を使用するメリット
Kinstaのステージング環境は、ウェブサイトを開発しテストする際に便利な機能です。本番環境を反映した設定を自由につくりあげることができます。本番サーバーもKinsta上に位置するため、高い信頼性を確保しながら慎重にテストを行うことが可能です。
MyKinstaからステージング環境を作成、管理、複製、削除することができます。
特別な柔軟性が必要な場合は、プレミアムステージング環境アドオンでさらに5つの環境を追加できます。GoogleのプレミアムティアネットワークやCloudflare統合といった堅牢なインフラストラクチャが利用できる点も特筆に値します。
さらなるパワーアップも可能です。プランによっては、最大12 CPUと8GBのメモリ、本番サイトと同じワーカープロセス数、Kinsta CDNを有効にしてパフォーマンスを引き上げることができます。これは、A/Bテスト、プラグインの互換性チェック、リソース集約型のテストなど、さまざまなタスクに便利なセットアップです。
ローカル開発では、DevKinstaがユーザー体験全体を補完します。準備が出来次第簡単にサイトをKinstaのステージング環境に直接プッシュすることができます。
全体として、作成、構築、デザイン、テスト、デバッグのすべてをKinstaのエコシステム内で実行できます。さらに、DevOpsライフサイクルとも調和します。これについては後ほど詳しくご説明します。先にKinstaのステージング環境についての補足をご紹介します。
Kinstaのステージング環境に関する補足事項
Kinstaのステージング環境は、本番ではないもののサーバー上でサイトをテストする場合に効果的です。とはいえ、Kinstaのステージング環境と本番環境の間にはいくつかの違いがありますのでご注意ください。
- まず、デフォルトではフルページキャッシュとOPcacheの両方を無効にしています。お望みであれば、これを有効にすることもできますが、無効状態ではページの読み込み時間が長くなる可能性があります。
- 同じように、WordPressではサイトのインデックスも無効になっています。必要であれば有効にできますが、一時的なURLインデックスの制限ヘッダーをオフにすることはできません。
- cronジョブはステージング環境では実行されませんが、設定そのものは存続します。つまり、変更を加えることができ、これを本番環境に移行した後に本番環境のcronジョブに置き換わります。しかし、ステージング環境では実行されません。
- また、WordPressのログイン情報はステージングサイトでも本番サイトと同じものになります。
ワークフローに移る前に、もう一つご説明したいことがあります。
Kinstaのステージング環境でのプラグインの使用
Kinstaは、セキュリティとパフォーマンスの理由から、WordPressへの特定のプラグインのインストールを制限しています。しかし、これとは別にステージング環境に関しては、サイトのプラグインの一部を無効にすることが必要になる可能性があります。
これを考慮したい状況が3つあります。
- プラグインのライセンスがドメイン名にリンクされている場合、ステージング環境では動作しない可能性があります。
- Jetpackなどのプラグインは自動的にステージングモードに切り替わります。処理したデータはWordPress.comに送られませんが、実際の違いは特にわからないかもしれません。また、ステージング環境ではJetpackを無効にすることはできません。
- CoScheduleのようにSNSに接続して投稿するプラグインもあります。このようなプラグインをご利用中であれば、本番での稼動までオフにすることをお勧めします。これは、ステージング環境のURLに基づいて投稿の作成や投稿ができてしまうためです。
これに関する詳しい情報はドキュメントをご覧ください。Kinstaのステージング環境を使用しながら、プラグインやテーマに関連する影響を最小限に抑えるために大事な情報をご紹介しています。
Kinstaのステージング環境を使用した典型的な開発ワークフロー
おそらく独自の開発ワークフローはすでにお持ちだと思いますが、Kinstaのステージング環境を使用すると、継続的インテグレーション/継続的デプロイメント（CI/CD）を考えDevOpsライフサイクルをシームレスに統合できます。
このプロセスは開発用のローカル環境から始まります。素早くセットアップが完了し、これを経てMariaDBデータベースの構築も行うことができます。
ヘッドレスWordPressプロジェクトにはDevKinstaも有用です。そのような例ではWordPressは実質コンテンツアプリケーションプログラミングインターフェース（API）として機能し、ReactやVue.jsのようなJavaScriptフレームワークを使用してフロントエンドを構築することができます。
DevKinstaからは典型的な流れでステージング環境へのプッシュを行うことができます。フロントエンドについては、Kinstaの静的サイトホスティングまたはアプリケーションホスティングにデプロイ可能です。
典型的なワークフローの続きは以下のようになります。
- ステージング環境へのプッシュ：ローカルでの開発と予備テストが完了したら、ステージング環境にプッシュします。このテストを経て、本番サイトと同様の結果をもたらすことを確認できます。デプロイする前に自動でテストと品質チェックを実施できるので、CI/CDパイプラインにおける重要なステップになります。
- テストとデバッグ：パフォーマンステスト、セキュリティスキャン、ユーザー受け入れテスト（UAT）など、ステージング内でより多くのテストを実施することもできます。Kinstaではステージング環境と本番環境が分離されるため、このテストが本番サイトに影響を与えることはありません。Kinstaのロギングとアプリケーションパフォーマンス監視（APM）を使用して問題をデバッグすることもできます。
- 継続的インテグレーションとデプロイメント：テストフェーズと最終的な承認の後、ステージングの内容を本番環境に統合します。CD/CIワークフローに従って、このプロセスを自動化することができます。中央のバージョン管理は常に最新の状態に保ちながら、最小限の入力でコードを本番環境にデプロイできます。
- モニタリングとフィードバック：デプロイ後は、継続的なフィードバックとモニタリングループを使用して、問題を特定して修正することが重要です。KinstaのAPMは、デプロイ後の課題に対処するのに有用です。ここから、得られた洞察とデータを使って継続的な改善を行うことができます。
全体として、Kinstaのステージング環境（およびDevKinsta）は、開発ワークフローを合理化するのに役立つ堅牢なインフラストラクチャとなり、ヘッドレスWordPressアプリケーションもサポートしています。次のセクションでは、既存のDevOpsスキルをKinstaのステージング環境と組み合わせて使用する方法をご紹介します。
Kinstaのステージング環境とDevOpsテクニックの調和
Kinstaのステージング環境でDevOpsのさまざまなテクニックを使うことで、コラボレーションの幅が広がり、開発ライフサイクルの合理化も捗ります。ステージング環境が本番環境を可能な限り忠実に再現するため、部門横断的なチームにとって特に効果的です。
これにより、開発者、品質保証（QA）チームなどが、ビルド、テスト、デプロイメントの各フェーズで同期して共同作業を行うことができます。管理と隔離に基づいた環境が確保され、コンフリクトは最小限に抑えられます。また、開発プロセスの早い段階で問題を特定し、対処することも可能です。
DevOpsの核心は、伝統的な「サイロ化された」チーム、開発、運用の間の障壁を取り除くことです。そのため、現場で実践するプラクティスは、協調、自動化、統合を奨励するものになります。
さらに、DevOpsを正しくとらえることで、開発とデプロイのスピード、効率性、セキュリティの向上も目指すことができます。
DevOpsライフサイクルの各ステージを通して、この性質を実際に確認することができます。プロジェクトやチームにもよるものの、およそ5～7の段階があります。
- 開発：このステージでは、ステージング環境の選択とともに、プランニングとコーディングが行われます。次のステージに移る前に、ここでコードを書き、テストし、バージョン管理を行います（おそらくGitを使うことになるでしょう）。
- 統合：コードの変更点を中央のリポジトリにマージし、新しく追加されたものがサイトを壊さないように調整します。
- テスト：次に、ステージング環境のテストを自動化を用いて行います。これにより、バグのない質の高いコードを保証する2つ目の層ができます。
- デプロイメント：ステージング環境のコードを検証したら、本番環境へのデプロイを自動化により実行します。これにより、サイトは常に最新のバージョンで維持されます。
- モニタリング：デプロイ後はサイトのパフォーマンスを監視します。このステージで堅牢なアラートシステムとプロセスが価値を発揮します。ここで収集したデータは、今後の分析にも役立ちます。
- フィードバック：ユーザー（この場合はサイト訪問者）から洞察とデータを収集する、導入後の段階です。この段階でのフィードバックから、次の開発サイクルにおける改善点を特定します。
- オペレーション：このフェーズは新たなサイクルと重なる可能性があります。ダウンを最小限に抑え、稼働時間を改善し、サーバーの構成を最適化するといった作業を行います。
ライフサイクルのステップ数によっては、順序が異なるものもあります。例えば、統合が開発やテストの一部になるかもしれません。さらに、フィードバックやオペレーションなどは、特定のステージとして設けられないこともあり得ます。
Kinstaのステージング環境は、コーディング、テスト、およびデプロイ前のQAに便利な安全かつ隔離された環境となるため、開発フェーズで強さを発揮します。この環境をDevOpsライフサイクルに統合することで、コラボレーションを促進、納期を短縮し、成果物の質を高めることができます。
次に、MyKinstaからステージング環境を作成する方法をご紹介します。
Kinstaでステージング環境を作成する方法
すべての会社のサーバーに付帯するわけではありませんが、Kinstaではステージング環境をプランの大小に関係なく提供しています。数クリックするだけでセットアップが完了します。
詳しい解説は知識ベースでご確認いただけます。ここでは基本にとどめますが、まずはMyKinstaからプロセスを開始します。
最初に、標準ステージング環境かプレミアムステージング環境のどちらかを選択します。ポイントとして、ステージング環境が本番サイトにとってどの程度重要であるか考えることをおすすめします。例えば、本番環境から離れて要素をテストするには、標準環境で十分でしょう。
対照的に、本番サイトと同じレベルと範囲のリソースが必要な場合には、プレミアム環境が必要になります。複数のステージング環境をセットアップできるなど、他にも利点はあります。ただし、リソースを大量に消費するサイト（ECストアなど）では、本番サイトのリソースに合わせる必要があります。
ほとんどの場合、ステージング環境のタイプを選択した後、既存のサイトのクローンを作成することになります。
DevKinstaで作業をしていた場合には、ここで空の環境を選択することになるかもしれません。DevKinstaのサイト設定の中に、ステージング環境への反映ボタンがあります。好みの設定を選択し、環境のセットアップが完了するまで数分待ちます。その後、Kinstaステージング環境を使用してサイトの構築とテストを開始できます。
Kinstaステージング環境にサブドメインアドレスを設定する
一般的には、Kinstaステージング環境はサーバーのサブフォルダに位置します。kinsta.cloudのサブドメインURLが割り当てられますが、これはいくつかの問題を引き起こす可能性があります。
- 特定のドメイン名でライセンスを確認する必要があるプラグインなど、一部のプラグインが動作しなくなります。
- WordPressマルチサイトの特定の構成では、Kinstaのサブディレクトリで問題が発生したり、最適な方法で実行するために独自のサブドメインが必要になったりする可能性があります。
そのため、Kinstaステージング環境に別途サブドメインアドレスを設定することをお勧めします。プレミアムユーザー向けにKinstaは専用のサブドメインアドレスを提供していますが、これでも問題が解決しない場合があります。
これを解決するには、サイトに独自ドメインを設定し、ドメインネームシステム（DNS）を使用してサブドメインからステージング環境を実行することができます。目的に応じたドメインとサブドメインを使用したステージングURLには2つの利点があります。一つ目として、先に触れた問題を軽減することができます。二つ目に、共同作業者やクライアントと共有する際に「より整った」サブドメインを持てます。
本番サイトをステージングにプッシュする
ステージング環境の1つの大事なステップとして、セットアップ後に本番サイトをステージング環境にプッシュすることができます。ステージング環境は単に本番サイトのコピーであることを理解すれば、イメージしやすくなります。
理解を深めるためにワークフローの概要を簡単にご説明します。
- ステージング環境を作成すると、基本的に本番サイトがサブドメインにコピーされます。これにはすべてのデータベースとファイルが含まれます。本番サイトのレプリカです。
- DevOpsライフサイクルに従ってステージング環境に変更を加えます。その内容は実際のプロジェクト、ワークフロー、目標に依存します。
- その変更内容を本番環境にプッシュする際には、いくつかの選択肢があります。Kinstaに組み込まれた本番環境への反映機能を使うか、手動で変更を加えるかです。これについては後で詳しくご説明します。
- これを経て、ステージング環境と本番環境の両方でサイトの1対1のレプリカを再び持つことになります。
そのため、本番サイトのステータスに基づいてステージング環境を更新する手段はありません。ステージング環境を削除し、次に必要なときに再構築することをお勧めします。これが、Kinstaステージング環境に独自サブドメインアドレスを使用することをおすすめするもう一つの理由です。
Kinstaでは本番サイトとステージング環境の両方のバックアップを作成します。つまり、本番サイトのバックアップをステージング環境に直接復元することができます。これにより、ライフサイクルのフェーズ間の移行がより簡単になります。
最初にステージング環境をセットアップする必要がありますが、標準またはプレミアム環境どちらにでも復元することができます。いずれにしても、MyKinstaから全ての操作が行えます。
ボタンを数回クリックするだけで完了し、本番サイトとステージングサイトの既存のバックアップと設定したカスタムドメインの両方が保持されます。
バージョン管理をステージングセットアップに組み込む
多くの開発者がGitのようなバージョンコントロールを使用しています。Kinstaの本番環境とステージング環境の両方がGitとの統合に対応し、ステージングサイトでバージョン管理を行い開発スケジュールを維持することができます。
Kinstaサーバーに簡単にリポジトリをプル・複製可能です。基本的なステップは以下の通りです。
- SSH接続を使用してサイトに接続する
- GitHub、GitLabなどのサービスから既存のリポジトリをプルする
- あるいはリモートロケーションからリポジトリを複製する
リモートのリポジトリをどのようにプルするかは、それがパブリックかプライベートか、二要素認証（2FA）があるかどうかによって異なります。リモートリポジトリにコードをプッシュする場合は、その要件にあったワークフローを確保する必要があります。
Kinstaのステージング環境とGitの統合において、現段階では「git push kinsta mysite」のようなコマンドはサポートされていません。とはいえ、解決策はあります。例えばWP Pusherのようなツールを使うことができます。
開発者の面々により、KinstaからGitHubにプッシュする方法がいくつも考案されています。Gitクライアントからのシンプルなコマンドの実行やスクリプトを用いたプロセスの自動化などです。コードを本番サイトにプッシュする一般的な概念については、また後ほど詳しくご説明します。
Kinstaのステージング環境でのパフォーマンステストの実施
テストとモニタリングのライフサイクルフェーズの一部に、ベンチマークによるステージングサイトのパフォーマンス比較が挙げられます。本番サイトと同様にステージングサイトでもKinstaのすべてのツールを利用可能です。
つまり、本番サイトのベンチマークを取得し、到達したいターゲットを作成し、ステージングサイト内でコードを最適化できます。そこから、その変更がプラスに働くかどうかを評価します。うまくいけば、変更内容をそのまま反映し、そうでない場合はコーディングとテストのステップを繰り返します。
Kinstaのステージング環境のテストでは、Kinsta APMが中心的な役割を果たすでしょう。
これはWordPressの問題に焦点を当てたツールで、収集したすべてのアクティビティがタイムスタンプ付きで表示されます。PHPプロセス、HTTPコール、データベースクエリなどを監視できます。例えば、パフォーマンス低下の問題の大半は、最適化されていないプラグインやテーマに起因していることがわかります。Kinsta APMの「WordPress」タブからこのような情報を確認することができます。
個々のトランザクションを深く調べ、ボトルネックがどこにあるかを正確に把握可能です。ステージングサイトでは、Redisのトランザクション時間を監視することはあまりないでしょう。その代わりにPHPとMySQLの時間が重要になります。
トラブルシューティングの際に絶対的なタイムフレームを使用すると、懸念のある領域をピンポイントで特定することができます。Kinstaのドキュメントで一般的なワークフローを説明していますが、一言で言えば、読み込みの遅いページにまず狙いを定めるべきです。
そこから、トランザクションを構成するプロセスを掘り下げ、最適でないコードまたは劣悪なサードパーティツールを特定することができます。厄介なコードを探し、それに対処するために、おそらく様々なツールを使うことになるはずです。WordPressの開発では、WP_DEBUGとQuery Monitorが典型例です。
継続的なデプロイ─ステージングと本番環境間の変更の同期
ライフサイクルのデプロイフェーズでは、どのコードをプッシュするかという決断を迫られます。一度にすべてを反映するのが楽かもしれませんが、必ずしも最善のアイデアとは限りません。
というのも、ステージング環境と本番環境がどれだけ似ていても、違いはあります。時間をかけたアプローチの方が一般的には賢明です。特定の改善のためのコード群をプッシュし、変更を監視し、次のプッシュのスケジュールを立てるといった流れです。
このコンセプトは継続的デプロイメントの中核を成すものであり、 デプロイメントにおいて重要視されるべきは安全性です。以前は、Kinstaからワンクリックで本番環境に変更内容を反映するのが一般的でした。しかし、現在では選択的プッシュ機能が搭載されています。これを使えば、ファイル、データベース、またはその両方を選びながら反映することができます。
これにはNginx、PHP、リダイレクト設定などの環境設定も含まれます。サイトの特定の一部分に小さな変更を加えるだけの場合は、大掛かりに感じるかもしれません。
もちろん、Kinstaの本番環境への反映機能を使う代わりに自分で作業を行うこともできます。最も安全なのは変更を自動化するのではなく、本番サイトで「変更内容を一つ一つ再現」することです。確かに、実装には時間がかかりますが、各変更内容を本番で監視できるメリットがあります。
そして、継続的デプロイメントを採用するにしても、バックアップは重要な要素になります。Kinstaでは、サイトのバックアップが毎日自動で作成されます。重要な操作の前にはシステムにより自動でバックアップが生成され、これとは別に手動でバックアップを取ることもできます。
各バックアップデータは特定の環境の完全なスナップショットになります。破損したサイトを修復する必要がある場合、ものの数分で以前の状態を回復できます。
まとめ
Kinstaのステージング環境は、実行するフェーズ数やワークフロー内の各ステップの性質に関係なく、サイトの作成、テスト、および本番環境へのデプロイを多方面から支援します。Kinstaで実行するすべてのサイトで標準ステージング環境を無料で使用できるため、高い柔軟性が確保できます。
さらにプレミアムステージング環境では、複数のインスタンスをセットアップしたり、本番サイトと一致するかたちでリソースを実行したりすることができます。Kinstaのステージング環境は、アプリケーションホスティングと組み合わせて使用することも可能です。ローカルから本番環境にサイトを移行し、MyKinstaからKinstaのすべてのツールを利用することができます。
Kinstaのステージング環境を汎用的なDevOpsのベストプラクティスと組み合わせて活用することについてご質問がありますか？以下のコメント欄でお聞かせください。
コメントを残す