WordPressサイトの最新の展開

公開: 2022-06-30

私のように、ファイルをWebサーバーにプッシュする最初の経験は、cPanelなどのWebベースのファイルマネージャー、またはTransmitやFilezillaなどのファイル転送プロトコル（FTP）クライアントのいずれかを介したものでした。サーバーに接続し、ファイルをドラッグして、転送が完了するのを待ちます。

簡単ですよね？

ただし、静的HTMLファイルよりも複雑なもので作業を開始するとすぐに、コードのデプロイははるかに複雑になりました。他の人が必要とするファイルや、グローバルインクルードのセミコロンを見逃して、ホワイトスクリーンが表示された場合はどうなりますか。サイト全体？プロセス中に重要なステップを見逃した場合はどうなりますか？

これらの「カウボーイコーディング」の問題は、より多くの人、環境、依存関係が関与するにつれて悪化するだけです。その結果、これらすべての可動部品をジャグリングしながら進歩を続けることはますます難しくなっています。何よりも悪いことに、コードをリリースすることは大きな問題となり、常に不安を引き起こします。

アプリケーション、サイト、およびストアがより近代化されるにつれて、展開も近代化する必要があります。バージョン管理から継続的デリバリーまで、最新のリリースプロセスにより、展開に関する不安を和らげることができます。

バージョン管理による変更の追跡

アドホックアップデートやカウボーイコーディングから脱却するための最初のステップは、Gitなどのツールを使用してサイトをバージョン管理下に置くことです。

バージョン管理を使用すると、何が変更されたか、誰が変更を加えたかを確認でき、ブランチを使用して複数の変更セットを同時に処理することもできます。その結果、作業は上書きされず、ファイル間の競合が明確に強調表示されます。

これまでGitを使用したことがない場合でも、恐れることはありません。Gitの概要と、より高度なGitワークフローに関する投稿の両方を作成しました。

何を追跡するかを決定する

サイトをバージョン管理下に移動するとき、追跡しないことは、実行することとほぼ同じくらい重要です。

一般的に、バージョン管理はソースコードを追跡するためのものであり、ツールやプロセスによって生成されたアセットではありません。これには、CSSとJavaScriptの連結/縮小、外部依存関係などが含まれます。まとめて、これらのアイテムをアーティファクトと呼びます。

たとえば、SassなどのCSSプリプロセッサを使用している場合、生成されたCSSファイルをバージョン管理下で追跡しないでください。それらは簡単に再現できるだけでなく、読みにくく、複数の開発者が関与している場合、マージの競合の一般的な原因となります。

依存関係（ライブラリ、WordPressプラグインなど）に関しては、リポジトリで責任のないコードをバンドルするのではなく、ComposerやWPackagistなどのツールを利用してください。

さらに、Gitリポジトリには、パスワード、SSH秘密鍵、または秘密と見なされるその他の機密情報を含めることはできません。リポジトリのコピーを持つすべての開発者は、その機密情報を自分のコンピューターに持っているからです。

リポジトリの構造化

WordPressまたはWooCommerceサイトのGitリポジトリを設定するときは、通常、このディレクトリの上のファイルにアクセスしないため、wp-content/をリポジトリのルートとして扱うのが一般的に最適です。

サイトで使用されているがコードを維持していないプラグインとテーマは、外部の依存関係であるため、Composerを介してロードする必要があります。同様に、処理されたCSSファイルとJavaScriptファイルは、リリースプロセスの一部として作成されるため、.gitignoreファイルを介して除外する必要があります。

開始するために、GitHubで無料のリポジトリテンプレートを利用できます。

CI/CDの紹介

ソフトウェアの展開に関しては、継続的インテグレーション（CI）と継続的デリバリー（CD）という2つの重要な用語を理解する必要があります。

これらの2つの用語は密接に関連しているため、まとめて「CI / CD」と呼ばれることが多く、変更が流れるパスが「CI/CDパイプライン」になります。このパイプラインは通常、次の形式を取ります。

リリースをビルドします。依存関係（Composer、npmなど）をインストールしてから、アーティファクト（Webpack、Grunt、Sassなど）をビルドします。
ビルドのテスト：単体テストの実行、コーディング標準の確認、静的コード分析の実行など。
リリースを1つ以上の環境にデプロイします

継続的インテグレーションは、コードを継続的にテストして、変更によって既存の機能が損なわれないことを確認し、新しい変更が既存のコードベースと完全に統合されるようにするプロセスです。新しい変更がプッシュされるたびに、「ビルドが壊れていない」ことを確認するためのチェックが実行されます。

継続的インテグレーションを有効にするには、これらのチェックを自動化する必要があります。たとえば、一連の単体テストがある場合、新しいプルリクエストが開かれるたびにこのテストスイートを実行して、コードが本番環境に移行する前に破損の可能性があることを警告することができます。

ただし、継続的インテグレーションは単体テストに限定されません。コードに対して自動的に実行できる「コードフリー」チェックが多数あるため、次のようなものがあります。

