使用 Bitbucket 進行 WordPress 持續部署和版本控制

已發表: 2022-03-11

好的，伙計們。是時候坦白了。

如果你和我一樣，你在 WordPress 開發的第一階段是“牛仔編碼”——也就是說，在實時站點上進行大量更改，緊急測試並使用 FTP 啟動它們，通常會導致 500 條內部服務器錯誤消息和您尊敬的訪問者可以看到整個站點的中斷。

雖然這絕對令人興奮，因為腎上腺素從你的手指中抽出，在那個被遺忘的分號中猛烈撞擊，但在訪問者超過 0 人（實際上註意到停機時間）的網站上，這將開始成為一個問題。如果一棵樹倒下而沒有人聽到它，它會發出聲音嗎？取決於您所認同的人性理論。

但是，如果網站崩潰並且有人在那裡看到它，他們肯定會發出聲音。

WordPress 持續部署做錯了

進入臨時站點，複製 WordPress 安裝（至少在理論上）可以進行更改，然後在確認一切正常後再次在實時站點上進行。雖然這讓訪客安靜下來，但它開始讓我們的開發人員製造一些噪音。突然，我們需要跟踪兩個站點，確保代碼在它們之間手動同步，並再次測試所有內容以確保它在實時站點上運行。至少可以說，“確保在現場進行更改”和“確保在復制代碼之前在臨時站點上切換”的冗長而混亂的列表令人傷腦筋。該系統的備份也是一場噩夢——大量名為“my-theme-staging-1”和“my-theme-live-before-menu-restyle-3”的文件夾等等。

必須有更好的方法，而且確實有。

有 Git，它為開發人員提供了完美的源代碼控制和其他功能。對 WordPress 安裝使用版本控制可立即加快和清理開發，因為不再花費數小時在每個開發人員的系統中進行備份，而是實際用於編碼。更改已保存，我終於可以在我的工作中添加有意義的信息，與“my-theme-4-v2”不同的世界。

雖然代碼庫更乾淨了，但實際部署的問題仍然存在，並確保相關站點使用最新的代碼——輸入人為錯誤的機會。仍然依靠手動 FTP 上傳來覆蓋以前的代碼感覺不太好。雖然存在其他 CI/CD 服務，但它們中的許多都帶有可觀的價格標籤和大量的設置——服務器重新配置，即使是最簡單的網站也依賴另一種服務，學習其他服務的整個“做事方式”等等隨之而來的特質。

雖然可以使用 GitHub/GitLab 和其他服務完成與本教程類似的設置，但我很早就將我的雞蛋放在了 Atlassian 籃子中，因為它們有免費的私有存儲庫（這只是 GitHub 的最新產品）。當 Bitbucket 推出他們的管道和部署服務時，它允許新代碼自動部署到暫存或生產站點（或中間的任何其他站點），而無需通過 FTP 重新上傳或使用外部服務。開發人員現在可以在他們的 WordPress 開發中使用源代碼控制的所有值，並立即將這些更改發送到適當的目的地，而無需額外的點擊或擊鍵，所有內容的狀態都可以通過一個儀表板可見。這可確保所有內容保持同步，並且一目了然，讓您準確了解每個站點正在運行的代碼。此外，Bitbucket 構建分鐘的價格非常實惠——每月免費 50 分鐘，並且可以選擇“超時免費”計劃。

花了一些啟動時間來弄清楚如何在這個新模型中最好地使用分支和其他源代碼控制功能以及 Bitbucket Pipelines 設置的細節。這是我用於啟動新 WordPress 項目的過程。我不會詳細介紹設置 git 和 WordPress 安裝的所有細節，因為這方面的大量資源只需 Google 搜索即可。最後，內容流將是這樣的：

Alexa Green WordPress 部署程序

此處概述的步驟應根據需要執行：

在客戶端的服務器上

為活動站點設置域（例如，clientsite.com）和用於登台的子域（例如，staging.clientsite.com）。

在實時站點和登台子域上安裝 WordPress。這可以通過 cPanel/Softaculous（如果客戶的主機有這個）或從 wordpress.org 下載來完成。確保分別有單獨的數據庫用於實時和暫存。

在 Bitbucket.com 上

設置一個新的存儲庫。包括一個 .README 讓我們振作起來。

在存儲庫中， Settings > Pipelines > Settings然後選中Enable Pipelines 。

