每日构建与零缺陷

简单:永远不要使用签入代码 (已知) 里面有虫子。这并不意味着你每天登记一次。当您实现了一个有意义的更改时签入,以便其他开发人员可以访问它。

持续集成-自动化您的构建

我也同意查德迈尔斯的回答:无论你决定什么,它都需要自动化。自动化工具为你做这类事情最好的一点是,你不再需要考虑或记住去做。或者像查德说的,你不会停止做。 我可以推荐使用CI工具,但请看这里: What tools do you use for Automated Builds / Automated Deployments? Why?

一旦你有了CI,如果你能通过引入一个坏的构建令牌来注入一些幽默(和羞耻),你就可以获得更高的质量! http://ferventcoder.com/archive/2008/08/20/continuous-integration-enhancement--the-broken-build-token.aspx

使用良好的工具进行自动构建

NETLand中的大多数用户使用NAnt或MSBuild脚本进行自动生成,以便以后可以将其连接到CI服务器。如果您刚刚开始,我的建议是使用 UppercuT ,它是一个非常容易使用的构建框架,使用NAnt。下面是第二个链接,有更深入的解释: UppercuT .

积极发展的分支与主干

除非只在发布时才打开主干(这意味着其他所有人都与您在同一个分支中工作),否则您不必进行分支。但我会在主干和主动开发分支上使用CI。

软件开发过程

同样要回答关于软件开发过程的问题,答案是响亮的“是”。但除非需要大幅度的改变,否则不要急于做任何事情。选择一个您想要迁移到的流程,然后慢慢开始采用流程。评价,评价,评价。如果特定流程对您的团队不起作用,请找出您是否做错了什么,或者您是否只需要消除它。然后去做。无论你最终有什么样的过程,都需要为你工作,否则就行不通。

那么,我的公司如何进行日常构建并努力实现零缺陷呢?我们在签入代码之前运行测试套件。对我们来说,唯一的问题是测试套件的完整运行需要超过72小时,因此我们在签入代码之前运行一组有限的单元测试。对于我们的夜间构建,我们运行一组测试,运行大约需要8小时。然后在周末我们运行完整的测试套件。每个阶段都会遇到越来越多的问题,但90%以上的问题是在5分钟的开发人员测试中发现的,而98%以上的问题是在夜间测试中发现的。这仍然很早就提醒了我们问题的出现,而这些问题还没有出现在我们的客户面前,并且需要花费大量的时间来解决。

这意味着要做出更小的承诺。您提交工作修订的频率越高,您自己的工作副本被破坏的频率就越低。迭代开发从您开始。

尽早整合,经常整合,快速整合。而不是“每日构建”,每次有人提交时构建,并经常提交(至少每天一次,最好超过2次)。

重要提示:对于低缺陷,快速反馈是必要的。如果你的构建需要很多分钟甚至一个多小时,最终你会讨厌这个构建,学会避免它,尽可能少地运行它,等等。它的价值会迅速下降到一文不值的地步,你的缺陷数量会开始飙升。

提前投入一些时间让构建快速运行。如果有慢的东西,找出它慢的原因并消除它。如果不能,那么至少设置一个级联构建,使构建的其余部分运行得很快(想想<2-5分钟),然后长时间运行的东西可以立即跟进,并花费它想要的时间(尽管尽量将其保持在10米以下)。

说得不够:快速的变化反馈周期非常重要!

诀窍是尽可能多地签入,只是通过了一些测试,很好地签入!修复了一个bug,请登录! 尝试找到可能的小增量,并将其签入!这样做还有一个额外的好处,那就是可以方便地编写实际相关的签入注释,这是一个不错的奖励。

当然,这要求您拥有一个比夜间更频繁构建的CI环境,尽可能频繁地构建是最好的选择。

哦,记住,如果是的话 从不 休息一下,那你就做错了。(也就是说,你过于保守,偶尔会有一点破坏,这只能表明你有希望推动它。)

如果你不回家,直到你所有的缺点都消失了,那么你永远不会回家。

我的想法是,每天的构建应该在某些时候实现自动化。在此之前未签入的任何代码都不会生成,如果有人连续两天未签入(生成),则生成系统应通知他们和技术负责人,因为这是一个警告标志。

一种可能更实用的方法是主干上没有缺陷,分支用于所有开发,然后在主干和分支上都可以进行日常构建,但是零缺陷不适用于开发分支。

通过查看答案,我很惊讶没有人提到测试驱动开发。如果你的目标是零缺陷,那就是最好的起点。

之后,我强烈推荐结对编程。

continuous integration is an attitude not a tool . 保持代码正常工作的团队承诺是关键。

关于零缺陷策略:如果代码中存在已知的bug,您可以回家。更重要的是,在实现新功能之前,缺陷应该得到修复。

这不能适用于整个团队,但是如果一个开发人员分配了一个bug,那么这个bug优先于开发人员必须创建的新特性。

根据您正在构建的内容,采用不允许缺陷的方法可能不合适。我个人的观点是,它很少,如果有的话,是。

允许缺陷存在可以让你专注于更重要的事情——例如,如果你在一个版本中只有有限的时间,那么你可能没有时间修复所有的东西以及获得所有的功能,因此如果要在修复十个边缘小缺陷之间做出选择,或者创建一个增值功能,那么务实的选择可能是附带已知的bug。

我并不是说零缺陷是一个坏主意——事实上,我们在每个发布周期结束时都会努力做到这一点——但就像软件开发中的许多事情一样,实用主义在现实世界中通常比清教徒主义更有效。

我会在CI参数上使用@feverentcoder。慈是你的朋友,让他帮你吧!

至于分支/主干点-每个人都应始终在 大旅行箱 标签

当涉及到流程时,发现 这些都与您相关,然后围绕它们构建微流程。此外,仅使用您认为可以提高生产率的实践/流程。最后,要勇敢——试着练习一两周,看看它是否对你有效;如果没有,扔掉它。你又学会了一种方法 做一个灯泡!