|
|
6 回复 | 直到 16 年前
|
1
23
(值得注意的是,“持续整合”是指 自动化的 与 自动化的 构建过程和 自动地 运行测试 自动地 检测每个部件的故障。 值得注意的是,“持续集成”仅仅意味着主干或测试服务器。这并不意味着“活到老”。 有很多方法可以错误地进行连续集成。) 我想不出任何理由不进行持续集成测试。我想我假设“持续集成”包括测试。仅仅因为它编译并不意味着它可以工作。 如果构建和/或测试需要很长时间,那么持续集成可能会变得昂贵。在这种情况下,在提交之前运行明显与更改相关的测试(覆盖率分析工具,如 Devel::CoverX::Covered 可以帮助发现什么测试与什么代码相匹配),在提交之后使用 SVN::Notify ,如果失败,则通知开发人员。使用类似于 Smolder . 这使得开发人员可以快速地工作,而不必坐在那里看测试套件的运行,同时还可以很早地发现错误。 也就是说,通过一些工作,您可以经常加快构建和测试过程。很多时候,缓慢的测试都是由于每个测试都要做太多的设置和拆卸,而这些设置和拆卸指向的系统太过耦合,只需要设置整个系统来测试一小块。 分离通常会有所帮助,将子系统分解为独立的项目。较小的范围使理解更容易,构建和测试更快。每个提交都可以进行完整的构建和测试,而不会给程序员带来不便。然后将所有子项目收集在一起进行集成测试。 在每次提交时运行测试套件的一个主要优势是,即使它是在提交之后,您知道是什么破坏了构建。而不是“我们昨天做的事情破坏了构建”,或者更糟的是,“我们昨天做的四件事以不同的方式破坏了构建,现在我们必须解开它”,“它是”修订版1234破坏了构建。您只需检查一个修订版就可以找到问题所在。 每天构建的好处是,至少你知道每天都有一个完整的、干净的构建和测试运行。但无论如何,你应该这么做。 |
|
|
2
12
我不认为这有什么坏处。但是为了争论,这里是 Eric Minick's article on UrbanCode (关于测试而不是构建。) 他批评基于 Martin Fowler's work 说他们没有足够的时间进行测试。
为了在CI中取得真正的成功,Fowler断言构建应该是自测试的,并且这些测试包括单元测试和端到端测试。同时,构建应该非常快——理想情况下不到十分钟——因为它应该在每次提交时运行。如果有大量的端到端测试,那么在构建时执行它们,同时将整个过程保持在10分钟以下是不现实的。
|
|
|
3
9
James Shore有一系列关于使用CruiseControl这样的CI工具意味着您正在进行持续集成的危险性的博客文章:
建立CI服务器的一个危险是目标转移,认为重要的是“保持构建通过”,而不是“确保我们拥有高质量的软件”。所以人们不再关心测试需要多长时间。然后他们花了太长时间才运行完所有的文件。然后建筑继续破坏。然后构建总是被破坏。因此,人们对测试进行注释以使构建通过。软件的质量下降了,但嘿,构建正在通过… |
|
|
4
4
通常有两种情况,我认为持续集成并不真正有意义。请记住,我是一个很大的词倡导者,并尽量使用它时,我可以。 第一个问题是投资回报率没有意义。我目前开发了几个小型的内部应用程序。这些应用程序通常非常小,开发的整个生命周期大约是一两周。要正确设置CI的所有内容,可能会使其翻倍,我可能再也不会看到这项投资回来了。你可以争辩说我会把它恢复到维护状态,但这些应用程序在更新后很可能会被丢弃。请记住,您的工作可能是发送软件,而不是达到100%的代码覆盖率。 我听到的另一种情况是,如果你不打算对结果做任何事情,那么CI就没有意义。例如,如果您的软件必须发送给QA,并且QA人员只能每隔几天查看一个新版本,那么每隔几小时就进行构建是没有意义的。如果其他开发人员不考虑代码度量并尝试改进它们,那么跟踪它们就没有意义。当然,这不是CI技术不好的原因,而是您的团队不愿意接受CI。然而,在这种情况下实现CI系统是没有意义的。 |
|
|
5
0
启动时,需要一段时间来设置所有内容。 如果添加测试、覆盖率、静态代码检查、重复搜索、文档构建和部署,可能需要很长时间(几周)才能正确完成。之后,维护构建可能是一个问题。 例如,如果您将测试添加到解决方案中,您可以让构建根据某些标准自动检测它们,或者您必须手动更新构建设置。自动检测很难纠正。覆盖范围相同。与文档生成相同… |
|
|
6
-4
不进行持续集成的唯一好理由是,当您让项目工作到集成测试在很长一段时间内没有发现任何缺陷,并且每次进行构建时运行这些缺陷所花的时间太多。换句话说:你已经做了足够的持续集成,你已经向自己证明你不再需要它了。 |
推荐文章