移行をマスターする – サイトを A から B に移行するためのより速く、より簡単で、より安全な方法

公開: 2023-04-09

移行は難しい場合があります。失敗したときのフラストレーション (または完全な恐怖) は誰もが知っていますが、移行が成功したときの安堵感も知っています。移行のすべての複雑さと微妙な違いを考慮して、どうすれば成功率を高め、本当にやりたい仕事に集中する時間を取り戻すことができるでしょうか?

確立されたプロジェクトをローカルマシンにコピーする必要がある場合でも、少数の増分更新を本番環境に展開する必要がある場合でも、移行を高速化し、簡素化し、リスクを軽減する方法について説明します。

ビデオ: 移行をマスターする – サイトを A から B に移行するためのより迅速、簡単、安全な方法

スピーカー:

WP Engine のシニアプロダクトマネージャー、Kevin Hoffman 氏
Austin Wendt 氏、WP Engine のシニアプロダクトマネージャー

セッションのスライド:

Mastering-migrations–より速く、より簡単に、より安全にサイトをAからBに移動する方法ダウンロード

転写:

AUSTIN WENDT: 皆さん、ようこそ。ご参加ありがとうございます。お待ちしております。 DE{CODE} カンファレンスへようこそ。

私の名前は Austin Wendt です。ここ WP Engine のシニアプロダクトマネージャーで、ローカルプロダクトの構築に取り組んでいます。そして、私の同僚であるケビンと私は、あなたがすぐにここで会うことになり、今日、よりスマートな構築について、特に移行をマスターするという観点から、お話しできることを楽しみにしています。そのため、サイトを A 地点から B 地点に移動するための、より速く、より簡単で安全な方法について説明します。これにより、サイトをローカルの安全な開発環境に移動する場合でも、自分で移動する場合でも、これらの開発ワークフローに自信を持つことができます。時間をかけてそのサイトを公開する準備ができています。

飛び込む前に、簡単な議題について説明します。今日カバーするのは、コードの移動について話すときに、ここ WP Engine で考えたい 3 種類の移行を紹介することです。理想的な移行ワークフローを定義し、このプレゼンテーションの過程で、コードを移行するさまざまな方法について説明します。既存のサイトをエクスポートし、それをダウンさせて、ローカル開発環境にインポートする方法について説明します。

初めての展開の実行について説明します。サイトを初めて稼働させるとき、それはどのようなもので、それを達成するためのいくつかの方法があります。次に、これら 2 つの環境を時間をかけて同期します。それでは、さっそく見ていきましょう。

私たちが考えている 3 種類の移行 - ユーザーが実行しようとしている主なオプションは 3 つあります。 1 つ目は、リモートからローカルへの変換です。そのため、すでに Web 上のどこかにホストされているサイトを持っていて、それを Local (おそらく小文字の l) のローカル環境に持ち込みたい場合、クライアントの既存のサイトで作業を開始する場合に便利です。つまり、新しいクライアントを継承したか、クライアントから変更を求められ、それを安全な場所に移動して、リスクの低い環境でトラブルシューティングを行うことができます。

また、最新のデータベースの変更を取り込もうとしているときにも非常に便利です。これにより、リモート環境と本番環境 (失礼ですが、開発環境) が可能な限り一致していることを確認できます。 2 つ目は、ローカルからリモートへです。したがって、個人のマシンからどこかのホストされたサーバーに戻るとき、つまり、初めて完全なサイトを展開するか、コードにいくつかの変更を加えてそれらの変更をプッシュするかのいずれかです。テーマやプラグインなど、サイトにライブで反映させたいものなら何でも。

2 つ目は、すみません、3 つ目はリモートからリモートです。今日はこれについて深く掘り下げることはしませんが、これから学習するツールを使えば可能になります。これは通常、ホスティングプロバイダーを切り替える場合 (ホスト A からホスト B に移動する場合) に使用するか、サイトがホストされている場所に関係なく、開発環境、ステージング環境、および運用環境の間を移動する場合に使用します。

それでは、Kevin に自己紹介を渡し、理想的な移行フローがどのようなものかについて説明します。ケビン、持って行って。

