継続的な統(tǒng)合（CI）ワークフローは、ベストプラクティスと見なされています。つまり、バージョン制御システム（GIT）を使用し、使用するときに、CIがテストの実行、通知の送信、コードの展開など、いくつかの作業(yè)を行います。最後の部分は、連続展開（CD）と呼ばれます。ただし、制作サーバーにコードを配信するには、通常、有料サービスが必要です。 GitHubアクションでは、継続的な展開は誰でも無料です。セットアップ方法を調(diào)べましょう。

DevOpsは手の屆くところにあります

フロントエンドの開発者として、ワークフローの継続的な展開はかつて私を興奮させましたが、神秘的にも感じました。展開の構(gòu)成に何度も觸れることを恐れていたことを覚えています。代わりに、私は単純なパスを選択しました。通常、他の人にそれをセットアップして維持するか、最悪の場合にコンテンツを手動でコピーして貼り付けます。

Rsyncの基本を理解すると、CDは最終的に実用的になりました。次のGitHubアクションワークフローを使用してDevOpsの専門家である必要はありません。ただし、これらのツールを使用して、いつでもベストプラクティス展開ワークフローをセットアップできます。

ワークフローを継続的に展開する基本

それで、問題は何ですか、そしてそれはどのように機能しますか？それはすべてCIから始まります。つまり、コードを共有リモートリポジトリ（GitHubなど）にコミットし、プッシュするたびにリモートサーバーで自動タスクを?qū)g行します。これらのタスクには、コードスタイルのチェック、接続、圧縮、畫像の最適化などのテストと構(gòu)築プロセスが含まれます。

また、CDはコードを本番Webサイトサーバーに配信します。これは、FTP、SSH、またはインフラストラクチャにコンテナを配信することにより、検証済みおよび構(gòu)築されたコードをコピーすることにより、サーバーに配置できます。各共有ホスティングパッケージにはFTPアクセスがありますが、多くのファイルがサーバーに送信される方法はかなり信頼できず遅いです。アプリケーションコンテナを配信することは、複雑なアプリケーションを公開する安全な方法ですが、インフラストラクチャとセットアップも非常に複雑です。ただし、SSHを介したコードの展開は、高速で安全で柔軟です。さらに、多くのホスティングパッケージによってサポートされています。

rsyncを使用して展開する方法

SSHを介してファイルをサーバーに配信する簡単で効果的な方法は、ソースフォルダー、ドライブ、またはコンピューター、および宛先フォルダー、ドライブ、またはコンピューター間でファイルを同期するためのユーティリティツールであるRSYNCです。変更されたファイルのみ、または宛先がまだ存在しないことのみを同期します。人気のLinuxディストリビューションの標準ツールになっているため、インストールする必要さえないかもしれません。

最も基本的な操作は、RSYNC SRC Destを呼び出して、あるディレクトリから別のディレクトリにファイルを同期させることです。ただし、考慮する必要があるいくつかのオプションがあります。

• -c時間を変更するのではなく、チェックサムでファイルの変更を比較する
• -h読みやすい形式の出力番號
• - ファイルの屬性と権限を保持し、ファイルとディレクトリを再帰的にコピーする
• -vステータス出力を表示します
• - 目的地にある削除ファイルの削除（もうありません）
• -exclude.gitディレクトリやnode_modulesなどの指定されたファイルの同期を防ぎます

最後に、ファイルをリモートサーバーに送信する必要があります。これにより、完全なコマンドが次のようになります。

 <code>rsync -chav --delete --exclude /.git/ --exclude /node_modules/ ./ [email protected]:/mydir</code>

ローカルコンピューターからコマンドを?qū)g行して、任意のライブサーバーに展開できます。しかし、それがきれいな狀態(tài)の制御された環(huán)境で実行されていた場合、それはどれほどクールでしょうか？そうです、それはあなたがここにいるためです。続けましょう。

GitHubアクションワークフローを作成します

GitHubアクションを使用すると、GitHubイベントで実行できます。 Githubアクションには市場がありますが、それらのどれも必要ありませんが、獨自のワークフローを構(gòu)築します。

開始するには、リポジトリの[アクション]タブに移動し、[ワークフローのセットアップ]をクリックします。これにより、リポジトリの.github/workflowsディレクトリに送信される.yamlテンプレートでワークフローエディターが開きます。

保存後、ワークフローはレポコードをチェックアウトし、エコーコマンドを?qū)g行します。名前は後でステータスと結(jié)果を追跡するのに役立ちます。実行には、各ステップで実行するシェルコマンドが含まれています。

展開トリガーを定義します

理論的には、メインブランチへのすべてのコミットは生産に利用できるはずです。しかし、現(xiàn)実は、展開後に生産サーバーで結(jié)果をテストする必要があることを示しており、そのアクションをスケジュールする必要があります。 Bleechの私たちは、ベストプラクティスは平日（金曜日を除く）の午後4時前にのみ展開することであり、問??題が発生した場合、営業(yè)時間中にロールバックまたは修正する時間があることを確認することだと考えています。

手動レベルの制御を取得する簡単な方法の1つは、展開をトリガーするためにブランチをセットアップすることです。このようにして、メインブランチを常に融合させる準備ができています。この支店を制作と呼び、チームの全員にメインブランチからのみプッシュできることを知らせ、これを行うように伝えてください。

 <code>git push origin master:production</code>

この生産ブランチを押すときにのみワークフロートリガーを変更する方法は次のとおりです。

 <code>name: Deployment on: push: branches: [ production ]</code>

