Appearance
CI/CD 概念
什么是工件存储库？
工件仓库（或工件管理器）存储通过持续集成生成的构建工件，并使它们可用于到测试、暂存和生产环境的自动部署。
构建工件是由构建流程创建的文件，例如分发软件包、WAR 文件、日志和报告。 工件可以存储在 CI 服务器上的仓库中，也可以存储在 CI 服务器可用的外部位置。
当您定期提交更改时，自动化的 CI/CD 管道每天会生成大量构建。 管道的性质意味着在发现问题之前，许多构建将部署到前几个环境中，而少量构建将持续到发布上线。
工件仓库提供了一个中心位置来存储这些构建，并且大多数会公开一个 API 以将构建自动部署到管道中的环境。 作为管道逻辑的一部分，您可以指定构建应在仓库中保留多长时间以及移除工件以释放空间的条件。
CI/CD 的分支策略
像制表符与空格一样，分支策略是引发在线和离线激烈辩论的情绪话题之一。
就像软件开发中的许多事情一样，关于最佳方法有许多坚定的观点，但正确的答案取决于上下文。 考虑到这一点，我们来看看什么是分支策略以及它们如何与 CI/CD 关联。
简而言之，分支策略是您的团队就如何以及何时在版本控制中创建和合并分支的协议。 您如何设置版本控制系统和使用分支将影响您如何设置 CI/CD 管道，因此选择满足您需求的模型至关重要。
DVCS 中的分支
随着使分支变得更加容易的分布式版本控制系统（尤其是 Git）的流行，分支策略成为开发团队的一个考量因素。
对于分布式系统，仓库有多个副本，因此有多个真实来源（尽管团队通常会指定一个中央副本或主副本）。 您和您的团队成员在仓库副本上并行处理您的更改，通过将更改推送到同一仓库的其他副本来共享您的工作。
Git 使创建分支和合并来自不同分支的提交成为一种非常轻量级的工作。 在 Git 中，分支只是一个标有特定名称的提交（或一组提交）。 分支非常适合包含一组更改，例如处理新功能或黑客实验。
随后，您可以通过将分支推送到另一个仓库并且/或者将其与另一个分支（例如 master 分支）合并以将其与代码库的其余部分合并来共享您的更改。 如果您决定不采用更改，也可以舍弃这些更改。 当您将两个分支合并时，Git 会负责对齐每个分支上的提交，并避免与在其他版本控制系统中合并相关的大部分复杂性。
为 CI/CD 使用分支
通过持续集成，重点是让开发团队中的每个人都经常提交他们的更改。 这意味着您可以定期测试一切是否按预期运行，而不是在代码编写完成后花费数周或数月的时间去尝试集成不同的工作流。 反过来，这也可以更经常地发布软件更新，从而发挥持续交付和部署的优点。
决定应当在哪里提交更改，应当何时运行自动化构建和测试，以及应当从哪里发布更新是分支的使用与 CI/CD 交互的地方。 最简单的方法（至少在概念上）是完全避免分支。 在基于主干的开发中，每个人都定期将更改提交到中央仓库的 master 分支，中央仓库保持可发布状态并且经常部署到生产中。
尽管基于主干的开发可以非常有效地运行，尤其是当您拥有成熟的 CI/CD 设置并且正在运行到托管系统的持续部署时，它也提出了一些挑战。 分支策略提供了管理代码更改的替代方法，这些方法拥有不同的优点和缺点。 下面是运行 CI/CD 的开发团队最常用的一些方法。
功能分支
顾名思义，创建功能分支是为了将各个功能与代码库的其余部分分开。 将正在进行的工作保持在 master 分支以外可以更容易地将 master 分支保持在可部署状态，并且如果您直接从 master 分支而不是发布分支（见下文）部署，则可避免将未完成的功能部署到生产。 您仍然可以通过将您的分支推送到中央仓库（如果您已指定一个）或任何其他仓库来与团队的其他成员共享您的工作。
功能分支的主要缺点以及基于主干的开发的拥趸经常对它们提出的批评是，如果将更改的集成延迟到功能“完成”，用户将失去持续集成带来的好处。 这可能会导致合并冲突并引入更复杂的错误，与迭代提交更改相比，这些错误需要更长的时间才能修正。
您可以通过设置 CI 服务器来缓解这些问题，以便在功能分支和 master 分支（或您用来准备发布的任何分支）上运行自动构建和测试。 这既可确保您从正在构建的内容的即时反馈中受益，同时还能降低合并更改时出现问题的风险。
最大限度减少合并冲突的一种方法是使功能分支保持短暂的生命周期，最多一两天。 另一种选项是定期基于 master 分支变基分支或合并来自 master 分支的更改。 这将使您的功能分支与提交给 master 分支的所有其他更改保持同步。 但是，如果您有大量并发功能分支都延迟提交到 master 分支，则仍然存在冲突的风险。
发布分支
功能分支提供了一种管理正在进行的工作的方法，而发布分支则用于在发布之前“强化”更改。 发布分支非常适合持续交付模型，其中更新是以一定间隔交付，而不是在准备就绪时立即交付，这样便可在生产中更轻松地支持多个版本。
使用发布分支工作流，一旦为特定发布计划的更改准备就绪，就会立即创建包含相关更改的发布分支（从 master 分支或另一个开发分支），之后不再合并其他功能。 同时，为其他发布计划的功能开发可以继续合并到 master 分支或其他地方。
发布分支构建随后进行一系列自动化测试，并在发布分支上进行任何错误修正，之后进行进一步的测试，直到您准备好发布。 这些错误修正也应当应用回 master 分支，以确保它们包含在未来的产品版本中。
只要您需要支持软件的每个版本，就可以保持您的发布分支，这样便可更轻松地将修正部署到旧版本。
需要更新时，可以在修补程序分支中或 master 分支上开发并正常测试，随后应用到发布分支（例如，通过优选）。
然后，它将经过该分支上的 CI/CD 管道，以确保在部署更改之前该版本没有任何问题。 或者，您可以直接在发布分支上完成工作，并在适用时将其应用回 master 分支。
修补程序分支
修补程序分支的操作类似于功能分支，但为了完整起见，值得一提。 修补程序分支的目标是将错误修正尽快应用到生产中。
您可以从 master 分支或发布分支创建修补程序分支，具体取决于您的部署位置。 与功能分支一样，您可以选择在修补程序分支上运行某些 CI/CD 元素，然后再将其合并到发布分支或 master 分支，以便在发布前进行进一步的自动化测试。
收尾工作
我们已经了解了在 CI/CD 工作流中使用分支的一些最常见方法，但还有更多不同的方法。
最重要的是找到适合您的特定上下文的策略。 采用持续改进的 DevOps 心态并对不同的选项保持开放态度，这样您便能够随着 CI/CD 做法的成熟不断调整方法来满足您的需求。
什么是 Canary 发布？
Canary 发布是一种最初将更改发布给一小部分用户的部署策略。
随后使用业务 KPI 和运营指标仔细监控系统是否存在问题迹象。 一旦您确信您的更改没有对功能、性能或安全性产生不利影响，就可以分批或一次性向其余用户推出这些更改。
可以将接收更新的最初一部分用户比喻成煤矿中的金丝雀；如果在发布后检测到问题，那么损害仅限于他们。 因此，您的大多数用户仍然不知情且不受影响。 在部署无法在暂存环境中进行充分测试的高风险更改时，Canary 发布非常有用。
对于基于 Web 的系统，实现 Canary 发布涉及托管您产品的两个版本，控制路由到每个版本的流量，以及主动监控两者的运行状况。 对于已安装的产品，您可以向一部分用户提供新版本。 尽管如此，您很难控制他们何时应用更新，因此可能需要更长的时间来确定您的更改是否准备好向更多用户发布。
什么是代码覆盖率？
代码覆盖率，也称为测试覆盖率，可衡量自动化测试执行的代码比例。
代码覆盖率工具针对特定的编程语言。 其使用一系列标准衡量覆盖率，包括代码行数、方法或函数、分支和条件。 您可以使用代码覆盖率工具识别代码库尚未被自动化测试覆盖的部分。
监测代码覆盖率指标有助于确保您保持足够的自动化测试水平。 如果代码覆盖率有所下降，则可能表明您没有将自动化测试作为编写新代码的核心要素。
然而，虽然代码覆盖率能够说明测试覆盖了多少代码，但它并不会指示这些测试的有效性或其能否解决所有故障模式。 将代码覆盖率与其他指标相结合，了解自动化测试体系的有效性。
什么是配置管理？
在软件开发和 CI/CD 的上下文中，配置管理是指记录特定基础架构设置的详细信息，以便您可以确定更改何时引入。
CI/CD 管道包括多个用于在发布前测试和暂存软件的环境。 为了使管道和测试有效运行，预生产环境需要尽可能地复制生产并在测试运行之间保持一致。
为此，您可以设置一系列物理计算机或虚拟机来托管这些环境。 然而，随着时间的推移，需要应用补丁、安装新软件包或修改网络设置来排除特定问题，这些服务器开始以不同的方式偏离原始配置。
结果是一系列的 Snowflake 服务器。 更糟糕的是，假设每个更改的详细信息都没有记录下来。 在这种情况下，当服务器出现故障或者需要复制以扩大测试操作的规模时，重新创建相同的环境变得更加困难。 配置管理试图解决这一问题。
在您的版本控制系统中存储配置详细信息让任何更改一目了然，这样在出现问题时，可以更轻松地将它们撤消并将相同的更改应用于其他计算机，从而保持一致性。
如果这些配置详细信息以 YAML 或 XML 文件等结构化格式存储，那么您可以进一步进行配置管理并自动执行服务器配置。
将更改提交到版本控制后，它们会自动应用于相关的环境。
采用基础架构即代码方法可以自动拆除和重新创建虚拟机，这样您就可以设置 CI/CD 管道来刷新部署之间的环境。 这样便能够处理大量计算机，并且允许您在测试需求增加时轻松复制环境。
如果您使用容器来部署软件，则某些配置元素（例如软件依赖项）将移动至容器镜像。 但是，仍然需要配置托管容器的服务器。 将这些环境的创建编写为代码并实现自动化仍然会带来许多好处。
什么是持续交付成熟度模型？
持续交付成熟度模型提供了用于评估您在采用和实现持续集成、交付和部署 (CI/CD) 方面进度的框架。
成熟度模型通常将 CI/CD 分解为多个支柱，例如组织文化、部署流程、测试以及报告或反馈。 对于每个支柱，该模型描述了与每个成熟度级别（从基础或初学者到专家）相关的一系列做法和行为。
例如，如果您第一次使用 CI/CD，起点是确保您的所有代码都处于源控制中，鼓励团队中的每个人定期提交更改，并开始编写自动化单元测试。
尽管处于 CI/CD 旅程早期阶段的团队通常会在经过几周的测试后手动发布更改，但在特定日期定期发布的目标会将重点放在拥有一个可靠且可预测的流程上，然后可以对其进行优化和自动化。
建立基础后，您可以通过扩展自动化测试并与运营团队合作创建预生产环境来实现管道第一阶段的自动化。
随着您继续构建管道，您的团队将需要与其他职能部门更密切地协作，并开始为交付软件承担更多的责任。 要实现此目标，他们需要看到软件在生产中的执行情况，并让组织的其余部分接受这种方法。
尽早为这些元素奠定基础，可以让您在解决技术挑战时更容易保持进度。 在每个成熟度级别描述的做法都可以帮助您实现快速、可靠、可重复的发布流程，从而提供对更改的快速反馈。
根据您的组织，您的最终目标可能是在一天内让更改可部署（中级或高级）。 或者，您的目标可能是实现持续部署，如果更新成功通过管道的所有阶段，则会发布更新。 您还可以使用来自生产的持续反馈来指导假设驱动型开发（专家级别）。
使用持续交付成熟度模型可以促进对您想要使用 CI/CD 实现何种目标的讨论，并且将帮助您制定实现各种元素的分步方法。
以渐进方式建立您的管道，在此过程中达成可实现的目标，使流程更易于管理，并且提供评估和学习您迄今为止所做事情的机会。
通过绘制您和您的团队在每个支柱上的位置，您还可以确定任何需要更多投资的领域，以便在开始进入下一个阶段之前达到标准。 最后，与业务利益相关者共享成熟度模型也将有助于设定合理的预期并在未达到专家级别的情况下传达从 CI/CD 获得的好处。
什么是部署自动化？
借助部署自动化，您可以使用单个命令更新测试、暂存和实际环境。
自动执行将新构建部署到预生产和生产环境所涉及的任务创建了一个快速、可重复且可靠的过程。
部署自动化构成了 CI/CD 管道的后半部分。 作为持续集成阶段的一部分发布构建工件后，接下来的步骤涉及将这些工件部署到预生产环境中，以进行自动化集成、端到端、性能和安全测试。 接下来是手动探索性测试和从暂存收集反馈。
最后一个阶段涉及将更改发布到生产中，要么使用完全自动化的流程（持续部署），要么使用手动触发的脚本化流程（持续交付）。
最好为每个环境重复使用相同的构建工件，每次从工件仓库中拉取它们，并在不同环境之间保持部署流程尽可能相似。
这样做意味着，您将在达到生产之前在每个构建上多次测试流程，从而让您对发布更有信心。 如果您的组织第一次使用 CI/CD 和 DevOps，那么就统一部署流程达成一致可能是一项挑战，需要团队围绕共同目标进行协作和调整。
自动执行部署流程对于能够经常发布更改至关重要。 如果没有部署自动化，每次当您想要通过完整的自动化测试机制来纳入构建时，都需要更新测试环境并手动部署新构建。 这会减缓反馈循环的速度并延长将更改交付给用户所需的时间。
什么是功能发布控制（或功能特性切换）？
功能标志也称为功能开关或发布开关，允许您在不更新代码本身的情况下启用或禁用软件中的特定功能。
如果您使用基于主干的开发来实践 CI/CD，功能标志会特别有用，因为它们允许您不断合并到 master 分支以及从 master 分支部署，无需立即向用户提供新功能。 将部署与启动分开还可以更轻松地通过新功能的可用性来协调产品和营销工作。
您可以使用简单的配置文件来实现功能标志，从而允许您在某些环境（例如测试环境）中启用某个功能并在其他环境（例如暂存环境和实际环境）中将其禁用。 请记住，广泛使用功能标志会增加复杂性，并且维护它们可能涉及相当大的手动开销。
如果您发现自己需要一次处理多个功能标志，或者想要使用功能标志对用户运行 A/B 测试，则可能需要考虑使用数据库或专用工具来简化管理。
什么是不稳定测试？
不稳定测试被定义为在未更改代码或测试本身的情况下既返回了合格也返回了失败的测试。
有几个因素会导致不稳定测试结果，如环境不一致、测试运行之间未刷新测试数据、时间和时区问题以及测试执行顺序的依赖项。
不稳定测试的问题在于，它们会减缓 CI/CD 管道并削弱测试过程的可靠性。 由于无法依赖不稳定测试结果，您也无法确定成功的测试运行是否意味着代码没有错误，或者您是否应该在测试失败时花时间尝试重现和修正问题。
要发现不稳定测试，您需要比较多个测试运行的测试结果。 手动执行此分析将相当耗时，不过，好在许多 CI 服务器可自动检测不稳定测试。
找出不稳定测试是对其进行控制的第一步。 了解问题的严重程度，就可以确定修正的优先次序。 在此期间应将不稳定测试静音，从自动化测试报告中排除不稳定测试结果。
什么是发布协调？
发布编排能够协调由多个系统执行的自动化任务以向用户提供软件更新。
完全自动化的发布管道将涉及版本控制系统、构建代理、测试框架、工件仓库、监控工具和通讯渠道。
发布编排会协调所有活动并应用相关业务逻辑，确保环境自动刷新、测试结果快速传达并在满足发布条件时及时部署更改。
虽然建立 CI/CD 管道的早期阶段通常涉及多项手动任务，但随着流程的成熟和更多步骤的自动化，在一个平台上协调不同移动部分将有助于减少等待时间和保持管道高效。
同样，为处理多个开发团队的作业而扩展 CI/CD 管道时，发布编排能够保持流程可靠且一致、在更改就绪时通过管道推送、以测试结果和生产指标的形式提供反馈，以及报告特定更改的影响。
什么是静态代码分析？
静态代码分析是在源代码上执行的一系列自动检查。
静态分析工具会扫描代码，查找常见的已知错误和漏洞，例如内存泄漏或缓冲区溢出。 这一分析还可以强制执行编码标准。
在优先考虑安全的情况下，专业的静态应用安全测试 (SAST) 工具可以检查已知的安全缺陷。 由于静态分析是在源代码上执行，而不执行程序，它既可以在 CI/CD 管道的最开始运行，也可以在提交更改之前直接从 IDE 运行。
与所有形式的自动化测试一样，静态代码分析可确保检查的一致性，并为最新更改提供快速反馈。 集成到 IDE 中的静态分析工具可提供即时的针对性反馈，让您可以及时解决问题。
然而，静态分析只能识别违反预编程规则的实例，不能仅通过阅读源代码找出所有缺陷。 也存在误报的风险，因此需要对结果进行解释。
从这个意义上说，静态代码分析是代码审查的有价值补充，因为它突出了已知的问题，并为对整体设计和方法的审查等更有趣的任务腾出了时间。
静态代码分析构成自动化检查系列的一部分，可保持代码质量，应与其他形式的动态分析（执行代码以检查已知问题）和自动化测试结合使用。
什么是主干开发？
基于主干的开发是实践持续集成和持续交付/部署 (CI/CD) 的团队经常使用的几种分支策略之一。
通过基于主干的开发，您可以将更改直接提交到 master 分支（又称主干），而不是在单独的分支中开发功能或错误修正并在后续阶段将它们合并到 master 分支。
将更改提交到 master 分支会触发 CI/CD 管道。 如果管道标记了任何故障，那么每个人都有责任尽快尝试将其修正。 这样做的目的是保持 master 分支处于可部署状态，同时经常发布更改。
如果您已经熟悉 CI/CD 的原则，那么您可能已经从前面的描述中认识到，基于主干的开发非常适合持续集成和部署。 只要团队中的每个人都定期提交他们的更改，您就可以从看到每个人的更改以及对正在构建的内容的定期、快速反馈中受益。
保持 master 分支健康并处于可发布状态的首要任务会鼓励每个人随时为他们的更改添加测试。 监控测试覆盖率指标将帮助您密切关注这一点，同时确保每个人在提交之前都在本地构建（可能还运行一组基本的自动化测试）将减少在 master 分支上发现的问题数量。
一些基于主干的开发的拥趸认为，这是实现持续集成的唯一方法，使用开发或功能分支只会削弱 CI/CD 的好处。 但是，基于主干的开发也有其缺点。
虽然它非常适合持续部署（通过管道所有阶段的代码更改会自动发布），但该模型最适合 SaaS 产品，这种产品对持续更新（甚至是预期）有很高的容忍度。
如果您正在构建安装式产品或移动应用，则可能希望将更改批量应用到定期发布中，而不是为经过管道的每个更新创建一个新版本。
在这种情况下，使用分支可以更轻松地管理每个发布中包含的内容，并且为多个产品版本提供持续支持。
基于主干的开发的一个潜在挑战涉及如何处理大型或复杂功能的开发。 要在将更改定期提交到 master 分支的同时将这些更改直接部署到生产，需要一种方法来管理您还不想让用户看到的功能。
对于基于主干的开发，功能标志提供了一种控制功能可见性的方法，但管理这些功能可能相当复杂。 另一种方法是选择包含功能分支的分支策略，这样您就可以在准备发布功能前将其保持分离状态。
对于第一次使用 CI/CD 的团队，在您有时间开发可靠的测试套件之前，将更改直接提交到 master 分支并保持其可部署可能极具挑战。 如果基于主干的开发是一个很好的选择，那么随着 CI/CD 做法的成熟，将其作为您可以努力实现的目标是值得的。
基于主干的开发非常适合持续集成和部署，如果您拥有可靠的自动化测试套件，并且不需要支持软件的多个版本或将更新分组到发布中，那么这种开发会发挥最佳效果。 不过，这当然不是唯一的方法，其他分支策略可能会更符合需求，具体取决于您的情况。
什么是价值流图（VSM）？
价值流图是一种用于分析流程、识别浪费区域和优化工作流的精益技术。
在精益制造中，价值流图着眼于将材料转化为产品的所有步骤，包括物流、仓储和装配线，并寻求效率提升。
此过程涉及绘制端到端流程图，识别不同类型的浪费，如生产过剩、等待时间、运动和缺陷，随后制定和实施计划以尽可能减少浪费。
精益软件运动展示了精益思想和技术（包括价值流图）如何应用于软件开发生命周期，使其更加高效并改进交付给用户的内容。
精益理念是对敏捷和 DevOps 原则的补充，该原则突出强调具有持续反馈循环的迭代周期和构建质量以加快价值交付。
无论您是已经实施还是即将实施 CI/CD 管道，创建软件开发过程的价值流图都是一项有意义的实践。
从想法到设计、开发和发布，绘制涉及的所有步骤、人员和工具，可视化整个产品生命周期。
然后，您可以使用此图促进开发和运营团队之间的讨论，建立对各步骤所增加价值以及各参与者关注和动机的共同理解。
勾勒出流程后，即可开始识别浪费实例：也就是不会为用户增加价值的活动（直接以所需功能的形式，或间接形式，例如通过保持产品稳定）。
精益制造中确定的浪费类型已适用于软件开发，包括：
多余功能
就像制造业的生产过剩一样，创建不使用的功能是一种浪费。 以频繁交付的小增量工作、采取最小可行产品方法、持续收集和处理反馈，这些都有助于理解您正在构建的内容，并避免将时间和精力浪费在不被使用的功能上。
任务切换
不断在不同任务之间切换是一种浪费，这会阻止您保持专注。 每次在任务中被打断，您都必须先花时间回到正确的状态才能重拾效率。 无需手动输入触发各测试阶段的全自动管道有助于避免任务切换。 同样，谨慎使用警报，仅在必要时（例如生产失败而不是单元测试失败）才被中断，也有助于避免不必要的任务切换。
等待
最明显的浪费形式之一，工作流中任何阶段的延迟最终都会减缓上市进度。 减少个人之间的交接，尽可能提高构建、测试、部署和提供反馈的自动化程度，将减少等待时间。
额外流程
当更简单的形式可以达到同样的效果时，创建过于复杂的流程和程序将需要更多的时间和资源来实施和维护。 这方面的示例包括从过于复杂的部署到暂存环境再到每次发布前的苛刻风险评估。 了解步骤背后的动机将帮助您确定是否一个更简单的过程就已足够。
缺陷
缺陷会导致额外工作量，一旦发现就需要时间修正，如果投入生产则会对客户体验产生负面影响。 自动测试的小增量工作是打造高质量产品的可行方法，有助于及早发现问题并更快确定问题的原因。 在生产中发现缺陷时，有能力快速发布修正可以最大限度地减少对用户的影响。
部分完成的工作
在制造业背景下被称为库存或库存过多，部分完成的工作不会为用户带来价值，同时会减慢其他功能和改进的交付速度。 通常是由于开发过早，准备不充分，最终导致延迟。 同时，用户的需求得到更好的理解，随后进行返工以适应新的需求。
交接
当工作必须移交给另一个团队完成下一阶段时，这会增加延迟（因为下一个团队可能没有准备好立即开始工作）并且需要通过会议或书面文件转移知识。 通常，在此过程中会丢失一些知识，需要重新找回。 这些都会浪费时间和精力，拖慢进程。 尽量与拥有整个生命周期所有权的跨职能团队减少交接有助于减少此类浪费。
确定流程中的浪费后，就可以着手解决了。
为了与精益、DevOps 和敏捷原则保持一致，应逐步实施更改、监控更改的影响、持续收集反馈并及时调整路线。
最后，不要让价值流图本身成为一种浪费。 虽然可能需要花费大量时间学习正确的符号并将发现转移到绘图工具中创建数字资产，但您通常可以从一个简单的白板会话开始，初步了解您能从价值流图实践中获得多少收益。
什么是软件版本控制？
版本控制系统 (VCS)，又称为源代码管理 (SCM) 系统，允许您跟踪代码库的每一处更改。
将文件保存在版本控制系统中，您可以查看每一次编辑、添加或删除，以及其对应时间和操作者。
您还可以恢复到较早的状态并比较各文件在一段时间内的更改。 版本控制是现代软件开发的必备工具。 它不仅让每个人都能看到更改，而且允许多人处理相同的文件并合并更新，使版本和发布的管理更加轻松。
版本控制系统有两种主要形式：分布式和集中式。 在集中式系统中，所有文件都存储在一个中央服务器上，个人用户“签出”文件的本地副本，然后与中央真实来源同步。
但是，这种方法的主要缺点是中央服务器是单点故障。 相比之下，分布式版本控制系统中具有多个文件副本，因此有多个真实来源。
无论您使用哪种系统，基本步骤都将涉及更新源文件的本地副本、在本地处理更改，然后以提交的形式与他人共享。
将用于构建应用程序的所有文件放入所有人都可以访问的单一版本控制仓库，是实现持续集成和构建 CI/CD 管道的第一步。
这可以使每个人都能定期共享更改，触发自动构建和测试流程，对更改提供快速反馈。
无论是在测试还是生产中，出现问题时您都可以确定引入问题的提交，并使用修订历史记录来准确了解具体变化。