Continuous Integration - Reducing Risks

对我们是否甚至能够建造软件几乎没有信心。

在内部(即测试小组)或外部(即客户)交付软件之前的宽度整合阶段,在此期间没有做其他工作。

无法生产和复制可检测的建筑。

Solution

消除民主选举学会与建筑工序之间的紧张关系。 只使用一台单独的机器来整合软件。 确保在版本控制储存库中包含你建造软件所需的一切。 最后,建立持续融合制度。

连续整合服务器可以观察版本控制存放处的变动情况,并在发现对存放处的变更时管理项目建档。 不断整合系统的能力可以提高,包括进行试验,进行视察,并在开发和测试环境中部署软件;这样,你总是有工作软件。

“可与数据库同步”——有时开发商无法在开发过程中迅速重新检索数据库,因此难以进行改动。 这常常是由于数据库小组与发展小组之间的分离。 每个小组将侧重于自己的责任,彼此之间几乎没有合作。 这一关切有三个方面的影响:

担心改变数据库或源代码,或对其加以调整。

难以用不同测试数据储存数据库。

难以维持发展和试验环境(例如发展、一体化、QA和测试)。

Solution

以上问题的解决办法是,确保把所有数据库工艺品列入版本的控制储存库。 这意味着需要调整数据库图谱和数据:需要数据库制作文字、数据操纵文字、储存程序、触发器和任何其他数据库资产。

通过放弃和重开你的数据库和表格,重新购买你的建筑文字数据库和数据。 其次,适用所储存的程序和触发因素,最后插入测试数据。

测试(和检查)贵国数据库。 通常,你将使用部件测试来测试数据库和数据。 在某些情况下,你需要撰写具体数据库的测试。

Risk 2 – Discovering Defects Late in the Lifecycle

由于多种开发商经常对源代码进行大量修改,因此总是有可能在法典中引入一种缺陷,而这种缺陷只能在稍后阶段发现。 在这种情况下,这可能产生巨大影响,因为软件中后来发现了缺陷,消除缺陷的成本越高。

Solution

这是任何软件开发周期、测试和测试的最重要方面。 如果软件代码有任何重大改动,则绝对必须确保所有测试都进行。 在连续一体化服务器的帮助下,可以实现自动化。

如果测试案例没有涵盖该守则的全部功能,则没有检测点。 必须确保为测试申请而创建的测试案例是完整的,并测试所有密码途径。

例如,如果你有一个需要测试的标志性屏幕,那么你就没有一个能够成功标识的测试案例。 如果用户使用不同的用户名称和密码组合,则需要有一个负面的测试案例,然后需要看到这种情景发生的情况。

Risk 3 – Lack of Project Visibipty

手册通信机制需要进行大量协调,以确保及时向适当的人民传播项目信息。 接手到你们旁边的开发商,让他们知道,最新的建筑是共同的驱动力,是相当有效的,但是它并没有很好地缩小规模。

还有哪些其他开发商需要这种信息,他们正在休息或以其他方式无法得到? 如果服务器倒塌,你会怎样得到通知? 有些人认为,他们可以通过人工发送电子邮件来减轻这一风险。 然而,这不能确保信息在适当的时候传递给适当的人,因为你可能意外地离开有关各方,而有些人当时可能无法使用他们的电子邮件。

Solution

解决这一问题的办法再次是连续整合服务器。 所有的电离层服务器都有在电离层故障时启动自动电子邮件的设施。 通过向所有关键利益攸关方发出这一自动通知,还确保每个人都掌握软件目前的状况。

Risk 4 – Low Quapty Software

存在缺陷,因此存在潜在的缺陷。 如果你的软件设计不完善,或不符合项目标准,或难以维护,那么你就可能存在潜在的缺陷。 有时,人们将这种说法称为法典或设计工具,“一种可能错的症状。 ......

有些人认为,低质量软件只是推迟的项目费用(交付后)。 这可能是一个推迟的项目费用,但在你向用户提供软件之前,它也会导致许多其他问题。 过于复杂的代码、不遵循结构的代码和重复编码,通常会导致软件出现缺陷。 在出现缺陷之前发现这些代码和设计工具可以节省时间和金钱,并可导致高质量的软件。

Solution

有一些软件部件进行编码质量检查,可以与 CI软件相结合。 可以在守则建立之后进行,以确保守则实际上符合适当的编码准则。