提升您的 DevOps 能力！立即掌握使用 FOSS 工具实现 CI/CD 的基础知识！

DevOps 领域最热门的话题之一是持续集成和持续部署 (CI/CD)。这种关注吸引了大量投资，并且在 CI/CD 领域创建了大量专有的软件即服务 (SaaS) 工具，而传统上该领域一直由免费开源软件 (FOSS) 工具主导。考虑到许多 SaaS 选项的低成本，FOSS 仍然是正确的选择吗？

这取决于情况。在许多情况下，自行托管这些 FOSS 工具的成本将高于使用非 FOSS SaaS 选项的成本。然而，即使在今天以云为中心且 SaaS 饱和的世界中，您也可能有充分的理由自行托管 FOSS。无论原因是什么，都不要忘记，在保持服务 24/7/365 可靠运行方面，“免费”并非真正免费。如果您将 FOSS 视为一种省钱的方法，请务必考虑这些成本。

即使考虑到这些成本，FOSS 仍然提供了很多价值，特别是对于正在迈出 DevOps 和 CI/CD 第一步的中小型组织。从商业化的 FOSS 产品开始是一个很好的折衷方案。它为深入了解更高级的专有功能提供了平滑的增长路径，让您只需在需要时才为这些功能付费。这种方法通常被称为“开放核心”，虽然并非普遍受欢迎，但如果应用得当，它可以为所有参与者创造很多价值。

DevOps 概念在过去几年中爆发式增长。这个术语迅速渗透到主流科技行业。随着这种思维的普及，可用于完成 DevOps 相关任务的工具数量也相应增加。对于 DevOps 从业者来说，这既是福音也是诅咒。由于有无穷无尽的选择，您肯定能找到满足您需求的东西，但对于新手来说，如此多的选择令人眼花缭乱。再加上 DevOps 范畴下的任务范围广泛，以及各方对“最佳”的激烈争夺，这简直是让人瘫痪的节奏。寻找工具并按各种标准进行筛选的一个好地方是 DevOpsBookmarks.com。所有内容都是开源的，维护者也勤于合并贡献，但最近更新不多。尽管如此，它仍然是一个很好的起点。如果您发现任何值得注意且应包含的内容，我们将不胜感激您的拉取请求！

在与客户或同行讨论 DevOps 概念时，将事物分解为“通道”很有用，这有助于简化对话，并为定义任务的归属或工具的应用方式提供粗略的边界。在最高层面，您有“基础设施”、“代码”和“可见性”通道。CI/CD 主要在代码通道中，其中一些部分进入基础设施和可见性。CI/CD 的主题分解为“源代码管理”、“构建/打包/部署自动化”和“测试自动化”通道。

大多数组织将其 DevOps 之旅的重点放在 CI/CD 上，因为它具有最大的感知投资回报率，并且与“更快地发布优质代码”的目标最相关。总的来说，他们是对的，但他们忽视其他通道的风险自负。一些组织投入数十万美元来实施 CI/CD 工具和流程，但最终整个努力因基础设施通道的缺陷而受阻。更糟糕的是，历时数月的部署和培训项目毫无成果，因为没有人费心确保工具真正被使用。这就是关注您的可见性通道发挥作用的地方。在进行 DevOps 时，重要的是衡量和报告尽可能多的与您的目标相关的指标。流程和工具采用指标至关重要。

CI/CD 旨在缩短从代码更改到部署和使用之间的时间。许多 CI/CD 之路上的圣杯是，将从提交到生产的时间缩短到几分钟，而无需在此过程中进行人工干预。为此，采用了多种类型的自动化来测试、构建、打包和部署代码更改。但要真正实现这一目标，您的应用程序架构必须能够适应这种潜在的变化率。

微服务和无服务器架构是两种可以很好地处理它的设计模式，但如果您的应用程序是单一的单体服务，那么如果不首先更改该设计或拥有非常成熟的测试自动化，您很可能无法实现这一目标。不过，即使在最成熟的组织中，有时您实际上可能也不想在更改发生后立即部署。因此，有些人喜欢区分“交付”和“部署”，将该过程称为“CI/CD/CD”。

在采用 DevOps 实践时，工具是容易的部分。这并不是说选择和实施它们在客观上是“容易的”，只是说它比确保组织的文化和流程支持 DevOps 实践的配套任务容易得多。在选择工具时，很容易陷入对“正确”做事方式的担忧中。他们说“如果您没有单元测试，那您就做得不对！”，或者“如果您没有在代码中定义您的基础设施，那您就做得不对！”

