第 2 章：源代码管理
想象一下这样一个场景：你和你的团队正在协作一个复杂的软件项目。多位成员贡献智慧，进行修订和增强。如果没有清晰的系统来管理变更，你们可能会覆盖彼此的工作，并且无法追踪谁在何时做了什么更改，以及为何进行这些更改。如果没有清晰的系统来标记一系列变更，一旦出现问题，你将无法回溯到团队代码的某个稳定旧版本。如果没有明确的工作流和结构化的访问控制，任何人都可以随时更改任何内容，且缺乏监督。如果没有这些控制，当你需要重新构建某个特定版本时，团队将无法确定哪些代码文件被用于构建该版本。
接下来，再想象一下，几个团队已在一个新应用程序上工作了数月，现在即将部署到生产环境。各种开发和质量保证（QA）环境都进行了临时性修复和调整，但这些更改并未可靠地反映在生产环境中。重要的生产设置未在 QA 环境中重复，并且开发环境之间差异巨大。鉴于所需环境日益复杂，搭建新环境已成为一个耗时且容易出错的瓶颈，这会带来沮丧和延迟。
这些情况都是导致功能失调和精力浪费的根源。源代码管理（SCM）实践正是为了解决这些问题而创建的。SCM 的核心在于跟踪和管理代码以及配置等关键资源随时间推移所发生的变化。
如今，人工智能（AI）正在改变我们处理 SCM 的方式。AI 可以自动检测高风险更改、建议代码或配置改进，甚至通过理解修改背后的意图来帮助解决合并冲突。它能够识别跨环境的不一致性、推荐修正方案并优化部署工作流。AI 驱动的工具不仅帮助团队管理复杂性，还在赋能更快速、更安全、更具韧性的开发周期。随着软件交付变得更加分布式和动态，AI 正在成为使 SCM 更智能、更主动、更高效的重要伙伴。
源代码管理简介
在团队内部协调变更的问题可以追溯到编程的早期，SCM 实践的历史与计算机编程的演进紧密相连。在本节中，我们将探讨 SCM 如何演变以及 AI 工具在现代 SCM 中扮演的关键角色。
源代码管理简史
在编程早期，程序相对简单，受限于有限的硬件，代码管理也十分初级。随着 CPU 变得强大和复杂，计算和代码也变得更加复杂。代码仓库，即提供基本 SCM 功能的集中存储，最早出现在 20 世纪 70 年代，与高级语言和结构化编程方法的兴起同步。像 Source Code Control System (SCCS) 这样的工具提供了基本的版本跟踪功能，允许开发人员回滚到以前的版本并查看变更历史。这些早期系统反映了向更有组织性的程序开发转变的趋势。
20 世纪 70 年代，随着更结构化的软件工程团队的出现，SCM 进一步发展。像 1982 年引入的 Revision Control System (RCS) 和 1986 年引入的 Concurrent Versions System (CVS) 等工具增加了对协作至关重要的功能，包括分支。这使得更复杂的项目管理和协作文化成为可能。
20 世纪 90 年代初，IBM Rational ClearCase 作为一种商业 SCM 解决方案出现。它强调强大的配置管理和流程定制，使其适用于复杂的软件开发环境。由 CollabNet 开发的 Subversion (SVN) 是另一个获得普及的集中式代码仓库。SVN 1.0 于 2004 年发布，旨在解决 CVS 的缺点并提供缺失的功能。
分布式版本控制与 Git
21 世纪初，敏捷方法论和开源的兴起对软件开发提出了新的要求。快速发布意味着团队需要对日益复杂的代码库拥有更大的灵活性和控制力。团队本身也发生了变化，变得更大且通常分散在不同地理位置。Git 由 Linux 内核的创建者 Linus Torvalds 于 2005 年创建。他需要一个强大而高效的系统来管理 Linux 项目的庞大代码库，而现有选项都无法满足要求。
版本控制系统 (VCS) 是跟踪文件随时间变化的核心技术，构成了任何 SCM 方法的基础。与大多数早期代码仓库不同，Git 是一个分布式 VCS。在集中式 VCS 中，每个人都从存储在中央服务器（仓库）中的代码库的单个副本进行工作。每个开发人员都有自己的本地副本（工作副本），他们可以修改它。当开发人员进行更改并提交时，这些更改会立即上传到中央仓库，使其对其他人可见。要查看其他人的最新更改，开发人员只需从中央仓库更新他们的本地副本即可。图 2-1 展示了一个集中式 VCS。
分布式系统采取了不同的方法。在这里，每个开发人员在自己的本地机器上都拥有代码库的完整副本（包括仓库和工作副本）。开发人员所做的更改只存在于他们的本地副本中，直到他们明确地与团队共享这些更改。这通过将更改“推送”到中央仓库来完成。同样，要查看其他开发人员所做的更新，用户需要从中央仓库下载（“fetch”）这些更改到他们的本地副本中。图 2-2 展示了一个 Git 分布式 VCS。
Git 对速度的专注、其分布式特性以及强大的分支功能使其在许多方面成为颠覆性的创新：
分布式促进离线工作
Git 的去中心化方法促进了高效和独立的工作，因为开发人员可以在没有中央服务器的情况下在本地进行更改。这也使得开发人员能够离线工作。
灵活的分支与合并
Git 的分支系统非常灵活。开发人员可以创建隔离的分支来开发新功能或修复错误，而不会影响主代码库。将这些分支合并回主代码库是一个流畅高效的过程。这使得开发人员能够更自由地进行实验和迭代。
轻量且高效，适用于大型代码库
Git 擅长高效处理大型代码库。它只存储代码版本之间的差异，这使得它比传统的 SCM 系统更快，并且所需的存储空间更少。
非线性历史有助于组织
与某些强制执行线性历史的 SCM 系统不同，Git 允许开发人员通过诸如变基（rebasing）之类的功能来重写历史。这种灵活性有助于维护一个干净整洁的代码库。
首批广泛使用的 Git 托管仓库在几年后出现。GitHub，如今最受欢迎的平台，于 2008 年推出。这些平台建立在 Git 的强大功能之上，提供了用户友好的网页界面、代码库的云存储和协作功能。这种结合将 Git 从一个强大但技术性的工具转变为一个可访问且社交化的软件开发平台，使其成为现代软件开发工作流的基石。
尽管传统的集中式仓库仍有其历史足迹，并用于具有非常特定需求的环境中，但 Git 现在是主要选择。Stack Overflow 2022 年的一项调查发现，94% 的受访者使用了 Git，而使用任何源代码控制的人中有 98% 使用 Git。因此，我们将重点关注 Git 仓库的变体。
Git 分支扩展
2010 年，Gitflow 分支约定出现，它利用分支为开发、功能创建和发布准备提供了清晰的分离。图 2-3 展示了一个 Gitflow 工作流。
在 Gitflow 工作流中：
- 主代码库位于名为“main”的分支上。此分支通常被认为是稳定的，并且只应包含生产就绪的代码。
- 创建一个新的“develop”分支，它作为所有开发工作的持续集成（CI）分支。
- 功能开发发生在从 develop 分支派生出的隔离分支（feature/release 分支）上。开发人员在这些功能分支上开发新功能和修复错误。一旦功能完成并经过彻底测试，它就会合并回 develop 分支。
- develop 分支充当所有已完成功能的集成点。它代表即将发布的版本，并不断通过合并的功能分支进行更新。
- 当需要发布时，会从“develop”创建一个发布分支。此分支上可以进行错误修复和微小调整。一旦最终确定，发布分支会合并回“main”以创建官方发布。同时在“main”中创建一个相应的标签来标记发布版本。
拉取请求（Pull Request，有时缩写为 PR）是 Git 版本控制中用于代码审查和集成的一项核心协作功能，并广泛用于 Gitflow 和其他分支模型。拉取请求为开发人员提供了一种结构化的方式来提议更改代码库，并在将其合并到主分支之前获得其他人的审查。
Gitflow 强调计划发布和独立的发布分支，这受到了新的 Git 分支模型的挑战。受持续集成和持续交付日益普及的推动，这些模型优先考虑更快的部署和更频繁的更新。主干开发（Trunk-based development）完全摒弃了专用开发分支的概念。相反，功能在经过严格测试后会持续直接集成到主分支（通常称为“trunk”或“main”）中。图 2-4 展示了这种模式。
这种简化的方法允许更快的反馈循环和更快的部署，与现代 DevOps 实践非常吻合。拉取请求在这些工作流中仍然至关重要，通过代码审查确保代码质量，然后再将更改合并到主分支。
GitOps 与源代码管理
我们已经看到代码仓库如何与编程和软件开发实践共同演进，解决了我们所设想的问题，使团队能够有效地协作源代码。但是部署问题呢？我们如何高效、系统地生产所需的环境，又如何简化代码到生产环境的部署？
这就是 GitOps 的用武之地。DevOps 将开发（Dev）和运维（Ops）结合起来，强调自动化在消除人为错误和确保环境一致性方面的重要性。这转化为更快的部署、更高的可靠性和更低的风险。GitOps 是指自动化配置基础设施的过程，尤其是在现代容器优先的云基础设施中。GitOps 强调使用代码仓库（通常是 Git）作为系统所需状态的单一事实来源，并利用自动化持续协调实际状态与所需状态。存储到我们仓库的资源可以包括：
基础设施配置
定义环境所需组件的文件、虚拟机（VM）的类型和数量、存储配置、网络设置和安全策略。这可以包括声明式和命令式配置以及部署脚本。
环境变量
这些对于存储不应直接嵌入代码中的敏感信息（如密码或 API 密钥）至关重要。基础设施即代码（IaC）工具通常具有安全管理和引用环境变量的机制。
额外资源
根据环境的复杂性，仓库还可能存储其他资源，例如用于应用程序部署的容器镜像（通过 git-lfs）。
利用我们的仓库作为单一事实来源，我们可以利用其强大的功能。我们获得详细的版本跟踪和变更历史记录，并且可以通过 Git 工作流来管理基础设施更新，这些工作流通过拉取请求（Pull Request）等方式促进协作和监督。管理良好的基础设施自动化意味着更快的部署、更少的错误以及每次需要创建新环境时都具有可靠的环境。我们将在第 4 章中了解更多关于使用 GitOps 进行部署的内容。
单体仓库与远程缓存
我们在第 1 章中提到了微服务的重要性。两种提高基于微服务系统生产力的关键实践是使用单体仓库（monorepos）和远程缓存。
单体仓库（monorepo）是一个单一版本控制的代码仓库，用于存储多个项目或服务的代码。在微服务背景下，这种方法简化了协作，简化了依赖管理，实现了跨服务的原子性更新，并减少了版本冲突。
远程缓存是指将构建产物（如编译后的代码或测试结果）存储在远程服务器上。像 Nx 这样的工具使用此技术显著加快开发工作流，允许团队重用以前生成的输出，而不是从头开始重建，从而减少冗余计算。
单体仓库和远程缓存共同支持更快、更高效的 CI/CD 流水线，并有助于提高整体系统性能。然而，随着项目规模的扩大，单体仓库可能会引入复杂性，并且如果未深思熟虑地实施，远程缓存可能会引发厂商锁定（vendor lock-in）的担忧。
AI 在源代码管理中的应用
AI 工具彻底改变了开发人员的编码方式。GitHub Copilot、Cursor、Harness AI Code Agent 等编码助手/代理充当智能结对程序员，根据项目上下文提供实时代码建议。这些工具可以预测并建议整个代码行或代码块，显著加快开发过程。
除了代码补全，AI 助手还可以：
- 自动生成样板代码结构
- 建议不同的实现方法
- 提供代码解释和文档
- 协助调试和优化
AI 原生软件交付始于 AI 原生 SCM。AI 与 SCM 的集成超越了代码补全。在 SCM 内部，AI 可以分析仓库模式，在代码到达生产环境之前识别潜在的错误，并根据在类似项目中观察到的最佳实践提出架构改进建议。这种前瞻性方法显著减少了技术债并从开发的早期阶段提高了代码质量。我们将在本章稍后探讨其中一些主题。
在接下来的几节中，我们将介绍 SCM 系统如何适应交付流水线。在此理解的基础上，我们将讨论在选择适合团队的 SCM 时需要考虑的因素。最后，我们将探讨现代代码仓库的特点，包括 AI 的作用，这些特点可以简化你的整个软件开发流水线。
源代码管理在交付流水线中的作用
核心代码仓库是交付流水线中的关键组成部分，它锚定了整个流水线过程。它作为代码的单一事实来源，确保一致性和可靠性，并且是开发人员持续交互、启动集成和交付活动的实体。
图 2-5 描绘了代码仓库与持续集成和交付的关系。
让我们来看看典型流水线的三个主要部分：
代码仓库
开发人员对代码仓库进行操作，提交更改并打开和关闭拉取请求。
持续集成
持续集成由代码仓库内的特定操作触发。这些触发器可以自定义，包括代码提交、拉取请求的打开或关闭，或团队根据其特定需求和实践确定的其他相关操作。CI 为开发人员提供关于代码更改的快速反馈。通过自动化构建和测试，CI 充当早期预警系统，提醒开发人员潜在的错误、集成问题，甚至代码风格违规。这种即时反馈使开发人员能够迅速解决问题，防止它们演变成更大、更昂贵的后续问题。有了 CI，你的代码库将保持在持续可部署的状态，为交付流水线中的下一步做好准备。
持续交付与部署
持续交付和部署步骤自动化了基础设施的配置以及新代码版本到一个或多个预生产环境的部署。通常会针对在预生产环境中运行的应用程序执行各种类型的测试。我们将在第 4 章中讨论这些步骤。最后，自动或手动决策会控制软件到生产环境的最终部署。我们将在第 8 章中详细讨论这些步骤。通过频繁部署更小的更改，CD 简化了交付过程，降低了发布风险，并增强了快速响应用户反馈的能力。
许多代码仓库内置了敏感信息检测功能。敏感信息可以包括以下内容：
API 密钥
用于验证和授权访问各种 Web 服务和 API 的唯一标识符
访问令牌
授予应用程序或资源特定访问权限的临时凭据
OAuth 令牌
用于委托授权的令牌，允许一个应用程序代表用户访问资源
私钥
在非对称加密中用于解密消息或验证数字签名的密钥
用户名和密码
用于系统和服务基本身份验证的凭据
数据库连接字符串
建立与数据库连接所需的详细信息，通常包括主机名、用户名和密码等敏感信息
云服务连接字符串
用于连接到 Azure Storage 或 AWS S3 等云服务的字符串，可能包含访问密钥和其他敏感信息
某些代码仓库会在开发人员尝试提交或合并包含检测到的敏感信息的代码时阻止或警告。CI 过程可以在敏感信息检测中发挥作用，阻止它们到达生产环境。理想的方法是同时利用两者以实现全面的安全性。
代码仓库考量
鉴于 SCM 对软件开发的重要性，选择代码仓库是团队将做出的首批决定之一。“我们将把源代码放在哪里？”是团队在启动项目之前就需要回答的问题。
首先，一个代码仓库必须支持对其团队至关重要的基本操作和开发人员工作流：
- 支持分布式离线工作的仓库创建、导入和克隆
- 分支、合并以及定义满足团队特定需求的分支规则（例如，限制特定用户创建/删除分支）
- 创建、审查和合并拉取请求，以及根据团队所需的治理定义拉取请求策略（例如，要求所有更改都与拉取请求相关联、禁止直接提交或设置所需审阅者批准的最小数量）
- 创建和修改标签，并定义标签策略（例如，强制标签名称遵守特定的模式，如语义化版本控制）
虽然实现细节可能有所不同，但这些都是预期的仓库功能。
在创建交付流水线时，团队通常首先选择仓库；因为这是一个可能对实现产生深远影响的选择，所以确保你的代码仓库能够无缝集成到更广泛的生态系统中至关重要。你的代码仓库应该在一个能够提高团队生产力而非增加工作量的生态系统中运作。此外，解决方案应该具有成本效益，并提供组织所需的透明度。
全面的集成
一个设计良好的 DevOps 生态系统的特点是易于使用的工具和与交付流水线所需的功能和服务的全面集成。这与零散的方法形成对比，在零散的方法中，开发人员需要手动集成许多不同的工具，这可能导致难以排查的问题和安全风险。它也与过于复杂的单一平台解决方案形成对比，这些解决方案通常存在功能冗余，难以配置。
配置即代码（configuration-as-code）是简化集成的一个例子。这种实践允许对交付流水线的更新直接在仓库中进行版本控制和跟踪，就像你的项目代码一样。你可以通过强制执行要求通过拉取请求和审批进行更改的工作流来进一步增强协作和治理，从而与标准开发实践保持一致。
另一个功能示例与安全/漏洞扫描有关。在拉取请求的上下文中显示检测到的漏洞和建议的修复有助于开发人员快速理解并解决任何检测到的问题。
AI 驱动的功能
过去几年，使用大型语言模型提高开发人员效率的编码助手或代理呈爆炸式增长。这些编码助手有助于代码自动补全、生成代码建议、理解代码功能以及许多其他用例。当 AI 助手与代码仓库集成以访问完整的代码库作为上下文——而不仅仅是孤立的代码片段——它们可以生成更准确和相关的建议。
MCP 在此发挥关键作用，它提供了一种通用的、标准化的方式来连接 AI 模型和代码助手与各种数据源，包括 Harness Code Repository、GitHub 和 Git 等仓库。这消除了对自定义集成的需求，减少了开发工作并提高了效率。
生成式 AI（GenAI）在代码仓库中的另一个强大应用是语义搜索——使用自然语言搜索整个代码库的能力。像 Sourcegraph 的 Cody 和 Harness Code Repository 这样的工具使开发人员能够提出诸如“身份验证是如何实现的？代码在哪里？”之类的问题，而不是依赖于基于关键字的搜索，如“登录”或“验证”。此功能对于新团队成员的入职特别有价值，可以帮助他们快速理解复杂的代码库，而无需深入了解项目特定的术语。
在代码审查方面，像 DeepCode 和 Codacy 这样的工具使用机器学习算法来审查代码更改，自动检测潜在的错误、代码异味以及对编码标准的遵守情况，比手动审查更高效。AI 在 SCM 中的其他用例还包括：通过在代码提交之前自动扫描漏洞和合规性问题来增强安全性，并推荐这些问题的修复方案；总结拉取请求；以及使用 SCM 作为数据源之一生成软件交付流水线。
需要注意的是，对于 AI 系统而言，结果在很大程度上取决于用于训练 AI 模型的数据。因此，例如，“好”的代码将带来好的代码建议和审查，而“坏”的代码将带来坏的代码建议和审查。
衡量 AI 的影响同样重要，以验证使用 AI 是否确实对开发人员产生了积极影响。Harness Software Engineering Insights 等工具可以帮助衡量使用不同编码助手的开发人员的生产力，并将其与不使用任何编码助手的开发人员进行比较。
AI 驱动的 SCM 通过生成快速可靠的代码（尤其是在训练良好的情况下）来加速上市时间，通过识别问题（包括安全漏洞）从源头提高代码质量，并通过提升代码审查的质量和效率来增强团队协作。
通过开源实现效率和透明度
你的 DevOps 工具是否开源是一个重要的考量。开源解决方案对于预算受限的组织来说可能具有成本效益，它们提供的透明度也具有优势。
专有解决方案通常可以声称提供可靠的正常运行时间和专门的客户支持团队来解决你遇到的任何技术问题。然而，企业用户通常需要支付订阅费，这对于小型团队来说可能是一个重要的成本因素。开源代码库可以免费使用，使其成为预算有限的团队的理想选择。开源性质允许透明度和社区驱动的开发。开发人员可以访问源代码，从而能够根据特定需求定制平台。但是，他们通常必须依靠社区进行故障排除和支持。虽然有价值，但开源可能无法提供与商业提供商相同水平的保证协助。此外，虽然开源促进了透明度，但也意味着潜在的漏洞是公开可见的。
像 Harness.io 和 GitLab 这样的开放核心（Open core）解决方案提供了一个中间地带。它们提供免费的、功能受限的版本，类似于开源。
最后，如果出于监管要求或为了确保业务连续性，可以将开源软件（OSS）托管（escrow）起来。这提供了保证，即在工具提供商倒闭的情况下，你仍然可以访问构建、测试和监控应用程序以及重新创建开发、测试和生产环境所需的工具。
平台化方法
传统的、零散的 DevOps 工具链常常造成数据孤岛，阻碍了对整个软件开发生命周期（SDLC）的可见性。然而，单一的 DevOps 平台提供了一个引人注目的解决方案，通过提供端到端的可见性。例如，它能够跟踪每一个变更，从代码仓库中的首次提交到生产服务器上的最终部署。这种整体视图有助于识别瓶颈，在开发周期的早期发现潜在问题，并衡量 DevOps 实践的整体有效性。此外，全面的审计追踪提供了所有活动的清晰记录，简化了故障排除并确保符合安全法规。
统一平台还简化了治理并释放了智能自动化的潜力。在不同工具之间管理治理策略可能既繁琐又容易出错。单一平台允许你在整个开发流水线中一致地定义和执行策略。这确保代码符合编码标准、安全最佳实践和内部准则。例如，你可以通过实施以下策略来简化治理：在提交代码之前、在 CI 过程期间以及在 CD 过程期间，使用（你组织）批准的安全扫描器扫描代码。通过统一平台，这可以很容易地作为模板实现并重复使用。
此外，通过对部署上下文（包括基础设施和配置细节）的全面理解，该平台可以提供智能代码建议，优化性能和效率。想象一个由 AI 驱动的助手，它根据服务将如何部署来推荐代码调整，这可能节省开发时间并提高代码质量。
访问控制示例
当团队组建交付工具链时，通常会从单个点解决方案开始。然而，这种零散的方法可能导致显著的运维开销。在本节中，我们将以 RBAC 为例，看看一个内聚的交付流水线如何简化操作并赋能开发团队。
大多数协作工具都以某种形式使用基于角色的功能访问。代码仓库将支持内置角色，或包含内置角色并允许用户定义自定义角色。例如，GitHub 定义了“读取（Read）”、“分类（Triage）”、“写入（Write）”、“维护（Maintain）”和“管理（Admin）”等角色。这些角色对应于不同的访问级别；“读取”角色推荐给非代码贡献者，而“管理”角色则专为需要完全访问项目（包括敏感和破坏性操作）的用户设计。
这些系统使用 RBAC，这是一种管理系统中资源访问的方法，其核心围绕三个要素：用户、角色和权限：
- 用户代表需要访问的个人或账户。
- 角色是定义好的权限集合，授予对系统中特定资源或操作的访问权限。
- 权限是控制的基本单位，定义用户可以执行的操作（如读取、编辑或删除数据）。
用户不直接被分配权限。相反，他们被分配一个或多个角色。一旦用户被分配了角色，他们就继承了与该角色相关联的所有权限。这种方法通过消除为每个用户单独分配权限的需要来简化访问管理。相反，权限在角色级别定义，并根据用户被分配的角色授予访问权限。图 2-6 说明了用户如何被分配到角色，以及与角色相关联的权限集。
使用基于角色的访问是一种常见的模式，它通过强制执行最小权限原则（即仅授予用户执行其工作职能所需的权限）来减少管理工作并增强安全性。基于角色的访问还有助于合规性，因为它提供了谁可以访问系统中哪些内容的清晰文档。
定义角色，平台化方法
想象一个 DevOps 生态系统，它由 Git 仓库、Jenkins、用于管理 AWS 基础设施的 Terraform、用于配置管理的 Ansible 以及用于捕获性能指标的 Datadog 组成。在这样一个由多个不同工具构建的系统中，你可能会发现需要在每个系统中定义相似的角色，并重复添加这些角色。为新开发人员配置权限可能需要耗费时间的多个步骤。让我们看看一体化平台如何使用平台化方法处理 RBAC。
例如，Harness 平台具有三级层次结构。这三个级别（或范围）分别是账户（Account）、组织（Organization，简称 Org）和项目（Project）：
- 账户是最高级别的实体。它可以对整个平台进行控制并拥有可见性。
- 组织是一个控制单元，来自同一业务部门的人员和项目可以在一个独立的层次结构中进行组织。一个组织可以有多个项目。
- 项目是协作的基本单元，用户被分组在一起以处理相同的任务。
资源组（Resource Groups）是 RBAC 的一个组件，它定义了用户可以访问的对象。对象是任何 Harness 资源，包括项目、流水线、连接器、敏感信息、代理、环境、用户等等。当你将资源组分配给用户时，资源组中定义的访问权限将授予目标用户。资源组可以在任何范围定义。
角色同样可以在每个范围定义。角色与资源组一起应用，以创建完整的权限和访问集合。例如，你可以将“流水线执行者（Pipeline Executor）”角色分配给只允许访问特定流水线而非项目中所有流水线的资源组。
总结
在本章中，我们介绍了 SCM，它是现代软件开发的基石。SCM 解决了团队协作和随时间管理代码库变更的挑战。它使团队能够有效地协作并管理代码变更。
SCM 对于 DevOps 和 CI/CD 工作流至关重要，随着 AI 原生 SCM 系统的出现，其作用正在扩大。这些智能系统可以生成、审查、分析和优化代码，改变团队编写和管理软件的方式。通过自动化日常任务、提高准确性并提供洞察力，AI 驱动的 SCM 系统加速了开发并提高了交付效率。
我们还讨论了选择正确代码仓库的重要性以及统一 DevOps 平台在实现内聚工作流和更强治理方面的优势。有了坚实的 SCM 基础，第 3 章将深入探讨持续集成如何自动化构建和单元测试，以确保代码质量和开发速度。