持续集成 ci/cd_CI / CD按您的方式：11种本地选项，用于持续集成和交付
持续集成 ci/cd
当团队一起开发软件时，对持续集成（CI）以及通常也持续交付（CD）的需求很少有人争论。 中央连续集成服务器通过在测试和重新测试之前不断构建和重建软件，像裁判员和质量控制经理一样工作。 CI服务器越早发现问题，便越早可以解决它们。
真正的争论在于，是自己托管连续集成过程，还是将工作分担到繁盛的基于云的CI / CD服务之一上。 让其他人来做这项工作总是很有吸引力，并且服务通常可以更快，因为它们共享一个强大的计算机池，这些计算机可以并行运行CI流程中的不同任务。
但是缺点可能很大。 如果您的团队特别担心对代码或数据的访问，那么将所有内容保存在锁定服务器室中的计算机上会带来温暖的感觉。 是的，这意味着您自己更新操作系统并应用补丁程序，但是有时这比双手合十并让别人相信会更好。
如果您的代码库很大，或者您生产的是装有二进制文件的大容器，那么在开放的Internet上移动这些位可能会很慢。 许多云爱好者倾向于忽略延迟问题和运送大数据块的成本。 如果您只是将它们推到大厅下的服务器机房，则可以建立一个快速的网络，以确保它们很快到达。 是的，这可能意味着您一天中的休息时间会减少，但是可以极大地缩短交货时间。
最大的优势之一可能是有机会向您的构建添加自定义。 云服务在以与其他所有人相同的方式配置标准代码块方面做得很好，并且它们尝试提供所有插件和选项，但是没有什么能比拥有对计算机的root访问权限更好的了。 毫无疑问，许多云选项的预配置管道节省了时间，但是当您开始走人为路线时，它们可能会受到限制。 随心所欲的能力使本地部署成为引人注目的选择。
这是在您的场所中构建持续集成服务的11种解决方案。
詹金斯
第一轮变革是Jenkins ，它是原始的持续集成工具，始于Sun Microsystems的Java开发人员。 Sun工程师足够聪明，不会将体系结构限制为Java代码，如今有成千上万个插件可以处理所有主要堆栈和大多数次要堆栈的许多琐事。 选择诸如Lisp之类的随机内容并找到有人为其编写插件的情况并不少见。 Jenkins用Java编写的事实意味着通常可以轻松下载JAR文件并在Windows，Mac或Linux机器上运行它。
詹金斯（Jenkins）项目继续吸引着更多的关注和重建。 Blue Ocean子项目旨在从浏览器的舒适性中配置和优化Jenkins管道成为可能。 配置文件的文本编辑更少，点击更多。
Jenkins团队一直在努力通过减少配置和更新工具所需的工作量来简化在任何地方运行CI服务器的过程。 Evergreen版本将通过Docker容器进行配置，构建和更新。 就像医生缝制自己腿上的子弹一样。
JetBrains TeamCity
培育IntelliJ IDE的同一家公司还提供TeamCity ，它是持续集成服务器与许多其他功能（例如代码质量指标）和讨论代码的论坛的结合。 JetBrains致力于通过将TeamCity与所有主要版本控制系统集成并创建大量支持不同语言的插件来最大程度地提高兼容性。 TeamCity的核心是Java，但是很容易使其与其他语言一起使用。
该代码可在多种本地计算机上运行。 当然，有一个Docker容器，一个Java JAR文件要在servlet容器中运行，但也有Windows .exe文件。 较为有趣的选项之一是“预测试的提交”，它不会在您的桌面上发生，但仍会在正式认为代码已提交之前，贯穿所有CI步骤。 更好的绰号可能是“两阶段提交”，但这听起来并不酷。
专业版被称为“永远免费”，具有所有功能，并且对用户或构建时间没有限制。 购买企业版的用户可以获得额外的构建代理以并行运行，并且这些代理可以分布在诸如AWS之类的公共云中。 它是一种混合解决方案，可让您在本地托管主服务器，但在需要额外电源时启动云计算机。
亚搏体育app CI / CD
许多团队在GitLab服务器上的云中使用GitLab ，但是堆栈是开源的，可以安装在您选择的服务器机房中的服务器上。 社区版可以从GitLab检出并直接构建，但是仅抓住机器的软件包安装程序并使其完成工作可能会更容易。 还有一个付费的企业版，具有更多功能。
用于GitLab的CI工作在很大程度上依赖Docker进行配置和测试，这比基本工具更快，更简单。 大部分工作由一个名为GitLab Runner的程序处理，该程序是一种用于执行流水线中各个阶段的自动缩放工具，可以安装在多台服务器中。 还有一个很好的功能，称为AutoDevOps ，它可以检查您的代码，记录标准make文件的存在，然后配置管道以构建，测试和部署软件。
整个GitLab堆栈不仅具有持续集成的功能。 它还提供版本控制和协作工具，用于计划，问题跟踪和代码审查，这是创建运行代码的所有重要部分。
Azure DevOps服务器
Microsoft一直在努力向希望或需要将Azure堆栈托管在自己的服务器上的任何人开放Azure堆栈，并且devops角也不例外。 最简单的解决方案是添加更多的构建代理以加快工作速度。 基本的Azure DevOps帐户带有免费的构建代理。 您可以通过向Microsoft付费（最简单的解决方案）来添加更多的代理，或者通过在自己的计算机上安装Mac OS， Linux和当然是Windows软件包的构建代理来添加更多代理。 您还可以使用Visual Studio等其他Microsoft产品获得额外的构建代理。
如果需要更多控制或隔离，则可以在计算机上安装完整Azure DevOps Server的第一个候选版本。 它与Azure SQL的本地版本一起使用以提供完整的程序包。
Oracle容器管道
以前的初创公司Wercker现在是Oracle的一部分，该公司用Oracle Container Pipeline的简单但非常有用的名称来称呼收购的CI / CD产品。 之所以有意义，是因为该工具专注于使用一系列充满任务的管道来构建，测试和部署Docker容器。 如果您可以将其拼写为Bash脚本，则可能是一项任务。
Linux和Mac都有安装版本，因此可以在台式机或服务器场中运行相同的YAML管道代码。 如果您需要使用云，那么，您将需要自己构建它。 Oracle按座位定价服务。
可运输服务器
Shippable的主要产品是云中的CI / CD ，但是如果您要安装自己的服务器，或者只是“带上自己的节点”，则可以使用Shippable Server 。 Shippable设计为混合动力。 您可以将所需的组件混合在一起，以提供代码所需的性能。
该工具提供了本机汇编流水线，可将代码转换为已部署的实例，并进行大量测试。 标准的构建和测试任务构成了该服务的基础，但是Shippable还包括与配置（例如Puppet或Chef）和用于测量正在运行的部署的性能并将其显示在可视仪表板中的仪表的大量集成，因此您可以按照以下说明进行操作。
阿特拉斯竹
Atlassian有两种不同的产品可以进行持续集成。 Bitbucket Pipelines已集成到Bitbucket云中，而Bamboo是可以下载并安装在自己的服务器上的软件。 两种产品的目的是分开的，而不是像此处的其他一些解决方案一样，将云和本地服务器混合在一起。 但是，如果您需要更多的构建能力，Bamboo与AWS集成在一起，就可以启动实例来处理一些琐事。
Bamboo是一种商业工具，比Jenkins具有更多的功能和更多的支持。 该产品附带一个转换工具，该工具会将内部配置文件移动到内部Bamboo格式。 Atlassian团队添加了许多智能功能，用于在您本地版本的Bitbucket或Stash上查看代码库，并检测何时可以完成合并以保持存储库更整洁。
大多数文档都集中在支持Java和.Net项目上。 尽管可以将工具用于所有类型的任务，但针对这两个世界进行了优化。 该产品免费提供30天。 之后的价格取决于用户数量和构建代理的数量。
无人驾驶飞机
如果您已经构建了可以在Docker容器中执行所有操作的代码，则可以使用Drone持续集成工具。 所有管道任务都在容器中执行，然后结果可以部署在容器中。 有一个活跃的市场，充满了用Bash shell脚本或Go编写的可处理所有标准杂事的插件。
您可以在云中运行Drone管道，也可以在服务器上安装软件。 尽管您可以使用大多数主要功能，但无人机版的开发人员版本每年最多可免费构建10,000个版本。 为企业版付费可以解锁无限的构建和选项，例如部署到多台计算机和主要的云提供商。
代码刷新
Codefresh自称为第一个为Kubernetes构建的持续集成平台。 构建是在容器中完成的，然后结果直接指向已配置的集群。 可以将容器缓存在本地存储库中，然后以Helm图表为指导进行部署。
标准定价和免费套餐均基于在Codefresh云中运行该工具。 如果要创建在服务器上运行的混合版本或封闭版本，则可以使用企业版本 。 您可以免费试用14天。
蛋糕
如果将C＃语言的名称与持续集成的旧版本结合起来，那么Make会得到Cake ，这是一个为C＃程序员设计的工具，他们也想用C＃编写其构建脚本。 无需摆弄其他语法。
Cake是开源的，它支持您喜欢使用的所有以Microsoft为中心的工具。 对于任何为.Net世界而开发的人来说，它可能是最简单的解决方案。
IDE和存储库
像Eclipse和IntelliJ这样的经典集成开发环境并不是每个人都认为是连续集成工具，但是某些开发人员能够在不维护单独系统的情况下，获得优质CI工具的大多数相同优点。 毕竟，如果您添加了正确的插件，那么IDE将在容器中检出，构建，测试甚至部署代码。 为什么要重复这项工作？
如果您不需要第三方扮演中立的裁判和质量控制代理的角色，那么避免使用额外的连续集成服务器可能是一个更好的选择。 如果您的团队在不太集成的代码上相当独立地工作，则将CI服务器保持在后台运行可能没有意义。 它只是复制您在开发计算机上已经进行过的相同构建和测试。
另一方面，如果团队成员接触的代码中有任何重叠，则CI服务器的额外工作将变得非常宝贵。 这是一个艰难的决定，但有时IDE的所有标准选项都可以提供足够的集成和交付功能。
翻译自: https://www.infoworld.com/article/3345968/cicd-your-way-11-on-prem-options-for-continuous-integration-and-delivery.html
持续集成 ci/cd