使用 Deploybot 部署到 Live 和 Staging
已發表: 2022-06-30如果您從事 Web 開發已經有一段時間了，那麼您可能在嘗試更新站點時搞砸了文件傳輸。 在最好的情況下，您將一堆易於識別的文件添加到目錄中，然後刪除它們以修復錯誤。 是的，這會花費你時間，而且很煩人，但不會造成任何傷害。
在最壞的情況下，您不正確地傳輸了一堆主題文件。 然後你必須弄清楚哪些被覆蓋，哪些根本不屬於，以及你將如何恢復主題的正確工作狀態。
今天我們將使用 Git 和 Deploybot 來解決這個問題，以自動化您的部署過程。
什麼是自動化部署？
一個基本的自動化部署有四個部分，如下圖所示。
大多數開發人員只從他們的代碼和服務器開始。 他們對站點的工作副本進行更改，然後通過 FTP 將這些更改直接推送到服務器。 Coda 或 Dreamweaver 等工具具有直接的 FTP 集成，因此您可以在編碼環境中執行此操作。
許多開發人員採取的下一步是添加一個臨時站點，這樣他們就不會直接修改實時服務器。 您可以使用 VVV 或 MAMP 之類的東西來做到這一點。 這通常也意味著您正在使用像 Git 這樣的版本控制系統來管理您對本地工作站點所做的更改。
添加臨時站點時，也會增加複雜性。 您如何將您的代碼更改從本地工作站點轉移到您的客戶可以看到更改的臨時站點？ 是的，正如我已經說過的，您可以使用 FileZilla、Transmit 或 Forklift 之類的基本 FTP 客戶端在您進行更改時移動文件，但這很容易出錯，這就是自動化部署過程將為您節省大量時間的地方。
您無需獲取更改的文件並將它們推送到暫存服務器，而是使用另一個系統自動檢測 Git 存儲庫中的更改，並僅將這些更改推送到您的客戶端可用於檢查工作的暫存站點。
但是，這仍然使您的實時站點成為手動部署，這更加可怕，因為如果您關閉實時工作站點，這可能意味著損失真金白銀。 相反，讓我們假設您要將部署系統設置為自動部署到登台，然後在您準備就緒時，只需單擊一下即可將系統部署到實時環境。
所以現在你有一個看起來像這樣的系統。
讓我們深入研究，以便向您展示我如何為與我合作的每個客戶設置此部署過程。 這些是我開始一個新項目後立即採取的步驟。 在開始對客戶項目進行任何其他工作之前，我始終確保我的部署過程已設置並正常工作。
如何構建你的 Git 存儲庫
您要做的第一個選擇是，您將在哪個目錄中設置您的自動部署？ 除非我的客戶特別要求對他們的 WordPress 安裝進行完整的源代碼控制，否則我會使用 wp-content 目錄來設置我的自動部署系統。 通過發出初始化 git 存儲庫的命令在終端中開始。
混帳初始化
現在是時候忽略您不想一直部署的文件了。 這些文件包括備份文件、圖像以及許多代碼編輯器添加到目錄中的任何自定義項目文件。 你可以在下面看到我常用的 .gitignore 文件。
配置/app_config.yml
配置/數據庫.yml
配置/*.sphinx.conf
config/s3_credentials.yml
*~
*.cache
*。日誌
*.pid
時間/**/*
.DS_Store
數據庫/cstore/**
分貝/獅身人面像/**
文檔/API
文檔/應用程序
文檔/插件
文檔/*.dot
覆蓋率/*
db/*.sqlite3
*.tmproj
*.sw?
*.esproj
_筆記*
dwsync.xml
播客.xml
*.kpf
*上傳/*
*.swp
*。主意
*.sublime-項目
*.sublime-工作區
*/node_modules/*
標籤
*.bak
緩存/*
管理wp/*
畝插件/ *
dp.php
上升氣流/*
語言/*
數據庫.php
插件/wp-rocket/cache.json
根據需要隨意添加或刪除。 幾乎我從事的每個項目都需要某種自定義條目來忽略某些特定於我的本地工作站點的文件，對於這些文件，暫存站點和實時站點將有自己的自定義文件，我不想覆蓋這些文件。
從這裡開始，是時候設置您需要讓您的部署系統運行的分支了。 我使用兩個主要分支。 首先是對應於我的現場生產站點的主分支。 其次，是一個我標記為 staging 的分支，它對應於我希望我的客戶用來檢查我們所做更改的臨時站點。
當你初始化你的 Git 存儲庫時，你已經有了你的主分支，所以使用這個命令來添加一個暫存分支並檢查它。
git checkout -b 暫存
此命令創建並簽出一個新分支。 如果您是 git 新手，可以在 Git 文檔中找到有關可用命令的更多信息。
現在您需要將項目推送到源代碼控制系統中。 Github 和 Bitbucket 是兩個流行的選擇，它們都可以與我們將使用的名為 Deploybot 的自動化部署系統一起使用。 當您使用任一站點創建新存儲庫時，它們將為您提供進一步的指導，將您的本地存儲庫添加到您在 Github 或 Bitbucket 中的在線版本。
- Bitbucket 存儲庫設置文檔
- Github 存儲庫設置文檔
設置部署機器人
當我第一次作為開發人員從事更複雜的工作時，我的朋友 Duane 一直在向我推薦 Deploybot，而我在網上抱怨手動 FTP 部署搞砸了。 在我最終按照別人告訴我的事情做之前，我接受了很多建議，但多年來我一直是一個快樂的 Deploybot 客戶。
雖然還有其他方法可以部署您的站點，但其中許多方法都涉及通過代碼編輯器與 Git Webhooks 或一些自動部署配置文件進行交互。 這些其他工具有很多強大的功能，但如果您剛剛開始使用自動化部署，那麼直接使用像 Deploybot 這樣的工具就是開始的地方。
要開始註冊 Deploybot 帳戶並將 Github 或 Bitbucket 連接到您的帳戶。 今天我將使用我現有的 Bitbucket 帳戶。 首先將新存儲庫添加到您的 Deploybot 帳戶。
找到要為自動部署設置的存儲庫後，單擊頁面底部標記為連接的按鈕。 當 Deploybot 完成對存儲庫的初始化時，這會將您返回到存儲庫頁面。 通常，這會在一兩分鐘內完成，因此請裝滿咖啡，然後回來完成部署過程的設置。
設置存儲庫後，單擊它以轉到其主頁。 由於我們還沒有設置 sFTP 信息，它上面會有一個大框告訴您設置服務器。 單擊按鈕以創建環境和服務器。
讓我們從部署到我們的暫存環境開始。 因此，將您的服務器標記為登台。 選擇自動部署並確保將分支設置為暫存。
完成後單擊頁面底部的保存按鈕以移動到您的服務器配置。
在下一頁上，再次將其標記為暫存服務器，並從您的站點輸入您的 sFTP 信息。 如果您不確定在哪裡可以找到它們，請閱讀這份有用的指南。
輸入您的 sFTP 信息後，您可以向下滾動到底部並保存。 然後，Deploybot 將測試您的連接，以確保您提供的信息有效。 現在是時候為站點進行初始部署以確保一切正常。 我經常將 test.txt 文件添加到部署中，作為驗證部署是否正常工作的簡單方法。
要開始部署到您的環境歷史記錄，然後單擊部署。
現在，您將看到一個頁面，其中包含您最後的 git 提交消息，作為您將在此部署旁邊的 Deploybot 中看到的註釋。 對於大的改變，我會改變它，但如果我只是改變 CSS 或一些小的東西，提交消息可以保留。 由於這是暫存，因此對我們暫存分支的每一次提交都將自動部署，這意味著您的提交消息將顯示出來。 這只是我們需要手動對暫存站點進行的初始提交。
現在驗證您的文件是否已發佈到臨時站點，我們可以設置實時部署。
對於您的實時部署，請確保您沒有選擇自動部署，並確保您選擇主分支作為您的部署源。 當我們準備好將更改推送到我們的實時站點時，我們希望這是手動部署。
為此，您需要檢查您的主分支，然後將您的更改從暫存分支合併到主分支。
您可以使用這些命令來做到這一點。
git結賬大師
git 合併暫存
git push 起源大師
現在，當您轉到您的 Deploybot 帳戶時，您將能夠手動部署您的更改，就像我們在初始部署到暫存環境時所做的那樣。 對於您的實時環境，請確保您更改部署消息以適應正在推送到您的實時站點的更改。 您還應該創建站點的備份。 您可以通過訪問站點上的備份導航然後創建手動備份來執行此操作。
就是這樣，您已經為暫存環境和實時環境設置了自動部署系統。
其他部署注意事項
雖然這個系統對於大多數開發人員來說是向前邁出的一大步，但它並非沒有問題。 最大的問題是，如果您有大量更改，您仍在等待 FTP 完成傳輸已更改的文件。 這可能意味著有人訪問了您的網站，但並非您的網站需要運行的所有文件都存在。
對於許多客戶來說，這不是問題，但如果是針對您的站點，那麼您需要考慮設置一個原子部署系統。 這種類型的部署系統會移動所有文件，驗證它們是否正常工作，然後更改服務器上的文件設置，以便新目錄現在是運行站點的目錄。
鏈接到新文件夾的過程需要很短的時間，只有計算機會注意到。 這也意味著如果您以後發現問題，您可以將系統鏈接更改回網站的舊版本，以回滾到正常工作的版本。 這又只需要很短的時間並減少停機時間。
無論您選擇做什麼，立即停止使用 FTP 客戶端來部署您的客戶端文件。 每次部署文件沒有出錯時，Deploybot 每月的少量成本都會得到補償。