持续集成 - 降低风险
项目中可能会出现问题。通过有效地实践 CI，您可以了解在开发周期中的每个步骤会发生什么，而不是在项目进入开发周期后期才发现。CI 帮助您在风险发生时识别和降低风险，从而更容易根据具体证据评估和报告项目的健康状况。
本节将重点关注使用持续集成可以避免的风险。
任何项目都存在许多需要管理的风险。通过在开发生命周期的早期消除风险，这些风险在系统实际上线时演变成问题的可能性就会降低。
风险 1 – 缺少可部署的软件
“在我的机器上可以工作，但在其他机器上却无法工作” – 这可能是任何软件组织中最常见的短语之一。由于每天对软件构建进行的更改数量众多，有时人们对软件构建是否真正有效缺乏信心。此问题有以下三个副作用。
对我们是否能够构建软件几乎没有信心。
在内部（即测试团队）或外部（即客户）交付软件之前，集成阶段很长，在此期间没有其他工作完成。
无法生成和复制可测试的构建。
解决方案
消除 IDE 和构建流程之间的紧耦合。使用单独的机器专门用于集成软件。确保构建软件所需的一切都包含在版本控制存储库中。最后，创建一个持续集成系统。
持续集成服务器可以监视版本控制存储库中的更改，并在检测到对存储库的更改时运行项目构建脚本。持续集成系统的功能可以增强，包括让构建运行测试、执行检查以及在开发和测试环境中部署软件；这样您始终拥有一个可工作的软件。
“无法与数据库同步” – 有时开发人员无法在开发期间快速重新创建数据库，因此难以进行更改。这通常是由于数据库团队和开发团队之间存在分离造成的。每个团队都专注于自己的职责，彼此之间的协作很少。此问题有以下三个副作用：
害怕更改或重构数据库或源代码。
难以使用不同的测试数据填充数据库。
难以维护开发和测试环境（例如，开发、集成、QA 和测试）。
解决方案
解决上述问题的办法是确保所有数据库工件都放置在版本控制存储库中。这意味着重新创建数据库模式和数据所需的一切：数据库创建脚本、数据操作脚本、存储过程、触发器以及任何其他所需的数据库资产。
通过删除和重新创建数据库和表，从构建脚本中重建数据库和数据。接下来，应用存储过程和触发器，最后插入测试数据。
测试（和检查）您的数据库。通常，您将使用组件测试来测试数据库和数据。在某些情况下，您需要编写特定于数据库的测试。
风险 2 – 在生命周期后期发现缺陷
由于多个开发人员对源代码进行了如此多的频繁更改，因此代码中始终有可能引入缺陷，而这些缺陷可能只能在后期阶段检测到。在这种情况下，这可能会造成很大的影响，因为在软件中检测到的缺陷越晚，消除缺陷的成本就越高。
解决方案
回归测试 - 这是任何软件开发周期的最重要方面，测试和再测试。如果对软件代码进行任何重大更改，则绝对必须确保运行所有测试。这可以通过持续集成服务器自动完成。
测试覆盖率 - 如果测试用例没有涵盖代码的全部功能，那么测试就没有意义。必须确保创建的用于测试应用程序的测试用例是完整的，并且所有代码路径都经过测试。
例如，如果您有一个需要测试的登录屏幕，您不能只创建一个成功登录的场景的测试用例。您需要有一个负面测试用例，其中用户输入不同的用户名和密码组合，然后需要查看在这种情况下会发生什么。
风险 3 – 缺乏项目可见性
手动通信机制需要大量的协调才能确保及时地将项目信息传播给合适的人员。向旁边的开发人员倾斜并让他们知道最新的构建位于共享驱动器上非常有效，但它不能很好地扩展。
如果还有其他开发人员需要此信息，而他们正在休息或无法访问怎么办？如果服务器宕机，您是如何得到通知的？有些人认为他们可以通过手动发送电子邮件来降低这种风险。但是，这无法确保信息在正确的时间传递给合适的人员，因为您可能会意外地遗漏感兴趣的各方，而有些人可能当时无法访问他们的电子邮件。
解决方案
解决此问题的办法再次是持续集成服务器。所有 CI 服务器都具有在构建失败时触发自动电子邮件的功能。通过向所有关键利益相关者发送此自动通知，还可以确保每个人都了解软件的当前状态。
风险 4 – 软件质量低下
有缺陷，也有潜在缺陷。当您的软件设计不佳或不符合项目标准，或者难以维护时，您可能会遇到潜在的缺陷。有时人们将其称为代码或设计异味——“表明某些地方可能存在问题”。
有些人认为低质量的软件仅仅是延迟的项目成本（交付后）。它可能是延迟的项目成本，但在您将软件交付给用户之前，它还会导致许多其他问题。过于复杂的代码、不遵循架构的代码以及重复的代码——通常都会导致软件中的缺陷。在这些代码和设计异味演变成缺陷之前找到它们可以节省时间和金钱，并可以带来更高质量的软件。
解决方案
有一些软件组件可以执行代码质量检查，这些组件可以与 CI 软件集成。这可以在代码构建后运行，以确保代码实际上符合正确的编码指南。