ケビン・ホフマン: ねえ、ありがとう、オースティン。私の名前は Kevin Hoffman です。WP Migrate のプロダクトマネージャーです。今日は、これから取り組む移行のタイプのゲームプランから始めて、物事を開始したいと思います。そのため、リモート環境からローカルマシンに移動し、リモートホストに戻るときはいつでも、困難な作業になる可能性があります。ただし、自信を持ってこれらの移行を自分で行うことができるように、ソリューションのゲームプランをこのプレゼンテーションに残しておいてください。

まず、古いホストから既存のサイトを取得します。そのため、WP Migrate を使用した完全なサイトエクスポートが含まれます。次に、ローカルに移動して、ローカル開発の変更を行い、そのサイトを新しいホストにデプロイします。

作業を開始するために、WP Migrate を使用した完全なサイトエクスポートフローに移ります。なぜこのような状況でサイト全体のエクスポートを使用するのでしょうか? 2 つの環境間で直接プッシュまたはプルしないのはなぜですか? それにはいくつかの理由があります。

開始するには、WP Migrate の Pro バージョンを使用しますが、WordPress プラグインディレクトリにあるプラグインの無料バージョンである WP Migrate Lite を使用することもできます。

この状況で完全なサイトエクスポートを使用する 4 つの主な理由は、第一に、それが一方向の移行だからです。リモートホストから降りたいと思っていますが、戻る予定はありません。また、サイトを移動する既存のローカルインストールもありません。ある場合は、プッシュ移行またはプル移行を使用して、サイトをローカルマシンにダウンさせることができます。しかし、既存のインストールがないため、ドラッグアンドドロップでローカルにインポートするのが最も理にかなっています。

最後に、サイト全体のエクスポートを行うことで、無料のバックアップも取得できます。サイト全体が 1 つのバンドルされた zip ファイルにカプセル化されます。これは、将来の変更を行う前の優れたバックアップです。

作業を開始するために、WP Migrate にジャンプして、これがどのように機能するかを見てみましょう。

したがって、WP Migrate を最初に開くと、目の前に 6 つのアクションが表示されます。できるだけ早くリモートホストからサイトを取得したいので、エクスポートアクションを選択します。エクスポートプロファイルを開くと、データベースオプション、メディア、テーマ、プラグイン、WordPress コアファイルを構成できます。

先に進み、データベースの構成から始めましょう。必要に応じて、特定のテーブルまたは投稿タイプをこの移行から除外できます。しかし、今のところ、デフォルトの構成を使用して、リモートホストからサイト全体を取得したいと考えています。エクスポートするサイトの URL やローカルの WordPress インストールのパスなど、標準の検索および置換フィールドについて言及したいと思います。

ここで、手動で移行を行っていた場合は、これらの値を移動して、移行先に合わせて編集することをお勧めします。ただし、Local を使用しているため、この検索と置換を適切に処理してくれるので、これらのオプションフィールドに実際に入力する必要はありません。それらを空白のままにして先に進むことができます。

次は、カスタムの検索と置換です。これは、WordPress データベースまたはサイト全体のコンテンツ内の任意の文字列を検索する機能です。たとえば、古い会社名を新しい会社名に置き換えたい場合、これらのカスタムの検索および置換フィールドを使用してそれを行うことができます。また、必要に応じて行を追加できます。

これでデータベースが処理されます。メディアのアップロードに移りましょう。サイト全体を移動するので、[すべてのメディアアップロードをエクスポート] を選択します。ただし、ログ、バックアップ、キャッシュなど、エクスポートが肥大化する可能性のある一部のファイルは除外したいと考えています。

テーマファイルに進むにつれて、すべてのテーマを含めたいと思います。今回はアクティブなテーマだけです。ライブサイトに積極的に影響を与えているテーマだけに関心があるからです。

同様に、プラグインについても、アクティブなプラグインのみをエクスポートしたいと考えています。また、WordPress コアファイルについては、WordPress コアがエクスポート元のサイトの正確なバージョンと一致することを確認したいので、それらを含めたいと思います。

プロファイルが完全に構成されたので、エクスポートを開始できます。これにより、データベーステーブル、メディアアップロード、テーマ、プラグイン、および WordPress コアファイルをすばやく確認できます。

