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