持续集成、持续交付和持续部署(CI/CD)在开发者社区已存在了多年。一些企业设有运维部门，但许多企业没有。对于大多数企业而言，它们的运维团队要像开发团队那样熟悉CI/CD工具和实践。本文介绍了几款一流的开源持续集成、持续交付和持续部署工具。
持续集成、持续交付和持续部署(CI/CD)在开发者社区已存在了多年。一些企业设有运维部门，但许多企业没有。对于大多数企业而言，它们的运维团队要像开发团队那样熟悉CI/CD工具和实践。
CI/CD实践同样适用于基础架构和第三方应用程序以及内部开发的应用程序。此外，有许多不同的工具，但都使用类似的模式。可能最重要的是，引导贵公司采用这种新的实践将使你在公司内有很高的威信，你会成为别人跟随的领路人。
多年来，一些组织一直对基础架构采用CI/CD实践，使用Ansible、Chef或Puppet等工具。TestKitchen等其他工具可以在最终托管应用程序的基础架构上执行测试。事实上，那些测试甚至可以将应用程序部署到类似生产环境的环境中，针对更高级配置的生产负载执行应用程序级测试。然而，仅仅能够测试基础架构就很了不起。
与一些原始的配置管理工具相比，Terraform还可以使用TestKitchen测试更短暂更幂等的基础架构配置。加上Linux容器和Kubernetes，你现在可以使用类似生产环境的规范和资源来测试完整的基础架构和应用程序部署，这些规范和资源在数小时内而不是数月或数年内创建和停用。一切资源在再次部署和测试之前清除干净。
然而，你还可以专注于对网络配置或数据库数据定义语言(DDL)文件进行版本控制，开始在其上面运行小型CI/CD管道。也许它只是检查语法、语义或一些最佳实践。实际上，大多数开发管道开始就是这样。一旦你搭好了脚手架，就更容易在上面构建。一旦做好准备，你将开始为管道寻找各种用例(usecase)。
比如说，我经常在公司内部编写业务通讯，使用MJML在版本控制中维护。我需要能托管一个Web版本，有些人喜欢能够获得PDF，于是我构建了一条管道。现在当我创建新的业务通讯时，将它提交、进行GitLab中的合并请求。这自动创建一个index.html，附有指向业务通讯HTML版和PDF版的链接。HTML和PDF文件也在管道中创建。除非有人来查看这些内容，否则这些都不发布。然后，GitLabPages发布该网站，我可以下载HTML作为业务通讯来发送。将来，我会在合并请求合并时或特殊的审批步骤后自动发送业务通讯。这看起来很简单，但为我节省了很多时间。这正是这些工具的精髓：它们可以为你节省时间。
关键是创建抽象工作的工具，以便它们几乎没有变化即可应用于多个问题。我还应该指出，我创建的东西几乎不需要编写代码，只需要几个简单的HTML模板、循环处理HTML文件的某个节点，以及往索引页面填充所有HTML页面和PDF的另一个节点。
其中一些可能看起来有点复杂，但大部分来自我所使用的不同工具的教程。而许多开发人员乐意在这些类型的工作上与你合作，因为他们可能在完成后也觉得很有用。本文所附的链接指向我们计划为DevOpsKC开办的业务通讯，创建网站的所有代码都来自我在搞内部业务通讯时所做的工作。
下面介绍的许多工具都能提供这种类型的交互，但一些提供的模式略有不同。这个领域的新兴模式是用YAML之类的标记性语言对管道进行声明性描述，每个阶段是短暂幂等的。许多这些系统还通过在管道的不同阶段创建有向无环图(DAG)来确保正确的顺序。
这些阶段通常在Linux容器中运行，可以在容器中执行任何操作。某些工具(如Spinnaker)仅
转载请注明：http://www.0431gb208.com/sjszjzl/8282.html
