WordPressの継続的デプロイとBitbucketによるバージョン管理

公開: 2022-03-11

さて、皆さん。 '大騒ぎする時間。

私のような人なら、WordPress開発の最初の段階を「カウボーイコーディング」に費やしました。つまり、ライブサイトで乱暴に変更を加え、FTPで緊急にテストして起動し、500の内部サーバーエラーメッセージが表示されることがよくあります。サイト全体の休憩は、尊敬する訪問者にすべて表示されます。

アドレナリンが指から押し出され、忘れられたセミコロンを叩きながら、これは絶対にスリル満点でしたが、訪問者が0人を超えるサイト（実際にダウンタイムに気付いた）では、これが問題になり始めました。木が倒れて誰も聞いていない場合、音は鳴りますか？あなたが購読している人類の理論に依存します。

しかし、サイトがクラッシュし、誰かがそれを見るためにそこにいる場合、彼らは確かに音を立てます。

WordPressの継続的展開が間違って行われた

ステージングサイトに入り、変更を加えることができるWordPressインストールを複製し（少なくとも理論的には）、すべてが機能していることが確認されたら、ライブサイトで再度実行します。これが訪問者を静めている間、それは私たちの開発者にいくらかの騒ぎを引き起こし始めました。突然、2つのサイトを追跡し、コードがそれらの間で手動で同期されていることを確認し、すべてを再度テストして、ライブサイトで機能していることを確認する必要がありました。「ライブでこれを変更することを確認してください」と「コードをコピーする前にステージングサイトでこれを切り替えることを確認してください」の長くて厄介なリストは、控えめに言っても神経質でした。このシステムのバックアップも悪夢でした。「my-theme-staging-1」や「my-theme-live-before-menu-restyle-3」などの名前のフォルダが多数ありました。

より良い方法がなければなりませんでした、そしてありました。

開発者に完璧なソース管理やその他の機能を提供するGitがありました。 WordPressのインストールにバージョン管理を使用すると、開発者ごとのシステムでのバックアップに何時間も費やされなくなり、実際にはコーディングに費やされたため、開発が即座に迅速化およびクリーンアップされました。変更が保存され、「my-theme-4-v2」とは異なる世界で、最終的に意味のあるメッセージを自分の作品に追加できるようになりました。

コードベースはかなりクリーンでしたが、実際の展開の問題は依然として残っており、問題のサイトが最新のコードを使用していることを確認しました。人為的エラーの機会を入力してください。以前のコードを上書きする手動のFTPアップロードに依然依存しているのは、気分が良くありませんでした。他のCI/CDサービスは存在していましたが、それらの多くにはかなりの値札と大量のセットアップが付属していました。サーバーの再構築、最も単純なWebサイトでも別のサービスに依存し、他のサービスの「物事のやり方」全体を学習しました。それに伴う特異性。

このチュートリアルと同様のセットアップはGitHub/GitLabやその他のサービスで実行できますが、無料のプライベートリポジトリ（GitHubからの最近の提供のみ）のため、私は早い段階でアトラシアンバスケットに卵を入れていました。 BitbucketがPipelinesandDeploymentsサービスを導入したとき、FTP経由で再アップロードしたり、外部サービスを使用したりすることなく、新しいコードをステージングサイトまたは本番サイト（またはその間のその他のサイト）に自動的にデプロイできるようになりました。開発者は、WordPress開発でソース管理のすべての値を使用し、追加のクリックやキーストロークなしで、すべてのステータスを1つのダッシュボードに表示して、それらの変更を適切な宛先に即座に送信できるようになりました。これにより、すべての同期が維持され、各サイトで実行されているコードが一目でわかります。さらに、Bitbucketのビルド分の料金は非常に手頃で、月額50分無料で、「超過分無料」プランのオプションがあります。

この新しいモデルでソース管理のブランチやその他の機能を最適に使用する方法と、Bitbucket Pipelinesのセットアップの詳細を理解するには、起動に少し時間がかかりました。これが私が新しいWordPressプロジェクトを始めるために使うプロセスです。 gitとWordPressのインストールの設定については、Googleで検索するだけで、そのための優れたリソースをすべて紹介することはしません。最終的に、コンテンツフローは次のようになります。

Alexa Green WordPress Depoyment Routine

ここで概説する手順は、必要に応じて実行する必要があります。

クライアントのサーバー上