この時点で、データベースとサイト内のすべてのファイルが 1 つの便利な zip ファイルにまとめられます。そのため、わずか 18 秒でサイト全体が圧縮されました。

これで、ローカルに移動する準備が整いました。その前に、zip ファイルの内容を簡単に確認したいと思います。 files ディレクトリがあることがわかります。これには、WP コンテンツ、プラグイン、テーマ、アップロードを含むすべての WordPress ファイルが含まれます。また、データベースのダンプもあります。

もう 1 つのファイルは、WP Migrate に固有で非常に重要です。WP Migrate エクスポート JSON ファイルには、PHP バージョンや MySQL バージョンなど、エクスポートされたサイトに関する重要な情報が含まれているため、ローカルがインポートを処理するときに、そのリモート環境に可能な限り一致させることができます。

これで、Local にインポートする準備が整いました。そしてそれをオースティンに送り返します。

オースティン・ウェント: 素晴らしい、ありがとう、ケビン。ええ、Kevin が述べたように、その zip ファイルを Local にインポートしてビルドを開始する準備を整える方法について説明できることを楽しみにしています。しかし、最初に、ローカルとは何かを紹介したいと思います。ご存じない方のために説明すると、Local はここ WP Engine の人間によって構築されたナンバーワンの WordPress 開発ツールであり、コミュニティと無料で共有および提供できることを非常に楽しみにしています。

したがって、これは無料の開発ツールです。聞いたことがない場合は、localWP.com をチェックしてください。この製品をぜひご利用ください。しかし今日は、このワークフローを容易にするために Local を使用します。

なぜローカルなのか？マシンに固有の環境と同様に、リスクは非常に低くなります。そして、Kevin が言ったように、WP Migrate からそのエクスポートをインポートするときに Local がしようとしていることは、運用環境を厳密に模倣することです。したがって、WordPress のバージョン、PHP のバージョン、データベース、ローカルマシンは、本番環境で何が起こっているかをできる限り模倣する必要があります。これにより、トラブルシューティングを行ったり、何が問題なのかを確認しようとしている場合、Local はそれを知ることができるはずです。ホストされている環境で何が起こっているのか、できる限り近くにいてください。

Local でこれを行うもう 1 つの重要な利点は、Kevin が言及したワークフローがホストに依存しないことです。そのため、ホストしている場所が Flywheel か WP Engine かに関係なく、そのサイトをエクスポートして、非常に迅速かつ簡単にローカルにドロップできます。

そのため、デモを開始して、ローカル UI 内でこれがどのように見えるかを示します。

素晴らしいので、私はすでに WP Migrate を行っており、その zip をデスクトップに保存しました。ローカルでサイトを作成しようとすると、ここに zip ファイルをドラッグアンドドロップできることを示す新しいドラッグゾーンが表示されます。また、Local の優れている点は、UI 内のどの画面からでも実行できることです。したがって、そのzipファイルをローカルにドラッグアンドドロップすると、ケビンが言及したWP移行エクスポートJSONファイルからサイト名が提案されます.

PHP、Web サーバー、データベースがあらかじめ選択されています。次に、[作成] をクリックすると、残りは Local が処理します。そのため、Local はその zip ファイルを積極的に解凍し、それらの WordPress ファイルをすべてインポートして、可能な限り実稼働に近い状態でそのサイトを私のマシンにセットアップしています。

これが回転している間に、ホストファイルを更新する許可を求められます。パスワードを入力して更新を許可します。しかしその後、Local が WordPress の追加を開始し、準備完了です。

これが終了したら、すぐに強調したいのは、左側に表示されていることです。サイトをグループ化する機能は、ここ数週間でローカルに新しく追加されました. そこで、Garrett's Grocery を私の DE{CODE} デモセクションにドラッグアンドドロップします。これは、WP に接続されたクライアント別またはバージョン別にサイトをグループ化し、サイトを整理するためにチェックアウトすることをお勧めする良い方法です。エンジンであろうとなかろうと、あなたにとって最適なものは何でも。だから試してみてください。

