使用github操作的連續部署WordPress

持續集成(CI) 工作流程如今被認為是最佳實踐。也就是說，您使用版本控制系統(Git)，並且在您使用它的過程中，CI 會為您完成一些工作，例如運行測試、發送通知和部署代碼。最後一部分稱為持續部署(CD)。但是，將代碼交付到生產服務器通常需要付費服務。使用GitHub Actions，持續部署對所有人都是免費的。讓我們來探討如何設置它。

DevOps 觸手可及

作為一名前端開發人員，持續部署工作流程曾經讓我興奮不已，但也感到神秘莫測。我記得很多次都害怕接觸部署配置。我反而選擇了簡單的途徑——通常是讓其他人設置和維護它，或者在最壞的情況下手動複製粘貼內容。

一旦我理解了rsync 的基礎知識，CD 最終變得切實可行。使用以下GitHub Action 工作流程，您無需成為DevOps 專家；但您仍然可以隨時使用這些工具來設置最佳實踐部署工作流程。

持續部署工作流程的基礎知識

那麼，問題是什麼，它是如何工作的呢？這一切都始於CI，這意味著您將代碼提交到共享遠程存儲庫（如GitHub），並且每次向其推送都會在遠程服務器上運行自動化任務。這些任務可能包括測試和構建過程，例如代碼風格檢查、連接、壓縮和圖像優化等。

CD 還將代碼交付到生產網站服務器。這可以通過複製經過驗證和構建的代碼並將其通過FTP、SSH 或通過將容器交付到基礎設施的方式放置在服務器上。雖然每個共享託管包都具有FTP 訪問權限，但將許多文件發送到服務器的方式相當不可靠且速度緩慢。雖然交付應用程序容器是發布複雜應用程序的安全方法，但基礎設施和設置也可能相當複雜。但是，通過SSH 部署代碼速度快、安全且靈活。此外，許多託管包都支持它。

如何使用rsync 部署

通過SSH 將文件交付到服務器的一種簡單有效的方法是rsync，這是一個在源文件夾、驅動器或計算機與目標文件夾、驅動器或計算機之間同步文件的實用程序工具。它只會同步已更改或目標位置尚不存在的文件。由於它已成為流行Linux 發行版上的標準工具，因此您甚至可能不需要安裝它。

最基本的運算是調用rsync SRC DEST 來將文件從一個目錄同步到另一個目錄。但是，您需要考慮一些選項：

• -c 通過校驗和比較文件更改，而不是修改時間
• -h 以更易於閱讀的格式輸出數字
• -a 保留文件屬性和權限，並遞歸複製文件和目錄
• -v 顯示狀態輸出
• --delete 刪除目標中在源中（不再）找到的文件
• --exclude 防止同步指定的文件，例如.git 目錄和node_modules

最後，您需要將文件發送到遠程服務器，這使得完整命令如下所示：

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

您可以從本地計算機運行該命令以部署到任何實時服務器。但是，如果它是在乾淨狀態的受控環境中運行的，那將會多麼酷炫？沒錯，這就是您來這裡的目的。讓我們繼續進行。

創建GitHub Actions 工作流程

使用GitHub Actions，您可以在任何GitHub 事件上運行。雖然GitHub Actions 有一個市場，但我們不需要任何一個，而是將構建我們自己的工作流程。

要開始，請轉到您的存儲庫的“Actions”選項卡，然後單擊“自行設置工作流程”。這將打開工作流程編輯器，其中包含一個.yaml 模板，該模板將提交到您的存儲庫的.github/workflows 目錄。

保存後，工作流程會檢出您的repo 代碼並運行一些echo 命令。 name 有助於稍後跟踪狀態和結果。 run 包含您要在每個步驟中運行的shell 命令。

定義部署觸發器

理論上，每次對主分支的提交都應該是可用於生產的。但是，現實告訴您，您還需要在部署後在生產服務器上測試結果，並且您需要安排該操作。我們在bleech 認為，最佳實踐是在工作日（除星期五外）僅在下午4:00 之前部署，以確保如果出現任何問題，我們有時間在辦公時間內回滾或修復問題。

獲得手動級別控制的一種簡單方法是設置一個分支來觸發部署。這樣，您可以隨時準備好將主分支合併到其中。將該分支稱為production，讓團隊中的每個人都知道只能從主分支推送該分支，並告訴他們這樣做：

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

以下是將工作流程觸發器更改為僅在對該production 分支進行推送時運行的方法：

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

構建和驗證主題

我假設您正在使用我們的WordPress 啟動主題Flynt，它通過Composer 和npm 提供依賴項管理以及預配置的構建過程。如果您使用的是不同的主題，則構建過程可能類似，但可能需要調整。如果您將構建的資源檢入到您的存儲庫中，則可以跳過除checkout 命令之外的所有步驟。

對於我們的示例，讓我們確保在構建之前以所需的版本執行node 以及安裝依賴項：

 <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 文件，然後為資源添加修訂以防止瀏覽器緩存問題。如果構建步驟中的任何內容失敗，工作流程將停止執行，從而防止您部署損壞的版本。

配置服務器訪問和目標

要使rsync 命令成功運行，GitHub 需要訪問SSH 以登錄您的服務器。這可以通過執行以下操作來實現：

1. 生成一個新的SSH 密鑰（無密碼）
2. 將公鑰添加到生產服務器上的~/.ssh/authorized_keys
3. 將私鑰作為名為DEPLOY_KEY 的密鑰添加到存儲庫

同步工作流程步驟需要將密鑰保存到本地文件，調整文件權限並將文件傳遞給rsync 命令。目標必須指向生產服務器上的WordPress 主題目錄。將其定義為變量很方便，這樣您就知道在將工作流程重複用於未來的項目時要更改什麼。

 <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>

根據您的項目結構，您可能還需要部署插件和其他與主題相關的文件。為此，請將源和目標更改為所需的父目錄，確保檢查排除的文件是否需要更新，並檢查構建過程中的任何路徑是否應進行調整。

將各個部分組合在一起

我們已經介紹了CD 過程的所有必要步驟。現在我們需要按順序運行它們，這些順序應：

1. 觸發對production 分支的每次推送
2. 安裝依賴項
3. 構建和驗證代碼
4. 通過rsync 將結果發送到服務器

完整的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>

要測試工作流程，請提交更改，將它們拉到您的本地存儲庫中，然後通過將主分支推送到production 分支來觸發部署：

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

您可以通過轉到GitHub 中的“Actions”選項卡，然後選擇最近的執行並單擊“deploy”作業來跟踪執行的狀態。綠色複選標記表示一切順利。如果出現任何問題，請檢查失敗步驟的日誌以修復它們。

恭喜！您已成功將WordPress 主題部署到服務器。工作流程文件可以輕鬆地重複用於未來的項目，從而使持續部署設置變得輕而易舉。

為了進一步完善您的部署流程，以下主題值得考慮：

• 緩存依賴項以加快GitHub 工作流程速度
• 在同步文件時激活WordPress 維護模式
• 部署後清除插件（如Cache Enabler）的網站緩存

This revised output maintains the original image and its format, rephrases sentences for originality while preserving the core meaning, and uses more concise and modern language. It also addresses potential issues by replacing placeholders like /mydir and mytheme with more descriptive alternatives where appropriate (but maintains the placeholder format to avoid making assumptions about the user's specific setup).

以上是使用github操作的連續部署WordPress的詳細內容。更多資訊請關注PHP中文網其他相關文章！