ライブサイト用のドメイン（例：clientsite.com）とステージング用のサブドメイン（例：staging.clientsite.com）を設定します。

ライブサイトとステージングサブドメインの両方にWordPressをインストールします。これは、cPanel / Softaculous（クライアントのホスティングにこれがある場合）を介して、またはwordpress.orgからダウンロードすることで実行できます。ライブ用とステージング用にそれぞれ別々のデータベースがあることを確認してください。

Bitbucket.comで

新しいリポジトリを設定します。 .READMEを含めて、私たちを立ち上げてください。

リポジトリで、 [設定]>[パイプライン]>[設定]を選択し、[パイプラインを有効にする]をオンにします。

[設定]>[パイプライン]>[リポジトリ変数]で、次のように入力します。

 Name: FTP_username Value: The client FTP username

 Name: FTP_password Value: The client FTP password

[パイプライン]>[設定]に戻り、[ bitbucket-pipelines.ymlの構成]ボタンをクリックします。次のページで言語としてPHPを選択します。次のコードのようなものを使用することをお勧めします。 PHPバージョンをクライアントのサーバーで使用しているものに置き換え、URL / FTPサーバーを実際のクライアントサイト（本番およびステージング）のURL/FTPサーバーに置き換えてください。

 image: php:7.1.29 pipelines: branches: master: - step: name: Deploy to production deployment: production script: - apt-get update - apt-get -qq install git-ftp - git ftp init --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com main-dev: - step: name: Deploy to staging deployment: staging script: - apt-get update - apt-get -qq install git-ftp - git ftp init --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com/staging.clientsite.com

[ファイルのコミット]をクリックします。これで、パイプラインのセットアップがコミットされて実行されます。

すべてが正常にデプロイされたら、戻ってbitbucket-pipelines.ymlファイルを編集します（ [パイプライン]>[設定]および[bitbucket-pipelines.ymlの表示]からアクセスできます）。 git ftp push git ftp init save/commitに置き換えます。これにより、変更されたファイルのみがアップロードされるようになり、ビルド時間を節約できます。 bitbucket-pipelines.ymlファイルは次のようになります。

 image: php:7.1.29 pipelines: branches: master: - step: name: Deploy to production deployment: production script: - apt-get update - apt-get -qq install git-ftp - git ftp push --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com main-dev: - step: name: Deploy to staging deployment: staging script: - apt-get update - apt-get -qq install git-ftp - git ftp push --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com/staging.clientsite.com

main-devというブランチを追加します。

ローカルマシン上

ローカルインストールに使用する空のディレクトリにリポジトリのクローンを作成します。 main-devブランチをチェックしてください。

このディレクトリにローカルWPインストールを設定します。これには多くのツールがあります—Flywheel、MAMP、Dockerなどによるローカル。すべてがクライアントのサーバーで実行されているものと同じ（WordPressバージョン、PHPバージョン、Apache / Nginxなど）であることを確認してください。

次のような.gitignoreを追加します。基本的に、Gitにwp-content以外のすべてを無視させたい（インストール間のインストールの問題を防ぐため）。また、大きなバックアップファイルやシステムで作成されたアイコンおよびDS_Storeファイルを無視するための独自のルールを追加することもできます。

 # Ignore everything * # But not .gitignore !*.gitignore # And not the readme !README.md # But descend into directories !*/ # Recursively allow files under subtree !/wp-content/** # Ignore backup files # YOUR BACKUP FILE RULES HERE # Ignore system-created Icon and DS_Store files Icon? .DS_Store # Ignore recommended WordPress files *.log .htaccess sitemap.xml sitemap.xml.gz wp-config.php wp-content/advanced-cache.php wp-content/backup-db/ wp-content/backups/ wp-content/blogs.dir/ wp-content/cache/ wp-content/upgrade/ wp-content/uploads/ wp-content/wflogs/ wp-content/wp-cache-config.php # If you're using something like underscores or another builder: # Ignore node_modules node_modules/ # Don't ignore package.json and package-lock.json !package.json !package-lock.json

.gitignoreを保存してコミットします。

変更を加え、それに応じてコミットします。

main-devにコミットするたびに、ステージングサイトへのFTPアップロードが起動されます。マスターにコミットするたびに、本番サイトへのFTPアップロードが発生します。これはビルド分を使用することに注意してください。そのため、main-devからのブランチでほとんどのローカル変更を行い、その日の作業が終わったらmain-devにマージすることをお勧めします。