しかし、ローカルはここで終わりです。そのサイトのドメインを変更しています。ここでわかるように、mysite.local で利用できるように、自分のマシンで構成します。 [サイトを開く] をクリックすると、Garrett's Grocery が表示されます。そのため、ホストされている環境から効果的に移動し、それをローカルにドラッグアンドドロップして、2 分もかからずに自分のマシンで実行できるようになりました。これはすばらしいことです。

したがって、この例で示したのは、インターネット上のどこにあるかに関係なく、古いホストからそれを取得できることと、WP Migrate フルサイトエクスポートを組み合わせてローカルに取得し、あなたのホストを模倣できることです。数分もかからずに本番環境に移行できます。

さて、問題は、ローカルで取得したら、変更を開始する準備ができているということです。それを元に戻し、再びインターネット上で公開するにはどうすればよいですか? サイトをローカルから取得してホストに戻すために、ローカル接続を使用して WP エンジンまたはフライホイールにデプロイします。サイト全体の移行と部分的な移行の両方から。

しかし、なぜ完全なサイト展開を行う必要があるのでしょうか? サイト全体をホストに初めて展開するのは、ここでの良い例です。したがって、そのサイトはまだまったく存在しないか、ホスト上にテンプレート化されたサイトである可能性があります。テーマ全体またはプラグインの変更を含めたい場合、または今日ホスト上にある現在のサイトを完全に上書きする準備ができている場合. すでにコンテンツがあるかもしれませんが、現在そこにあるものはもはや生産的または助長的ではなく、それを消去する準備ができている場合は、完全なサイト展開を使用します.

したがって、Local を使用すると、これはかなり簡単に実現できます。そして、それがどのように見えるかのデモをお見せします。ここに Garrett's Grocery があります。ウェブサイトに一連の変更を加えたので、プッシュアップする準備ができています。 Local には Local Connect の概念があります。前述のように、Connect の左側にこの雲のアイコンがあります。右下にはホストへの接続もあり、WP エンジンまたはフライホイールに接続できます。

今日は、[接続] タブに移動し、[プラットフォームに接続] をクリックしてこれを実現します。 WP Engine アカウントにログインします。これは、ログインするのを見逃すことはありませんでした。Local Connect が、WP Engine でアクセスできるすべてのサイトをプルしていることがわかります。さて、私がやろうとしていることは、概説で Garrett's Grocery に戻ることです。右下で、[WP Engine に接続] を選択します。

Local は、そのサイトが WP Engine のインフラストラクチャと互換性があることを確認します。そのため、最新の WordPress と PHP を使用すると、[Push] をクリックできます。

プッシュにより、WP エンジンで上書きしたいサイトを選択できるようになります。環境を選べるようになります。そこで、Austin Wendt サイトを選択し、Production を選択します。画面の右側に表示されるのは、ローカルがファイルリストを決定していることです。

つまり、ローカルとは、基本的に、マシン上にあるものとサーバー上に存在するものとの差分を実行し、それを提供して、これから行う変更を実際に見て理解できるようにすることです。これは完全なサイト展開であるため、私のローカル環境では何も起こっていないことがわかりますが、右側の赤い X でわかるように、運用環境にあるすべてのものを上書きします。

次に、[Push to WP Engine] をクリックすると、Local が残りの処理を開始します。このビデオ全体は約 4 分です。私がここに座っているので、一緒に見ることは割愛します。何が起こっているかというと、Local がそれらのファイルを圧縮しています。これらのファイルを WP Engine にアップロードし始めます。そして、私が言ったように、自分のマシンにあるものと WP Engine サーバーにあるものの違いを分析し始めています。

Flywheel でホストする場合、これと同じワークフローが Flywheel にも適用されます。マシンとサーバーの間のファイルの違いを入力する同じフローに従います。

これで、Local はデータベースのパックを開始します。それをWP Engineにもプッシュしています。そのため、リモートサーバーに存在する既存のテーブルをすべて削除し、それらを私のマシンからのものに置き換えています。

データベースの移行の一環として、サイトドメインを調べて、検索と置換を実行します。これはご覧のとおりです。データベースに保存されているすべてのリンクと URL が、テーブルのプレフィックスと共に更新され、運用環境で正しく機能するようにします。

したがって、これらのテーブルプレフィックスが更新されます。このように、私のサイトは WP Engine にプッシュされました。

