持续集成 - 降低风险

项目有可能会出现问题。通过有效地实践 CI，您可以了解整个过程中每一步发生的情况，而不是等到项目进入开发周期后才知道。CI 可以帮助您在风险发生时识别并减轻风险，从而更轻松地根据具体证据评估和报告项目的运行状况。

本节将重点讨论通过使用持续集成可以避免的风险。

任何项目都存在许多需要管理的风险。通过在开发生命周期的早期消除风险，当系统实际上线时，这些风险发展成问题的机会就会减少。

风险 1 – 缺乏可部署的软件

“它在我的机器上工作，但在另一台机器上不起作用” ——这可能是任何软件组织中最常见的短语之一。由于每天对软件构建进行的更改数量很多，有时人们对软件构建是否真正有效缺乏信心。这种担忧具有以下三个副作用。

消除 IDE 和构建过程之间的紧密耦合。仅使用单独的机器来集成软件。确保构建软件所需的所有内容都包含在版本控制存储库中。最后，创建一个持续集成系统。

持续集成服务器可以监视版本控制存储库中的更改，并在检测到存储库更改时运行项目构建脚本。持续集成系统的功能可以增强，包括通过测试运行构建、执行检查以及在开发和测试环境中部署软件；这样您就始终拥有一个可用的软件。

“无法与数据库同步” ——有时开发人员在开发过程中无法快速重新创建数据库，因此很难进行更改。这通常是由于数据库团队和开发团队之间的分离造成的。每个团队都会专注于自己的职责，彼此之间很少进行协作。这种担忧有以下三个副作用 -

上述问题的解决方案是确保将所有数据库工件放置在版本控制存储库中。这意味着需要重新创建数据库模式和数据所需的一切：数据库创建脚本、数据操作脚本、存储过程、触发器和任何其他数据库资产。

通过删除并重新创建数据库和表，从构建脚本重建数据库和数据。接下来，应用存储过程和触发器，最后插入测试数据。

测试（并检查）您的数据库。通常，您将使用组件测试来测试数据库和数据。在某些情况下，您需要编写特定于数据库的测试。

由于多个开发人员经常对源代码进行如此多的更改，因此总是有可能在代码中引入只能在稍后阶段才能检测到的缺陷。在这种情况下，这可能会造成很大的影响，因为软件中检测到缺陷的时间越晚，消除缺陷的成本就越高。

回归测试- 这是任何软件开发周期、测试和再次测试中最重要的方面。如果软件代码有任何重大更改，则绝对必须确保所有测试都运行。这可以在持续集成服务器的帮助下实现自动化。

测试覆盖率- 如果测试用例没有覆盖代码的全部功能，则测试就没有意义。确保为测试应用程序而创建的测试用例完整并且测试所有代码路径非常重要。

例如，如果您有一个需要测试的登录屏幕，那么您就不能拥有包含成功登录场景的测试用例。您需要有一个负面测试用例，其中用户输入不同的用户名和密码组合，然后需要查看在这种情况下会发生什么。

手动沟通机制需要大量协调，以确保项目信息及时传播给正确的人员。向你旁边的开发人员倾斜并让他们知道最新版本位于共享驱动器上是相当有效的，但它的扩展性不是很好。

如果还有其他开发人员需要此信息，但他们正在休息或因其他原因无法联系，该怎么办？如果服务器出现故障，您如何收到通知？有些人认为他们可以通过手动发送电子邮件来降低这种风险。但是，这不能确保信息在正确的时间传达给正确的人，因为您可能会无意中遗漏感兴趣的各方，并且某些人当时可能无法访问他们的电子邮件。

此问题的解决方案仍然是持续集成服务器。所有 CI 服务器都具有在构建失败时触发自动电子邮件的功能。通过自动通知所有关键利益相关者，还可以确保每个人都了解软件的当前状态。

有缺陷，然后就有潜在的缺陷。当您的软件设计不佳、不符合项目标准或维护复杂时，您可能会存在潜在的缺陷。有时，人们将其称为代码或设计气味——“可能出现问题的症状”。

一些人认为，低质量的软件仅仅是递延的项目成本（交付后）。它可能是递延的项目成本，但在将软件交付给用户之前它也会导致许多其他问题。过于复杂的代码、不遵循架构的代码以及重复的代码——所有这些通常都会导致软件缺陷。在这些代码和设计气味显现为缺陷之前发现它们可以节省时间和金钱，并可以带来更高质量的软件。

有一些软件组件可以与 CI 软件集成来执行代码质量检查。这可以在代码构建后运行，以确保代码实际上符合正确的编码准则。