持续部署是一种策略，其中对存储仓主分支(通常是“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. 如果出现问题，它应该通知提交者或团队