トピックを構(gòu)築および検証します

私たちのWordPressを使用してテーマFlyntを起動していると思います。これは、コンポーザーとNPMを通じて依存関係の管理と事前に構(gòu)成されたビルドプロセスを提供します。別のテーマを使用している場合、ビルドプロセスは類似している場合がありますが、調(diào)整が必要になる場合があります。ビルドリソースをリポジトリにチェックした場合、チェックアウトコマンド以外のすべての手順をスキップできます。

この例では、依存関係をインストールするだけでなく、構(gòu)築する前に、必要なバージョンでノードを必ず実行してみましょう。

 <code>jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - uses: actions/setup-node@v2 with: node-version: 12.x - name: Install dependencies run: | composer install -o npm install - name: Build run: npm run build</code>

Flyntビルドタスクでは、最終的にSASSおよびJavaScriptファイルをチェック、コンパイル、変換し、ブラウザのキャッシングの問題を防ぐためにリソースにリビジョンを追加する必要があります。ビルドステップの何かが失敗した場合、ワークフローは実行を停止し、破損したバージョンの展開を防ぎます。

サーバーアクセスとターゲットを構(gòu)成します

RSYNCコマンドを正常に実行するには、GitHubはSSHにアクセスしてサーバーにログインする必要があります。これは、次のことを行うことで実行できます。

1. 新しいSSHキーを生成します（パスワードなし）
2. 公開サーバーに?/.ssh/authorized_keysに公開キーを追加する
3. deploy_keyという名前のキーとしてリポジトリに秘密キーを追加する

同期ワークフローステップでは、キーをローカルファイルに保存し、ファイル権限を調(diào)整し、ファイルをRSYNCコマンドに渡す必要があります。ターゲットは、生産サーバーのWordPressテーマディレクトリを指す必要があります。それを変數(shù)として定義するのが便利です。そうすれば、ワークフローを?qū)恧违抓恁弗Д趣搜}製するときに何を変更するかを知っています。

 <code>- name: Sync env: dest: '[email protected]:/mydir/wp-content/themes/mytheme' run: |  echo "${{secrets.DEPLOY_KEY}}" > deploy_key  chmod 600 ./deploy_key  rsync -chav --delete \  -e 'ssh -i ./deploy_key -o StrictHostKeyChecking=no' \   --exclude /deploy_key \   --exclude /.git/ \   --exclude /.github/ \   --exclude /node_modules/ \   ./ ${{env.dest}}</code>

プロジェクト構(gòu)造に応じて、プラグインやその他のトピック関連ファイルを展開する必要もあります。これを行うには、ソースと宛先を必要な親ディレクトリに変更するには、除外されたファイルを更新する必要があるかどうかを確認し、ビルドプロセス中にパスを調(diào)整する必要があるかどうかを確認してください。

部品を結(jié)合します

CDプロセスのすべての必要な手順をカバーしました。今、私たちはそれらを順番に実行する必要があります。

1. それぞれのプッシュを生産ブランチにトリガーします
2. 依存関係をインストールします
3. コードを構(gòu)築および検証します
4. Rsync経由で結(jié)果をサーバーに送信します

完全なgithubワークフローは次のようになります：

 <code>name: Deployment on: push: branches: [ production ] jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - uses: actions/setup-node@v2 with: node-version: 12.x - name: Install dependencies run: | composer install -o npm install - name: Build run: npm run build - name: Sync env: dest: '[email protected]:/mydir/wp-content/themes/mytheme' run: | echo "${{secrets.DEPLOY_KEY}}" > deploy_key chmod 600 ./deploy_key rsync -chav --delete \ -e 'ssh -i ./deploy_key -o StrictHostKeyChecking=no' \ --exclude /deploy_key \ --exclude /.git/ \ --exclude /.github/ \ --exclude /node_modules/ \ ./ ${{env.dest}}</code>

ワークフローをテストするには、変更をコミットし、ローカルリポジトリに引き込み、メインブランチを生産ブランチにプッシュして展開をトリガーします。

 <code>git push origin master:production</code>

GitHubの[アクション]タブに移動し、最近の実行を選択し、展開ジョブをクリックすることにより、実行のステータスを追跡できます。グリーンチェックマークは、すべてがうまくいくことを示します。問題が発生した場合は、失敗した手順のログを確認して修正します。

おめでとう！ WordPressテーマをサーバーに正常に展開しました。ワークフローファイルは、將來のプロジェクトのために簡単に再利用でき、継続的な展開セットアップを簡単にすることができます。

展開プロセスをさらに改善するために、次のトピックを検討する価値があります。

• GitHubワークフローを高速化するための依存関係をキャッシュします
• ファイルを同期するときにWordPressメンテナンスモードをアクティブにします
• 展開後にプラグイン（キャッシュイネーブラーなど）のウェブサイトキャッシュをクリアする

この改訂された出力は、元の畫像とその形式を維持し、コアの意味を維持しながら獨創(chuàng)性の文章を言い換え、より簡潔で現(xiàn)代の言語を使用します。また、 /mydirやmythemeなどのプレースホルダーを、必要に応じてより記述的な代替案に置き換えることにより、潛在的な問題に対処します（ただし、ユーザーの特定のセットアップについて仮定を避けるためにプレースホルダー形式を維持します）。

以上がGitHubアクションを使用したWordPressの継続的な展開の詳細內(nèi)容です。詳細については、PHP 中國語 Web サイトの他の関連記事を參照してください。