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 加載，因為它們是外部依賴項。 同樣，應通過 .gitignore 文件排除已處理的 CSS 和 JavaScript 文件，因為這些工件將作為我們發布過程的一部分為我們構建。

我們在 GitHub 上提供了一個免費的存儲庫模板來幫助您入門。

CI/CD 簡介

在部署軟件時，需要理解兩個重要術語：持續集成(CI) 和持續交付(CD)。

這兩個術語密切相關，以至於它們經常被統稱為“CI/CD”，我們的變更流經的路徑因此成為“CI/CD 管道”。 該管道通常採用以下形式：

  1. 構建版本：安裝依賴項（Composer、npm 等），然後構建工件（Webpack、Grunt、Sass 等）
  2. 測試構建：運行單元測試、檢查編碼標準、執行靜態代碼分析等。
  3. 將版本部署到一個或多個環境

持續集成是持續測試我們的代碼以確保更改不會破壞現有功能的過程，以便我們的新更改與現有代碼庫乾淨地集成。 每當推送新更改時，都會運行檢查以確保我們不會“破壞構建”。

為了使持續集成有用，這些檢查必須是自動化的。 例如，如果您有一套單元測試，您可以選擇在每次打開新的拉取請求時運行此測試套件，從而在代碼投入生產之前提醒您可能出現的損壞。

然而，持續集成不限於單元測試，因為有許多“無代碼”檢查可以針對您的代碼自動運行，包括：

  • 編碼標準檢查 (PHP_CodeSniffer, PHP Coding Standards Fixer)
  • 靜態代碼分析（PHPStan、Psalm）

在每次推送時自動運行這些檢查還可以確保所有代碼都通過相同的檢查運行，從而防止未通過的代碼被釋放。

另一方面，持續交付是我們應該能夠在任何給定時刻“交付”（部署）我們的代碼的想法。 為了實現這一點，我們必須有一個腳本化的部署過程，只需單擊一個按鈕，就可以將我們的代碼無縫地投入生產。

為您的部署編寫腳本意味著您可以定期和一致地進行部署； 每個部署都應該與之前的部署相同。 因此，您的團隊可以更有信心地進行更頻繁的部署，並且更少擔心有人在此過程中錯過了一步。 對於一些團隊來說，一天部署數十次（甚至數百次）的情況並不少見！

根據您的站點，您甚至可能想要查看“另一張 CD”，持續部署； 它與持續交付非常相似，但在此模型下，每次推送到分支都會自動部署。 這在使用分支版本控制方案（例如 Github Flow）時可能非常強大，但如果您需要安排發布窗口或在主分支中完成所有工作，則可能不受歡迎。

使用 CI/CD 部署 WordPress 或 WooCommerce 站點

現在我們已經掌握了基本術語，讓我們來看看部署一個典型的 WordPress 或 WooCommerce 網站：

在本練習中，我們將使用 Branch，這是一個 CI/CD 工具，它是圍繞 WP Pusher 背後的同一個人的 WordPress 開發人員的需求而設計的。 最重要的是，Branch 內置了對部署到 Nexcess 的支持！

首先，通過連接您的 GitHub、GitLab 或 Bitbucket 帳戶註冊 Branch，然後創建您的第一個站點。

接下來，我們將要配置構建站點所需的所有步驟。 Branch 為常見操作（安裝 Composer 依賴項、運行 Webpack 等）提供了許多“配方”，但也使我們能夠添加任意數量的自定義步驟。

一旦我們概述了構建網站所需的步驟，我們就可以進入管道的下一個階段：測試。

如果您的站點已經有一個自動化測試套件，您可以簡單地告訴 Branch 運行任何必要的命令。 即使您還沒有測試，Branch 也可以輕而易舉地添加 linting、編碼標準和兼容性檢查。

現在我們已經安裝了依賴項，構建了所有內容並通過了測試，是時候將我們的代碼投入生產了！

Branch 包含部署到 Nexcess（以及其他主要託管服務提供商）的方法，並且連接兩個平台很容易：

  1. 在分支儀表板中選擇您的站點，單擊“設置”，然後獲取您的分支站點的公共 SSH 密鑰
  2. 將此公鑰添加到 Nexcess 門戶中的密鑰列表中

一旦 Branch 能夠與您的 Nexcess 站點進行通信，我們就可以選擇“Nexcess”部署方案並填寫一些詳細信息：

  1. 站點的主機名和用戶名（可通過站點“訪問”屏幕上的 Nexcess 門戶獲得）
  2. 我們要部署到的 Web 根目錄。 如果我們的 git repo 打算用作 wp-content/ 目錄，那麼這個值應該是“public_html/wp-content”。
  3. 我們希望部署的文件（通常默認的“*”就足夠了）
  4. 要部署到此環境的 git 分支

“Git 分支”設置尤其重要，因為它可以讓您為不同的分支指定不同的部署。 例如，您可能有一個“暫存”分支部署到您的暫存環境，讓您在更改生效之前對其進行測試。

值得注意的是，Branch 默認使用持續部署模型，其中管道在每次推送到給定分支時運行。 如果您更喜歡持續交付模型（必須採取一些手動操作），您可能會考慮維護一個“生產”分支，該分支僅在您準備發佈時才合併。

此時，Branch 應配置為構建並部署您的 git 存儲庫到 Nexcess！ 您可以通過單擊站點“管道”頁面上的“運行部署”按鈕或推送到您的 Git 存儲庫來觸發您的第一次部署。

定制您的發布流程

Branch 的一個非常好的功能是能夠在成功部署後配置其他步驟，例如在部署後自動清除站點的對象緩存。 這可以使用“其他”下的 WP-CLI 配方來完成。

主機和用戶名通常與我們在部署步驟中使用的相同，您可以根據需要鏈接任意數量的命令。

結論

如果您仍在為牛仔編碼的滑稽動作和/或焦慮困擾的發布而苦苦掙扎，請查看 Branch，讓部署變得輕而易舉！