Webフロントエンド

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

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

あなたが私のようなものなら、あなたはあなたの最初の足を過ごしました 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 彼らを紹介しました パイプラインと展開 これにより、FTP経由で再アップロードしたり、外部サービスを使用したりすることなく、新しいコードをステージングサイトまたは本番サイト（またはその間のその他のサイト）に自動的にデプロイできました。開発者は、WordPress開発でソース管理のすべての値を使用し、追加のクリックやキーストロークなしで、すべてのステータスを1つのダッシュボードに表示して、それらの変更を適切な宛先に即座に送信できるようになりました。これにより、すべての同期が維持され、各サイトで実行されているコードが一目で正確にわかります。さらに、価格設定 Bitbucketのビルド分は信じられないほど手頃な価格で、月に50分無料で、「超過分無料」プランのオプションがあります。

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

WordpressBitbucketスクリーンショット1

Alexa Green WordPress Depoyment Routine

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

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

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

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

Bitbucket.comで

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

WordpressBitbucketスクリーンショット2

リポジトリでは、 設定>パイプライン>設定 次に確認します パイプラインを有効にする 。

WordpressBitbucketスクリーンショット2

WordpressBitbucketスクリーンショット3

WordpressBitbucketスクリーンショット4

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

Name: FTP_username Value: The client FTP username Name: FTP_password Value: The client FTP password

WordpressBitbucketスクリーンショット5

帰ります パイプライン>設定 をクリックします 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

WordpressBitbucketスクリーンショット6

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

すべてが正常にデプロイされたら、戻ってbitbucket-pipelines.ymlファイルを編集します（そこからアクセスできます） パイプライン>設定 そして bitbucket-pipelines.ymlを表示する ）。 git ftp initと表示されている両方の場所を置き換える必要がありますgit ftp pushでと保存/コミットします。これにより、変更されたファイルのみがアップロードされるようになり、ビルドの時間を節約できます。 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

WordpressBitbucketスクリーンショット7

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のリポジトリでパイプラインとデプロイメントのステータスを確認できます。

WordpressBitbucketスクリーンショット8

WordpressBitbucketスクリーンショット9

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

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

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

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

cプログラミングを学ぶ場所

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

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

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

まとめ

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

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

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

基本を理解する

WordPressにはバージョン管理がありますか？

WordPressにはバージョン管理が組み込まれていないため、カスタムソリューションが必要です。

WordPressでGitHubを使用できますか？

WordPressでGitHubまたは別のバージョン管理ソリューション（GitLab、Bitbucket）を使用できます。これにより、WordPressでバージョン管理の最新の開発機能を使用できます。

BitbucketとBitbucketServerの違いは何ですか？

BitbucketとBitbucketServerはどちらもバージョン管理ソリューションです。 Bitbucketは標準製品であり、最小限のセットアップで済みますが、BitbucketServerはチームにより多くのカスタマイズと制御を提供します。

なぜBitbucketを使用するのですか？

Bitbucketは、Atlassianの信頼できるバージョン管理ソリューションであり、GitHubよりずっと前から無制限の無料プライベートリポジトリを提供してきました。 Pipelines CI / CDサービス（継続的インテグレーションとデプロイを数分でセットアップできる）およびJiraソフトウェア、第1の問題およびプロジェクト追跡ツールと統合します。