在阅读“乔尔试验”和有关每日建造的文章时,与我在不同公司的几位技术主管朋友的讨论表明,他们从来不进行日常构建或持续集成,因为据他们说:
对于非敏捷项目来说,日常构建和持续集成真的很实用吗?它仅用于测试驱动的开发吗?遵循上面第3点的哲学真的足够了吗?我在和他们谈论乔尔所说的一步一步的自动化,但是他们不愿意接受这个想法。
记者:我在这个网站上浏览过关于日常建设等的问题,但我相信这个问题是不同的。
发布于 2012-08-10 05:12:17
你的朋友太懒了,国际海事组织也不专业--世界很快就会从他们身边过去的。
日常构建是针对遵循敏捷实践的项目。它不适用于瀑布模型。
我没有一个明确的参考方便,但每天的构建是常见的至少早在90's,所以他们的日期前敏捷,和*统一进程时间表。任何时候,您有两个以上的开发人员,有人将签入的东西,可以测试,同时,现在可以自动检查,以打破构建。
自动化测试对于图形部分.
自动化测试是一种节省时间和成本的工具。为什么有人会想让软件比必要的更贵呢?
没有必要进行配置管理
太疯狂了。开发人员都使用不同版本的第三方库?没有人跟踪将在每个版本中部署哪些功能?在版本控制系统中没有分支功能?
发布于 2012-08-10 06:29:33
公平地对待你的讨论伙伴,如果他们拥有的有用,那么,嗯,它是有效的。我可能还是会以某种形式卖给他们CI,但我能理解他们的反抗。
首先设置CI是有开销的,而管理CI则需要开销。不是一个巨大的头,但我直截了当地拒绝成为“CI的家伙”,因为我知道,在某一时刻,这将成为一个不想要的杂务。
但是,一旦我指定了其他人来配置它,至少知道签入的代码正在编译是有益的。只有一个好处是重要的。
它的测试方面有点不相关。CI构建应该运行测试,但是如果这些测试没有任何用处的话,这些测试就不应该存在。不过,总有一些测试用例是有意义的。对于许多开发人员来说,这也是一个阻力点。
有些人仍然认为代码测试覆盖率是项目健康状况的黄金统计数据。不是的。我仍然希望有1pc的覆盖率,因为1pc是合适的,质量测试,而不是80%的覆盖“我写的测试,因为我们需要达到80%的覆盖率”。
这是最后一个问题。一旦你有了CI,有人会问你的覆盖率统计数字,然后他们会问为什么你的覆盖率不高,然后有人会给你一个链接到一个伟大的UI测试包,自动化.在他们看来,他们已经从一个明显起作用的过程变成了一个需要付出更多努力才能达到同样的最终结果的过程,也就是他们以前交付的同样的工作代码。
发布于 2012-08-10 04:55:42
日常构建是针对遵循敏捷实践的项目。它不适用于瀑布模型。
我要说的是:纯粹的瀑布并不适用于那些一生都很小的琐碎项目,以至于每天建立一个庞大的建筑都会变得过于庞大。但是,如果您的项目生命周期至少是几个月,而且您的意思是“循环循环的瀑布”,那么当然每天构建都是有意义的。即使在经典的瀑布中,您有一个分析、一个设计和一个开发阶段,在开发阶段,您也必须进行大量的构建和代码集成,那么为什么不将其自动化并确保代码更改每天集成呢?
持续集成需要自动化测试
胡说,CI可以集成自动化测试,但这不是一个要求。您仍然可以手动测试,并且只可以使用CI来确保为测试人员准备好每天的构建。
其中一个人认为没有必要进行配置管理。
如果您有一个项目,您的产品的生命周期在1.0版本之后结束,那么这是正确的。在所有其他情况下,您应该有某种配置管理。但这与CI无关。此外,CI鼓励您将您对代码库的更改保持在较小的范围内,并每天重新集成--这正是您在这里反对它的理由。
即使他们为整个构建和刻录到cd过程创建脚本,创建自动化测试也是一个问题。
见我的评论,CI不需要自动测试。
至于你的其他观点:
你不可能总是知道你需要运行哪些测试
所有的人还有什么?
编写测试用例需要花费太多的时间。
您应该编写这些测试用例的脚本,在这些测试用例中一遍又一遍地手动应用它们需要花费太多的时间,因此将它们自动化将节省您的时间。
自动化测试工具可能并不总是支持特定类型的测试。
因为有一些可能的测试您有问题要自动化,所以什么都不自动化吗?听起来不太令人信服。谁告诉你自动化测试需要特殊的工具?我只是在没有任何工具的情况下开始工作,或者只使用一些轻量级的xUnit框架。
https://softwareengineering.stackexchange.com/questions/160277
复制相似问题