在Settings > Pipelines > Repository variables中，輸入以下內容：

 Name: FTP_username Value: The client FTP username

 Name: FTP_password Value: The client FTP password

返回Pipelines > Settings並單擊Configure 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

單擊提交文件。 Pipelines 設置現在將被提交並運行。

如果一切部署成功，返回並編輯 bitbucket-pipelines.yml 文件（您可以通過Pipelines > Settings和View bitbucket-pipelines.yml到達那裡）。您需要用git ftp push和 save/commit 替換上面寫著git ftp init的兩個地方。這將確保僅上傳更改的文件，從而節省您的構建時間。您的 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

添加一個名為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 上傳到登台站點。任何時候你提交到 master，它都會觸發一個 FTP 上傳到生產站點。請注意，這將使用構建分鐘數，因此您可能希望在 main-dev 的分支上進行大多數本地更改，然後在當天完成後合併到 main-dev。

將 main-dev 合併到 master 將帶來所有暫存更改。您可以在 Bitbucket.org 上的 repo 上查看 Pipelines 和 Deployments 的狀態。

跨安裝同步 WordPress 數據庫

請注意，以上只會同步文件（主題、插件等）。在生產和登台之間同步數據庫變成了另一回事，因為客戶經常在實時站點上進行未反映在登台站點上的更改，反之亦然。

對於跨 WordPress 安裝同步數據庫，存在幾個選項。傳統上，您可以通過phpmyadmin導入/導出來更新數據庫。不過這很棘手，因為它無法更新某些需要更新的內容，例如帖子內容中的永久鏈接。使用這種方法，最喜歡的工具是 Velvet Blues 更新 URL 插件，然後您可以使用它來搜索/替換舊站點 URL 的任何實例（例如，https://staging.clientsite.com）到新站點 URL（例如，https://clientsite.com）。您也可以將其與相對路徑和字符串一起使用。這種方法最終為人為錯誤留下了很大的空間——如果替換的字符串寫錯了，它可能導致整個站點崩潰並且無法使用插件/訪問儀表板。

雖然像 All-in-One WP Migration 這樣的插件提供了開箱即用的搜索/替換功能並且非常用戶友好，但它也帶來了文件，從而取消了我們整個 Pipelines 工作流程的價值。另外，由於它重新導入所有 wp-uploads，它可能會導致巨大的文件和加載時間（因此它不適合跨安裝移動更改）。像這樣的插件最好保留用於備份整個站點以用於存檔/安全目的。

VersionPress 似乎是一個有趣的解決方案，但尚未在許多生產環境中得到證明。目前，WP Sync DB 或 WP Migrate DB Pro 等插件似乎是數據庫管理的最佳解決方案。它們允許跨安裝拉/推數據庫，同時提供自動更新 URL 和路徑的選項。他們只能遷移某些表，例如僅用於發佈內容的 wp_posts，而不會浪費時間重新導入用戶和站點範圍的設置。我喜歡總是從現場拉出來，以確保沒有生產數據被覆蓋。如果您使用的是 WP Sync DB，這是一個示例設置（更多演練可在 WP Sync DB github 上找到）：

在實時站點上：設置 WP Sync DB 並啟用“允許從此存儲庫中提取”設置。
在臨時站點上：設置 WP Sync DB 與 Pull from Live 設置。將其命名為“現場直播”。
在您的本地開發設置上：設置 WP Sync DB 與從實時設置中提取。將其命名為“live-to-dev”。

您可能還想設置一個推送“dev-to-staging”規則，並檢查暫存站點設置以允許覆蓋數據庫。

包起來

我發現這些方法往往適用於大多數用例，無論是開發新的 WordPress 網站還是重新設計/重構已經存在的網站。

它允許代碼部署使所有站點版本保持最新，而無需增加開發時間/精力和用於在站點之間工作的有意、安全的數據庫遷移邏輯。更新插件也在源代碼控制中完成，因此可以在提交到實時站點之前安全地檢查插件更新，從而最大限度地減少生產站點中斷。

雖然將更多的源代碼控制工作流引入數據庫管理當然還有改進的餘地，但在生產環境中更多地使用像 VersionPress 這樣的工具之前，這種通過 WP Sync DB 或 WP Migrate DB Pro 選擇性地拉/推數據庫的方法似乎成為處理此問題的最安全方法。很想知道什麼適用於您的 WordPress 工作流程，或者如果在所有這些之後您寧願抓住您的套索和牛仔代碼！