main-devをmasterにマージすると、すべてのステージング変更が有効になります。 Bitbucket.orgのリポジトリでパイプラインとデプロイメントのステータスを確認できます。

インストール間でのWordPressデータベースの同期

上記はファイル（テーマ、プラグインなど）のみを同期することに注意してください。多くの場合、クライアントはステージングサイトに反映されていない変更をライブサイトで行っているため、本番環境とステージングの間でデータベースを同期することは別の問題になります。その逆も同様です。

WordPressのインストール間でデータベースを同期するために、いくつかのオプションがあります。従来、 phpmyadminを介してインポート/エクスポートすることでデータベースを更新できます。ただし、投稿コンテンツのパーマリンクなど、更新が必要な特定のものを更新できないため、これには注意が必要です。この方法を使用する場合、お気に入りのツールはVelvet Blues Update URLsプラグインです。これを使用して、古いサイトURL（https://staging.clientsite.comなど）のインスタンスを新しいサイトURL（https://staging.clientsite.comなど）で検索/置換できます。例：https：//clientsite.com）。これは、相対パスと文字列でも使用できます。この方法では、人為的エラーの余地が多く残されます。置き換えられた文字列が間違って記述されていると、サイト全体が破損し、プラグインを使用できなくなったり、ダッシュボードにアクセスできなくなったりする可能性があります。

All-in-One WP Migrationのようなプラグインは、箱から出してすぐに検索/置換機能を提供し、信じられないほどユーザーフレンドリーですが、ファイルも持ち込むため、パイプラインワークフロー全体の価値を取り消すことができます。さらに、すべてのwp-uploadsを再インポートするため、ファイルが膨大になり、読み込み時間が長くなる可能性があります（したがって、インストール間で変更を移動するのには適していません）。このようなプラグインは、アーカイブ/セキュリティの目的でサイト全体のバックアップ用に予約するのが最適です。

VersionPressは興味深いソリューションのように見えますが、多くの実稼働環境ではまだ証明されていません。今のところ、WPSyncDBやWPMigrateDBProなどのプラグインがデータベース管理に最適なソリューションのようです。これらは、URLとパスを自動的に更新するオプションを提供しながら、インストール間でデータベースをプル/プッシュすることを可能にします。投稿コンテンツ専用のwp_postsなど、特定のテーブルのみを移行でき、ユーザーの再インポートやサイト全体の設定に時間を浪費することはありません。本番データが上書きされないように、常にライブからプルするのが好きです。 WP Sync DBを使用している場合のセットアップ例を次に示します（WP Sync DB githubで利用可能なその他のウォークスルー）：

ライブサイトの場合： 「このリポジトリからのプルを許可する」設定を有効にして、WPSyncDBをセットアップします。
ステージングサイトの場合：[ライブからプル]設定を使用してWPSyncDBをセットアップします。「ライブからステージング」という名前を付けます。
ローカル開発者のセットアップ： Live設定からプルしてWPSyncDBをセットアップします。「live-to-dev」という名前を付けます。

また、プッシュ型の「dev-to-staging」ルールを設定し、ステージングサイトの設定を確認して、データベースを上書きできるようにすることもできます。

まとめ

これらの方法は、新しいWordPress Webサイトの開発と、すでに稼働しているサイトの再設計/再構築の両方で、ほとんどのユースケースで機能する傾向があることがわかりました。

これにより、開発時間/労力を追加することなく、すべてのサイトバージョンを最新の状態に保つコード展開と、サイト間で作業するための意図的で安全なデータベース移行ロジックが可能になります。プラグインの更新はソース管理内でも行われるため、ライブサイトにコミットする前に、ステージング時にプラグインの更新を安全にチェックできるため、本番サイトの中断を最小限に抑えることができます。

より多くのソース管理ワークフローをデータベース管理にもたらすための改善の余地は確かにありますが、VersionPressのようなツールが実稼働環境でより多く使用されるまで、WPSyncDBまたはWPMigrateDBProを介してデータベースを選択的にプル/プッシュするこの方法はこれに対処するための最も安全な方法であるために。 WordPressワークフローで何が機能するかを知りたい場合、またはこのすべての後で投げ縄をつかんでカウボーイがコーディングしたい場合は！