これをもう一度始めると、Garrett's Grocery はまだ私のマシンにあります。また、Connect タブに移動すると、プッシュした Austin Wendt サイトが右側に表示され、Garrett's Grocery に接続されていることがわかります。そのサイトの名前である Austin Wendt をクリックすると、ブラウザが開き、インターネット上で公開されている新しいコンテンツが表示されます。

Local を使用して完全なサイト展開を実現する方法を理解したので、Local を使用して、MagicSync として知られている機能を使用して環境を同期する方法について説明したいと思います。

したがって、MagicSync は増分移行の別の言葉です。したがって、ローカル環境とリモートサーバーの間でコードのほんの一部を移動するだけです。そして、なぜこれをしたいのですか？

そのため、サイト全体を置き換えたくない場合があります。公開する準備ができている既存のサイトに小さな部分的な変更を加えただけです。 Local のもう 1 つの優れた点は、前述したように、Local を使用すると、その diff 機能を使用して、含めるファイルを選択したり、除外したりすることができることです。ここでの大きな一般的な使用例は、自分のマシンで多くのことを行った可能性がありますが、メディアのプッシュとプルは除外したいと考えています。メディアの選択を解除できます。

そこで、MagicSync がどのようなものかを示すデモに飛び込みます。繰り返しになりますが、ここに Garrett's Grocery があります。たとえば、今回は別の小さな変更を加えたので、それが WP Engine にライブで反映されるのを確認する準備ができています。ここでも同じワークフローです。画面の右下で、WP Engine にプッシュするために戻ります。私が最後にやったときのことを思い出して、私と環境のために既にオースティン・ウェントのサイトが事前に選択されています。

そして今回は、もっと短くなります。これもまた、自分のマシンにあるものと WP Engine サーバーにあるものとの違いを判断することです。そのため、ここに戻ってきて、サイトに加えられた小さな変更セットが検出されます。必要なすべてのファイル変更の選択を解除できます。 WP コンテンツフォルダーのみを選択できます。

または、この場合、データベースをプッシュしたいだけだとしましょう。データベースボックスをチェックして、Push をクリックします。 Local が実際に WP Engine にファイルをプッシュしていないことを除いて、今起こっていることは以前に目撃したのと同じワークフローです。自分のマシンで行ったデータベースの変更を、現在 WP Engine サーバーにあるデータベースに置き換えるだけです。

ここでも同様のワークフローです。それほど長くはかからないため、この 1 つのプロセスを実際に見ていきます。偏差値が小さいからです。データベースを WP Engine にアップロードします。ローカルは、再び、私のために前進し、その検索と置換を行います。したがって、テーブルのプレフィックスが変更されたかどうか、自分のマシンでは異なる URL をリモートホストに反映する必要があるかどうかを検出します。

それは私のためにそれらの更新を行います。そして、約 1 分足らずで、自分のマシンで行ったサイトの変更が WP Engine にプッシュされ、同僚や仲間が自分の行った作業を確認したいだけであるかどうかにかかわらず、使用する準備が整います。たぶん私は開発環境にプッシュしたか、それが本番環境で Web 上にあり、クライアントや顧客、または消費者が Web 上で表示できるようになっている場合です。

このように、サイトが WP Engine にプッシュされ、ブラウザに戻ると、サイトが更新されて反映されていることがわかります。 Local を使用してインクリメンタルマイグレーションを実行する方法を理解したので、WP Migrate ツールを使用してこれを実行する別の方法を示すために、Kevin に引き渡したいと思います。

ケビン・ホフマン: ねえ、ありがとう、オースティン。ローカルから WP エンジンへのワークフローを実行していただきありがとうございますが、ホスティングプロバイダーを常に制御できるとは限りません。次のワークフローでは、任意の 2 つの WordPress 環境間で移行する方法を示します。この場合、ローカルから他の Web ホストに移動します。

そのために、WP Migrate を使用して、プッシュとプルという概念を使用します。では、なぜプッシュまたはプルを行うのでしょうか。サイト全体のエクスポートとは対照的に、これは双方向の移行です。つまり、両方のサイトがすでに存在しており、長期的な見返りを得るには、もう少し先行投資が必要です。

