7大ci/cd工具
持续集成，持续交付和持续部署（CI / CD）在开发人员社区中已经存在了很多年。 一些组织已将其业务同行纳入其中，但许多组织没有。 对于大多数组织而言，他们的运营团队必须像开发同胞一样熟悉CI / CD工具和实践。
CI / CD惯例同样适用于基础结构和第三方应用程序以及内部开发的应用程序。 同样，有许多不同的工具，但是都使用相似的模型。 也许最重要的是，领导您的公司采取这种新做法将使您在公司中处于有利位置，并且您将成为其他人效仿的灯塔。
几年来，一些组织已经在基础架构上使用CI / CD实践，并使用了诸如Ansible ， Chef或Puppet之类的工具。 其他工具（例如Test Kitchen ）允许在最终将承载应用程序的基础结构上执行测试。 实际上，这些测试甚至可以将应用程序部署到类似生产的环境中，并在更高级的配置中对具有生产负载的应用程序执行测试。 但是，仅达到能够单独测试基础结构的地步是一项巨大的壮举。 Terraform还可以使用Test Kitchen进行比某些原始配置管理工具更多的临时性和幂等基础结构配置。 加上Linux容器和Kubernetes，您现在可以使用类似prod的规范和资源来测试完整的基础架构和应用程序部署，这些规范和资源可以在数小时而不是数月或数年内出现。 在部署和再次测试之前，所有内容都会被清除。
但是，您也可以专注于将网络配置或数据库数据定义语言（DDL）文件纳入版本控制，并开始在它们上运行小型CI / CD管道。 也许它只是检查语法或语义或一些最佳实践。 实际上，这就是大多数开发管道的开始方式。 一旦将脚手架放下，将更容易构建。 一旦开始，您将开始为管道找到各种用例。
例如，我定期在公司内部编写新闻通讯，并使用MJML在版本控制中对其进行维护 。 我需要能够托管网络版本，有些人喜欢能够获取PDF，因此我建立了管道 。 现在，当我创建一个新的通讯时，我将其提交给GitLab中的合并请求。 这将自动创建一个index.html，其中包含指向新闻通讯HTML和PDF版本的链接。 HTML和PDF文件也在管道中创建。 除非有人来审查这些工件，否则这些都不会发布。 然后，GitLab Pages发布了网站，我可以拉下HTML作为时事通讯发送。 将来，合并请求合并后或经过特殊的批准步骤后，我会自动发送新闻稿。 这看起来很简单，但是它节省了我很多时间。 这实际上是这些工具可以为您提供服务的核心。 他们将节省您的时间。
关键是创建可以抽象使用的工具，以便它们几乎无需更改即可应用于多个问题。 我还应该注意，我创建的内容几乎不需要任何代码，只有一些简单HTML模板 ，一些要遍历HTML文件的 节点以及一些要用所有HTML页面和PDF填充索引页面的节点 。
其中一些可能看起来有些复杂，但是其中大部分是我使用的不同工具的教程中的。 许多开发人员很高兴与您合作处理这类事情，因为他们可能会在完成时发现它们很有用。 我提供的链接是我们计划为DevOps KC启动的新闻通讯，所有用于创建该网站的代码都来自我在内部新闻通讯中所做的工作。
下面列出的许多工具都可以提供这种类型的交互，但是有些工具提供的模型稍有不同。 在这个领域中出现的模型是对诸如YAML之类的管道的声明性描述，每个阶段都是短暂的和幂等的。 这些系统中的许多系统还通过在管道的不同阶段上创建有向无环图 （DAG）来确保正确的排序。
这些阶段通常在Linux容器中运行，并且可以执行在容器中可以执行的任何操作。 有些工具（例如Spinnaker ）仅专注于部署组件，并提供一些通常不包含的操作功能。 Jenkins通常将管道保持为XML格式，并且大多数交互都发生在GUI内，但是最近的实现使用了Groovy来使用领域特定语言 （DSL）。 此外，Jenkins作业通常在安装了特殊Java代理的节点上执行，并且由插件和预安装的组件组成。
詹金斯（Jenkins）在其工具中引入了管道，但是使用起来有些挑战，并且包含一些警告。 最近，詹金斯（Jenkins）的创建者决定将社区推动到几个不同的计划，这些计划有望为该项目注入新的活力-这是真正将CI / CD引入大众的计划。 我认为它最有趣的举措是创建一个Cloud Native Jenkins，它可以将Kubernetes集群变成Jenkins CI / CD平台。
当您了解有关这些工具的更多信息并开始将这些实践引入您的公司或运营部门时，您将Swift获得关注者。 您将提高自己以及其他人的生产率。 我们都有很多积压的积压工作—如果您能给他们足够的时间开始解决积压工作，您的同事会爱多少？ 不仅如此，您的客户还将开始看到应用程序可靠性的提高，而您的管理层将您视为力量的倍增器。 在您下次的薪资谈判或面试所有新技能时，这肯定不会受到伤害。
让我们进一步研究这些工具。 我们将简要介绍每个内容，并共享指向更多信息的链接。
亚搏体育app CI
GitLab在CI / CD领域是一个相当新的进入者，但它已经在Forrester Wave持续集成工具浪潮中名列前茅。 在如此拥挤且高素质的领域，这是巨大的成就。 是什么让GitLab CI如此出色？ 它使用YAML文件来描述整个管道。 它还具有称为Auto DevOps的功能，该功能允许较简单的项目使用内置的多个测试自动构建管道。 该系统使用Herokuish buildpacks确定语言以及如何构建应用程序。 某些语言还可以管理数据库，这是真正的游戏规则改变者，用于构建新应用程序并将其从开发过程的开始就部署到生产环境中。 该系统具有与Kubernetes的本机集成，并且将使用几种不同的部署方法之一（例如基于百分比的部署和蓝绿色部署）将您的应用程序自动部署到Kubernetes集群中。
除了CI功能外，GitLab还提供许多补充功能，例如通过与您的应用程序一起自动部署的Prometheus进行操作和监视。 使用GitLab Issues，Epics和Milestones进行项目组合和项目管理； 将安全检查内置到管道中，并在多个项目中汇总提供结果； 以及能够使用WebIDE在GitLab中直接编辑代码的功能，该功能甚至可以提供预览或执行管道的一部分以实现更快的反馈。
光盘
GoCD来自Thoughtworks的才智，足以证明其功能和效率。 对我而言，GoCD与其他产品的主要区别在于其价值流图 （VSM）功能。 实际上，管道可以与一个管道链接在一起，为下一个管道提供“材料”。 这样可以提高部署过程中职责不同的不同团队的独立性。 在打算将这些团队分开的较旧组织中引入这种系统时，这可能是一个有用的功能-但是让每个人都使用相同的工具将使以后更容易发现VSM中的瓶颈并重组团队或开展工作以提高效率。
为公司中的每个产品都配备VSM是非常宝贵的。 GoCD允许在版本控制中以JSON或YAML对此进行描述，并在等待时间附近以可视方式显示所有数据，从而使该工具对于试图更好地了解自身的组织而言更有价值。 首先安装GoCD，然后仅使用手动批准门来规划您的过程。 然后，让每个团队使用手动批准，以便您可以开始收集可能存在瓶颈的数据。
特拉维斯CI
Travis CI是我第一次使用软件即服务（SaaS）CI系统，它非常棒。 管道与您的源代码一起存储为YAML，并且与GitHub等工具无缝集成。 我不记得上次由于Travis CI或集成而导致管道失败— Travis CI的正常运行时间非常长。 它不仅可以用作SaaS，而且还具有可以托管的版本。 我没有运行那个版本-有很多组件，安装所有组件看起来有些艰巨。 我猜测使用Travis CI提供的Helm图表将所有内容部署到Kubernetes会容易得多。 这些图表还没有部署所有内容，但是我敢肯定，将来它还会增长。 如果您不想处理麻烦，也可以使用企业版。
但是，如果您正在开发开源代码，则可以免费使用Traas CI的SaaS版本。 这是一个很棒的团队提供的很棒的服务！ 这减轻了很多开销，并允许您使用相当通用的平台来开发开源代码，而无需运行任何程序。
詹金斯
詹金斯（Jenkins）是CI / CD中原始的，古老的事实标准。 如果您还没有，请阅读Jenkins的创建者兼CloudBees的首席技术官Kohsuke撰写的“ Jenkins：变速齿轮 ”。 总结了我过去十年对詹金斯和社区的所有感受。 他描述的东西已经需要几年了，我很高兴CloudBees率先进行了这种转变。 对于大多数非开发人员来说，Jenkins会有些不知所措，并且长期以来一直是其管理员的负担。 但是，这些是他们旨在解决的问题。
Jenkins的代码配置 （JCasC）应该有助于解决困扰管理员多年的复杂配置问题。 与其他CI / CD系统类似，这将允许通过YAML文件对Jenkins母版进行零接触配置。 Jenkins Evergreen旨在通过提供基于不同用例的预定义Jenkins配置来使此过程变得更加容易。 这些发行版应该比普通的Jenkins发行版更易于维护和升级。
Jenkins 2引入了具有两种类型的管道的本机管道功能， 我将在LISA17演示中进行讨论 。 当您执行简单的操作时，它们都不比YAML易于导航，但是它们对于执行更复杂的任务非常有用。
Jenkins X是Jenkins的完整转变，很可能是Cloud Native Jenkins的实现（或者至少是大多数用户在使用Cloud Native Jenkins时看到的东西）。 它将使用JCasC和Evergreen并在Kubernetes上以其最佳本机使用它们。 对于詹金斯来说，这是激动人心的时刻，我期待它在这一领域的创新和持续的领导地位。
大堂CI
我是Pivotal Labs的早期Beta版本版本，最初是由Pivotal Labs的人们介绍的-当时没有很多工具可以使用。 该系统由微服务组成，每个作业都在一个容器中运行。 其他工具没有的最有用的功能之一就是能够通过本地更改从本地系统运行作业。 这意味着您可以在本地进行开发（假设您已连接到Concourse服务器）并像在实际构建管道中运行构建一样运行构建。 另外，您可以从本地系统重新运行失败的构建，并注入特定的更改以测试您的修复程序。
Concourse还具有一个简单的扩展系统，该系统依赖于资源的基本概念。 基本上，您要提供给管道的每个新功能都可以在Docker映像中实现，并作为新资源类型包含在您的配置中。 这样可以将所有功能封装在一个不变的工件中，该工件可以独立升级和修改，而重大更改不一定必须同时破坏所有构建。
大三角帆
Spinnaker来自Netflix，更专注于持续部署，而不是持续集成。 它可以与Travis和Jenkins等其他工具集成，以启动测试和部署管道。 它还与Prometheus和Datadog等监视工具集成在一起，可以根据这些系统提供的度量标准做出有关部署的决策。 例如，金丝雀部署使用判断概念和收集的指标来确定最新的金丝雀部署是否已导致相关指标的任何下降，应该回滚还是部署可以继续。
与部署相关的几个其他独特功能涵盖了一个在讨论连续部署时经常被忽视的领域，甚至看起来是对立的，但对成功至关重要：Spinnaker有助于使连续部署的连续性降低一些。 这将阻止某个阶段在某些时间运行，以防止在应用程序生命周期的关键时间内发生部署。 它还可以强制执行手动批准，以确保在业务将从变更中获得最大利益时发布版本。 实际上，持续集成和持续部署的重点是准备好根据业务需求的变化尽快部署更改。
螺丝刀
螺丝刀是一项非常简单的工程。 它使用微服务方法，并依靠Nomad，Kubernetes和Docker等工具充当其执行引擎。 有一个很好的部署教程 ，可以将其部署到AWS和Kubernetes，但是一旦完成正在进行的Helm图表 ，就可以对其进行改进。
螺丝刀还使用YAML进行管道描述，并包含许多合理的默认值，因此每个管道的样板配置更少。 该配置描述了一个高级工作流程，该工作流程在作业之间可能具有复杂的依赖性。 例如，可以保证一个作业在另一个作业之后或之前运行。 作业可以并行运行，然后再加入。 您还可以使用逻辑运算符来运行作业，例如，如果其依赖关系中的任何一个成功，或者仅当所有成功时，才运行。 更好的是，您可以指定要从拉取请求中触发的某些作业。 另外，发生这种情况时，依赖的作业将不会运行，这使得您可以轻松隔离管道，以便何时应将工件投入生产以及何时仍需要对其进行检查。
这只是对这些CI / CD工具的简要说明-每个工具都具有您可以研究的更酷的功能和优势。 它们都是开源的，可以免费使用，因此请对其进行部署，看看哪种最适合您的需求。
接下来要读什么
翻译自: https://opensource.com/article/18/12/cicd-tools-sysadmins
7大ci/cd工具
1506
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