在您的组织建立相当成熟的 DevOps 文化之前，不要过分担心“正确”。专注于能够为您带来最短价值时间并为您的开发人员和运维人员提供最佳生活质量改进的工具和实践。编写和维护单元测试需要付出巨大的努力，而它提供的价值通常在遥远的未来。如果您只有几台服务器部署在简单的负载均衡器后面，并且这种情况不太可能很快改变，那么自动化您的基础设施可能不会带来回报。一开始就争取最快的胜利。没有什么比成功更能鼓励支持。只需确保您计划回来填补这些空白。随着您的组织成熟，它们变得越来越重要。不要让完美妨碍更好。

最大的回报通常在于自动化构建和部署，因此这是大多数人开始的最佳位置。这些是在您迭代开发过程时需要一遍又一遍完成的任务，通常每天多次。这些任务的痛苦越早减少到接近于零，每个人都会越高兴。这是 CI/CD 管道的核心。

存在许多源代码管理 (SCM) 系统。Mercurial、Microsoft Team Foundation Server 和 Perforce 都是想到的例子。然而，Git 已成为事实上的标准 SCM，而 GitHub 是人们在其之上使用的主要管理层。但是，GitHub 不是 FOSS，因此让我们转向其 достойный 竞争对手 GitLab CE，也称为 GitLab Core。

GitLab 成熟和添加功能的速度令人震惊。GitLab 根据开放核心模型获得许可，这意味着其中许多功能仅存在于其商业产品中，这很遗憾，但也是可以理解的。FOSS 产品仍然足够强大，非常引人注目。作为 Git 管理工具，它接近 GitHub 的功能对等性，甚至通过提供一套额外的 DevOps 支持功能（例如 CI/CD 编排、类似 Slack 的消息传递、工件存储库、紧密的 Kubernetes 集成，甚至功能即服务 (FaaS) 或“无服务器”）超越了它。但对于 SCM，它提供了执行分支、审查、批准和合并代码更改等核心代码开发管理任务所需的一切，甚至更多。自托管和 GitLab 托管产品的各种版本的完整功能比较矩阵可在此处 获取。

存在其他 FOSS 选项，但 GitLab 可能是开始的地方，因为它成熟且功能齐全。我了解到的另一个非常不错的选项是 Gitea，它是用 Go 编写的 Git 的非常轻量级的实现，具有友好的管理界面。如果 GitLab 众所周知的庞大系统要求对您的用例来说太过分，那么它可能最有用。

这里才是真正见真章的地方，也是从事 CI/CD 任务的人员可能会花费大部分精力的地方。该领域最著名的工具恰好也是 FOSS，那就是 Jenkins。在很大程度上归功于其庞大的插件库，Jenkins 可以不仅仅是一个 CI/CD 工具。它真的是自动化编排的瑞士军刀。Jenkins 的可扩展性和灵活性怎么强调都不过分。事实上，它非常灵活，以至于 CloudBees 这家公司是 FOSS 项目的重要贡献者，将其用作其主要商业产品的基础。这些产品解决了 Jenkins FOSS 的一些缺点，使其对于非常大型的企业级部署更具吸引力。

最近，开始出现关于 Jenkins “不够现代化”和“太难管理”的抱怨，特别是与 CircleCI 或 Shippable 等非常专注的 SaaS 产品相比时。这些说法有一定道理。如果不迁移到 CloudBees，则 HA 不容易实现，大型 Jenkins 部署可能会变得笨拙，UI 已经过时，并且其老派 Java 根基时不时会显现出来。但是，通过运行 Blue Ocean 界面并在容器中运行较小的、以团队为中心的部署，可以缓解其中大部分问题。迁移到竞争对手的 SaaS 工具也会失去 Jenkins 作为通用自动化编排工具所带来的许多功能，而这些功能是这些选项无法很好地填补的角色。

GitLab 也出现在这个通道中。GitLab 于 2015 年首次引入 CI 功能，此后这些功能迅速成熟。它已成为该领域备受推崇的工具，如果您已经为源代码管理部署了 GitLab，那么它是一个特别容易的选择，因为 CI 工具已包含在其中。

该领域还有其他几个值得注意的工具，每个工具都有自己对 CI/CD 的独特理解以及一组不同的优缺点。一个特别有趣的是 Drone，因为它旨在成为“容器原生”的。它使用非常类似于 Docker Compose 的 YAML 定义管道，这应该使任何熟悉使用 Docker 进行本地开发的人都可以轻松上手。与上面的 Gitea 一样，它是用 Go 编写的，并且占用空间非常小，因此对于资源受限的环境来说是一个合适的选择。

