持续集成 – 降低风险

项目有可能出现问题。通过有效地实践 CI，您会发现在整个过程中的每一步都发生了什么，而不是在项目进入开发周期之后。CI 可帮助您在风险发生时识别和减轻风险，从而更轻松地根据具体证据评估和报告项目的健康状况。

本节将重点介绍使用持续集成可以避免的风险。

在任何项目中，都有许多需要管理的风险。通过在开发生命周期的早期消除风险，这些风险在系统实际上线时发展为问题的可能性较小。

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

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

• 对我们是否可以构建软件几乎没有信心。

• 在内部（即测试团队）或外部（即客户）交付软件之前的漫长集成阶段，在此期间没有其他任何事情完成。

• 无法生成和复制可测试的构建。

解决方案

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

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

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

• 害怕更改或重构数据库或源代码。

• 难以用不同的测试数据集填充数据库。

• 难以维护开发和测试环境（例如，开发、集成、QA 和测试）。

解决方案

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

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

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

风险 2 – 在生命周期后期发现缺陷

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

解决方案

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

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

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

风险 3 – 缺乏项目可见性

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

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

解决方案

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

风险 4 – 低质量软件

有缺陷，然后有潜在的缺陷。如果您的软件设计不当，或者不符合项目标准，或者维护起来很复杂，则可能存在潜在缺陷。有时人们将其称为代码或设计气味——“一种可能出现问题的症状。”

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

解决方案

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