したがって、このセットアップが完了すると、時間の経過とともに増分移行を処理し、2 つの環境を継続的に同期させる準備が整います。

それでは、それがどのように見えるか見てみましょう。では、サイトをリモートホストにデプロイする準備ができたとしましょう。メディアライブラリには多数の投稿と多数の画像があります。このコンテンツを新しいサイトに移動します。現在、投稿はなく、メディアライブラリには画像がありません。

ここで採用する別のアプローチは、プッシュ移行を使用することです。最初に求められたのは、リモートサイトからの接続情報です。そのため、リモートサイトに切り替えて、[設定] タブで接続情報をクリップボードに直接コピーできます。また、プッシュマイグレーションを有効にして、ローカルサイトからこれらのプッシュリクエストを受け入れることができるようにしたいと考えています。

その情報を接続情報ボックスに貼り付けることで、リモートサイトに接続され、データベースオプションを構成する準備が整いました。ここで気付く大きな違いは、エクスポートワークフローと比較して、URL とパスの検索側と置換側の両方が完全に入力されていることです。これは、WP Migrate が両方のサイトにあり、その情報にアクセスでき、移行を開始するために何も入力しなくても処理できるためです。

カスタムの検索と置換を行うつもりはありませんが、ライブラリからのすべてのメディアアップロード、およびすべてのテーマとプラグインを含めるつもりです。ここで、プラグインを選択するときに気付くユニークな機能の 1 つは、リモートサイトでのそのプラグインの状態が表示されることです。この場合、そこにはプラグインがないため、これらのプラグインはすべて初めて追加され、そのアイコンにカーソルを合わせると現在のバージョン番号が示されます。

このプロファイルを将来の使用のために保存し、Push Full Site という名前を付けます。そのため、完全なサイトをリモートの場所にプッシュする必要があるときはいつでも、このプロファイルに戻って実行するだけです。

プロファイルを実行すると、テーブル、メディアのアップロード、テーマ、プラグインが再び表示され、移行の進行中に要求のサイズに関する情報が得られます。

移行が完了したら、先に進んでモーダルを閉じると、2 つの環境が同期されます。

この時点で、プロファイル画面に再度アクセスして、保存されたプロファイルを再度実行する必要がある場合に、どのようにクリックして戻ることができるかを確認することをお勧めします。

これは、WP Migrate にプロファイルを保存した完全なサイト展開です。しかし、増分変更の展開についてはどうだろうかと疑問に思うかもしれません。オースティンが示したように、ローカルで MagicSync を使用することにより、これは WP Migrate でそれを行う別の方法です。別のプッシュプロファイルを作成し、同じ接続情報を入力しますが、今回はメディアアップロードを選択するときに、新しいメディアアップロードと更新されたメディアアップロードのみをプッシュします。

これは、移行が初めて実行されるときに、すべてが含まれることを意味します。ただし、その後のすべての移行では、変更されたメディアファイルのみが含まれます。

これは、テーマやプラグインを気にせずにコンテンツやメディアファイルをプッシュする場合に最適なワークフローです。このプロファイルを保存して、Push Content and Media という名前を付けます。

これで、2 つの異なる目的に使用できる 2 つの移行プロファイルができました。それらはプロフィール画面に保存されており、必要なときにいつでもアクセスできます。プルプロファイルを設定して、本番データをこのローカルサイトにプルし、2 つの環境を双方向で同期させることもできました。

以上で、ローカルと WP Migrate を使用してリモートからローカルに移動し、リモートに戻るワークフローを終了します。

ご覧のとおり、これでゲームプランは完了です。WP Migrate からの完全なサイトエクスポートを使用してリモートサイトから移動し、それをドラッグアンドドロップしてローカルにインポートし、WP Engine または Flywheel にプッシュするソリューションがあります。または他のホスト。したがって、これは移行ソリューションに関する氷山の一角にすぎず、WP Migrate と Local を一緒に使用すると何が可能になるかを示しています。

そのため、次に独自の移行を実行する必要がある場合に、ゲームプランが得られることを願っています。 WP Migrate と Local の Twitter アカウントで皆様からのご連絡をお待ちしております。残りの DE{CODE] をお楽しみください。ご参加いただきありがとうございます。