测试自动化是真正 CI/CD 管道的基石；然而，这是一个非常复杂的主题。工具因应用程序编写的语言、应用程序本身的性质，甚至编写软件的团队或团队的组成而异。在 CI/CD 领域的所有问题中，这是最具挑战性的问题之一。不仅决定测试什么是一个挑战，而且确定如何最好地测试它也很困难。有单元测试、集成测试、功能测试、系统测试、验证测试、回归测试、黑盒测试、白盒测试、静态代码分析、动态代码分析，甚至开源许可证、合规性和安全分析。这个列表可以继续下去，将这个领域扩展为另一个看似无穷无尽的选择阵列。但最终，最好还是专注于回答“这段代码是否可以使用？”这个问题，然后提出您自己组织对“就绪”的定义。这将帮助您决定现在、以后甚至可能根本不需要进行哪些类型的测试。随着您在测试自动化道路上前进，您对“就绪”的定义可能会变得越来越严格，并且您将迭代地引入其他工具以满足不断发展的标准。最常见的自动化测试类别，单元测试、系统测试和功能测试，都是很好的起点。它们都有许多优秀的 FOSS 选项可用。

有数百种不同的单元测试框架可用，几乎每种在现实世界中得到应用的语言都有至少几个。在 Wikipedia 上有一个令人难以置信的框架列表。从那里开始搜索工具，或者在您选择的搜索引擎中搜索“$my_language 的单元测试”，然后选择一个似乎正在积极使用和开发的工具，以及一个可以与您打算使用的其他工具集成的工具。它们中的许多都是“xUnit”风格的，这是一种非常常见的单元测试模型。如果您选择其中一种类型，您的开发人员更有可能乐于为其编写测试，并且很有可能会在 JUnit 兼容的 XML 文件中创建结果报告。JUnit XML 报告是单元测试世界的通用语言，并且拥有该格式的报告使您想要记录结果的任何工具都更有可能解析该报告。

系统测试的定义并不那么严格。这里又是一个广阔的问题空间，有许多可能的解决方案，这些解决方案将受到您特定情况的很大影响。我首选的入门方法是相当可重复且广泛适用的。部署应用程序的一次性实例（通常在容器中），并使用 Gatling 或 Postman 等工具运行负载测试，以快速遍历应用程序的核心功能。如果这些测试失败，则很可能您的系统存在问题。Postman 本身不是 FOSS 工具，但对于大多数用途来说是免费的，并且 Postman 的人员发布了许多 FOSS 支持工具，并且通常似乎是优秀的 FOSS 社区成员。

还值得注意的是，系统测试通常被错误地称为“集成测试”。集成测试是传统上介于单元测试和系统测试之间的一个步骤，但在早期采用自动化测试实践时，应考虑跳过它，因为它通常只在非常复杂的软件中提供有形的价值，这些软件由非常大的团队编写或由来自多个独立团队的工作组成。

对于功能测试，杰出的 FOSS 工具是 Selenium，它是许多其他测试自动化工具（包括 FOSS 和商业工具）的核心。如果您的应用程序通过网页公开任何内容，则 Selenium 或类似工具应该在您的工具包中。

最后，如果您无法查看结果，那么世界上所有的测试都没有多大意义。Jenkins 本身可以显示测试结果，但运行 Sonarqube 会增加很多价值。它不仅让您清楚地了解您的测试结果随时间的变化情况，如果您使用的是受支持的语言，它还可以对您的代码执行各种静态分析。它是另一个获得开放核心许可的工具，最近一些非常有用的功能已转移到商业版本中——也许最值得注意的是轻松跟踪单个代码库的多个分支的能力。

可以使用上面列出的每个通道中的工具选择，并为有效的 CI/CD 管道提供框架。这里的选项只是可能的选择中的一小部分；但是，它们是经过验证可以交付价值的选项。最终，这才是重点：获得价值。最后，这才是 CI/CD 管道的用途，通过减少开发和部署过程中的摩擦，尽可能快速、顺畅地向您的用户交付价值。而这是拥抱 DevOps 的有效早期步骤。

• 被认为有害的开源商业模式
• DevOps 书签
• GitLab Core
• GitLab 功能矩阵
• Gitea
• Jenkins
• CloudBees
• Jenkins Blue Ocean
• Drone
• 单元测试框架列表 (Wikipedia)
• Gatling
• Postman
• 集成测试概述 (Wikipedia)
• Selenium
• Sonarqube

图片来源：Brian Ho，来自 Unsplash。