持續部署是一種策略，其中對存儲倉主分支(通常是“master”或“main”分支)中代碼的每次更改都會自動發布到生產服務器上。

提醒

• 請注意，實施持續部署項目需要對應用程序進行徹底的測試，并擁有一支經過適當培訓且具有DevOps概念的團隊。

持續部署

持續部署的基本要求是版本控制。要開始您的部署，您需要在Buddy中創建一個項目并將其連接到您要部署的存儲倉。 您可以選擇 GitHub、Buddy Git存儲倉、Bitbucket、GitLab，以及任何自定義/私有Git存儲倉。

一旦項目同步后，您可以添加交付流水線。為了以連續的方式部署，將觸發模式設置為"事件"(自動推送觸發)，并確保Git推送“觸發事件” 指向生產分支(例如：master)：

信息

• 流水線也可以手動觸發并使用通配分配給多個分支。

添加流水線后就該進行測試和部署了，Buddy中的流水線由運行特定任務操作構成。例如，下面的流水線運行單元測試，使用ESLint執行靜態代碼分析，并使用Gulp構建資源。下一步是將文件上傳到SFTP服務器并將資源上傳到S3存儲桶。最后，Buddy將信息發送到Slack頻道表明新版本已部署：

信息

Buddy具有150多種可用于構建流水線的操作和集成：從構建和測試到部署、通知、腳本執行、網站監控、Android開發，再到Docker和Kube.NETes編排等等。

以下是一個從Node應用程序構建Docker鏡像的管道。然后測試鏡像，如果一切正常，將其推送到Docker注冊中心，然后將鏡像從該注冊中心部署到Kubernetes集群：

持續交付?

持續交付與持續部署有一點區別。 在這兩種方法中，更改都會自動測試，構建會自動執行，部署和發布都為自動化。

不同之處在于，盡管在持續交付測試中，構建和部署是自動運行，但必須手動審核才能發布到生產環境：

持續集成?

持續集成背后的想法非常簡單：所有更改都應與主分支合并并盡快進行測試。事實上，持續集成是持續部署的支柱 —— 如果軟件沒有經過適當的測試，那么自動化部署就毫無意義。

CI(持續集成)流水線應滿足三個關鍵條件：

1. 它應該在每次推送到存儲倉時自動運行
2. 它應該徹底測試每次代碼提交
3. 如果出現問題，它應該通知提交者或團隊