理解持续集成和持续部署

听说过CI/CD但不确定是什么？

理想情况下，软件工程师被雇佣来编写需要交付到生产环境的代码，以便需要该产品的企业可以使用它。为了满足企业（通常称为用户/客户），产品必须是无bug的。

软件工程师通常采用的方法是在分支上工作，并创建一个拉取请求，将新的更新更新到主分支中。我们已经采用了编写测试的做法，以确保新的更改不会引入bug。当开发人员在大多数情况下开发功能时，通常在完全完成功能之前不会创建拉取请求。当他们准备好的时候会发生以下情况;

• 他们花费很多时间尝试使他们的代码库与在他们工作时发生的生产分支的更改保持最新。
• 在这样做的过程中，他们必须解决一系列合并冲突。
• 他们还有可能破坏生产分支，这会影响到在问题被发现和修复之前从分支上拉出代码的人。

如果你曾经遇到过这种情况，你会同意这可能是一种痛苦的经历 – 没人愿意这样度过他们的工作日。

解决方案是什么？

持续集成

为了防止我上面提到的情况，工程团队可以采用称为“持续集成”的实践 – 正如其名称所示，它涉及开发人员对代码更改进行持续集成到共享的分支/仓库中。要集成的代码必须经过验证的测试，以确保不会破坏应用程序。只有在测试通过后才会进行集成

为了理解这一点，让我们想象一个现实生活中的情景，有一个由10个开发人员组成的团队。这些开发人员在本地创建一个分支，他们在其中编写用于实现某些功能的代码。他们选择在进行小的更改时发送拉取请求，而不是在完全完成功能后发送拉取请求。这样的更改示例将是创建一个新的模态框，假设开发人员正在开发一个允许用户管理应用程序中个人任务的功能。开发人员在等待任务功能完成之前，为了遵循持续集成模式，将这个小的更改（与她正在开发的相比）推送并创建一个合并请求。

在集成这个新的更改之前，需要运行一系列的测试。

软件工程团队使用类似Travis CI的工具来创建这些集成过程和测试。使用这样的工具，测试是自动化的，只要提交到设置中选择的目标分支，测试就会运行。

测试的结果会生成，并且创建拉取请求的开发人员可以看到结果并进行必要的更改。遵循这种尽可能少地集成代码，并进行验证测试的模式的好处是;

• 团队可以知道是什么导致构建过程或测试失败。这减少了将bug发送到生产环境的可能性。
• 如果团队自动化了这个过程，他们会有时间专注于提高工作效率。

在这种实践中需要注意的重要事项是，它鼓励团队频繁地将代码推送到主分支。如果团队的其他成员不从主分支拉取以更新他们的本地仓库，那么这样做将是无效的。

测试的类型

在编写将成为集成过程一部分的测试时，以下是一些可以在该过程中实施的测试:

• 集成 – 将软件的各个单元组合在一起并进行测试。
• 单元 – 测试软件的单个单元或组件，如方法或函数。
• UI – 断言软件从用户的角度正常工作。
• 验收 – 测试软件是否符合业务需求。

需要注意的是，并不需要测试所有这些内容，因为其中一些可能已经在开发人员编写的代码中进行了覆盖。

持续集成工具

在不深入探讨的情况下，以下是您可以在当前或新项目中开始使用的工具：

• Travis CI – 在开源世界中广为人知，并承诺让您的代码在几分钟内无缝测试。
• Circle CI – 为您提供自动化管道控制到部署的强大、灵活和可控性。
• Jenkins – 提供数百种插件，支持构建、部署和自动化任何项目。

如果您是Jenkins的新手，我建议您参加此 Udemy course 以学习使用Java和.NET进行CI。

持续部署

如果您构建的功能在存储库中停留数周或数月之后才部署到生产环境中，那么这有什么好处呢？尽管工程团队可以努力将小的更改集成到主分支中，并尽快将这些更改推送到生产环境中。

在实践持续部署时的目标是，开发人员将这些更改集成到主分支后，尽快将更改推送给用户。

与持续集成的情况类似，在使用持续部署时，会建立自动化测试和检查来验证新集成的更改。只有当这些测试通过时，部署才会发生。

为了使团队受益于持续部署的实践，他们需要具备以下条件：

• 自动化测试是所有持续工程实践的基础。在持续部署的情况下，要部署的代码必须符合团队为推送给最终用户的内容所制定的标准。理想情况下，如果新更改低于阈值，测试应该失败并且不能集成。否则，它将被集成。
• 尽管已经进行了自动化测试，但仍有可能在生产环境中出现一些错误。因此，团队需要能够撤销已经进行的更改 – 撤销部署。这将使生产代码恢复到新更改之前的状态。
• 需要监控系统来跟踪已推送到生产环境中的更改。这是团队能够跟踪用户在使用部署更改时遇到的错误的方式。

用于持续集成的工具也提供了设置持续部署系统的功能。还有很多其他工具 read up on 可供选择。

结论

开发团队的生产力对企业的成功至关重要。为了确保他们的生产力，必须采用鼓励此类工作的实践。持续集成和部署是这些实践的例子。

通过持续集成，团队可以每天推送尽可能多的代码。通过实现这一目标，可以尽快将新增的更改部署给用户。部署这些更改使得能够从用户那里获得反馈。最终，企业将能够根据收到的反馈进行创新，这对每个人来说都是双赢的。

您还可以了解如何 scale up and optimize CI/CD。

如果您是开发人员并有兴趣学习CI/CD，请查看此 brilliant course。