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