コーディング標準チェック（PHP_CodeSniffer、PHPコーディング標準フィクサー）
静的コード分析（PHPStan、Psalm）

プッシュするたびにこれらのチェックを自動的に実行すると、すべてのコードが同じチェックで実行され、合格しなかったコードがリリースされるのを防ぐことができます。

一方、継続的デリバリーとは、いつでもコードを「デリバリー」（デプロイ）できるようにするという考え方です。これを実現するには、ボタンをクリックするだけでコードをシームレスに本番環境に移行するスクリプト化されたデプロイメントプロセスが必要です。

デプロイメントのスクリプトを作成するということは、定期的かつ一貫してデプロイできることを意味します。すべての展開は、前の展開と同じように機能する必要があります。その結果、チームはより高いレベルの自信を持ってより定期的に展開でき、誰かが途中で一歩を逃した心配が少なくなります。一部のチームでは、1日に数十回（または数百回）を展開することも珍しくありません。

サイトによっては、「もう1つのCD」である継続的デプロイを調べることもできます。継続的デリバリーと非常に似ていますが、このモデルでは、ブランチへのすべてのプッシュが自動的にデプロイされます。これは、ブランチバージョン管理スキーム（Github Flowなど）を使用する場合に非常に強力ですが、リリースウィンドウをスケジュールする必要がある場合、またはメインブランチですべての作業を行う必要がある場合は望ましくない場合があります。

CI/CDを使用したWordPressまたはWooCommerceサイトの展開

基本的な用語を理解したので、典型的なWordPressまたはWooCommerceサイトの展開を見てみましょう。

この演習では、WPPusherの背後にいる同じ人々のWordPress開発者のニーズに合わせて設計されたCI/CDツールであるBranchを使用します。何よりも、BranchにはNexcessへのデプロイのサポートが組み込まれています。

開始するには、GitHub、GitLab、またはBitbucketアカウントに接続し、最初のサイトを作成して、Branchにサインアップします。

次に、サイトの構築に必要なすべての手順を構成します。 Branchは、一般的なアクション（Composerの依存関係のインストール、Webpackの実行など）のための多数の「レシピ」を提供しますが、任意の数のカスタムステップを追加する機能も提供します。

サイトの構築に必要な手順の概要を説明したら、パイプラインの次の段階であるテストに進むことができます。

サイトの自動テストスイートがすでにある場合は、必要なコマンドを実行するようにBranchに指示するだけです。まだテストを行っていない場合でも、Branchを使用すると、リンティング、コーディング標準、および互換性チェックを簡単に追加できます。

依存関係をインストールし、すべてを構築し、テストに合格したので、コードを本番環境に移行します。

Branchには、Nexcess（および他の主要なホスティングプロバイダー）にデプロイするためのレシピが含まれており、2つのプラットフォームを簡単に接続できます。

ブランチダッシュボードでサイトを選択し、[設定]をクリックして、ブランチサイトの公開SSHキーを取得します
この公開鍵をNexcessポータル内の鍵のリストに追加します

BranchがNexcessサイトと通信できるようになったら、「Nexcess」展開レシピを選択して、いくつかの詳細を入力できます。

サイトのホスト名とユーザー名（サイトの「アクセス」画面のNexcessポータルから入手可能）
デプロイ先のWebルート。 gitリポジトリがwp-content/ディレクトリとして機能することを意図している場合、この値は「public_html/wp-content」である必要があります。
デプロイするファイル（通常、デフォルトの「*」で十分です）
この環境にデプロイするgitブランチ

「Gitブランチ」設定は特に重要です。これにより、ブランチごとに異なるデプロイメントを指定できるようになります。たとえば、ステージング環境にデプロイする「ステージング」ブランチがあり、変更を公開する前にテストすることができます。

ブランチはデフォルトで継続的デプロイモデルを使用し、パイプラインは特定のブランチへのプッシュごとに実行されることに注意してください。継続的デリバリーモデル（手動でのアクションが必要な場合）を希望する場合は、リリースの準備ができたときにのみマージされる「本番」ブランチを維持することを検討してください。

この時点で、gitリポジトリをビルドしてNexcessにデプロイするようにBranchを構成する必要があります。サイトの[パイプライン]ページの[デプロイの実行]ボタンをクリックするか、Gitリポジトリにプッシュすることで、最初のデプロイをトリガーできます。

リリースプロセスのカスタマイズ

Branchの非常に優れた機能の1つは、展開後にサイトのオブジェクトキャッシュを自動的にクリアするなど、展開が成功した後に追加の手順を構成できることです。これは、「その他」のWP-CLIレシピを使用して実行できます。

ホストとユーザー名は通常、展開手順で使用したものと同じであり、必要な数のコマンドをチェーンできます。

結論

それでもカウボーイコーディングのアンティックや不安に満ちたリリースに苦労している場合は、Branchを見て、展開を簡単にしてください！