每日构建vs.零缺陷

Question

您如何进行日常构建并努力实现零缺陷环境？这是否意味着我永远不能回家，直到我消除了新代码中的所有bug？或者，这是否意味着我在完全测试代码之前不会重新签入代码，这会使代码在更长的时间内进行有效的分支？

我是第一次和几个程序员一起工作(而不是自己工作，或者只和其他一个程序员一起工作)，所以我只是第一次与这样的决定搏斗。我们应该采用软件开发过程吗？

Answer 1

是的，请采用软件开发流程。有很多种，我相信不止一种适合你的团队。即使一个不是完美匹配的进程也比根本没有进程要好得多。

那么，我的公司如何进行日常构建并努力实现零缺陷呢？在签入代码之前，我们先运行测试套件。对我们来说唯一的问题是，测试套件的完整运行需要超过72小时，所以在签入代码之前，我们运行有限的单元测试集。对于我们的夜间构建，我们运行一组测试，运行时间约为8小时。然后在周末我们运行完整的测试套件。每个阶段都会捕获越来越多的问题，但超过90%的问题是通过5分钟的开发人员测试捕获的，而可能超过98%的问题是通过夜间测试捕获的。这仍然会在问题出现之前提前提醒我们，并且需要花费大量的时间来修复。

Answer 2

简单:永远不要签入带有(已知)错误的代码。这并不意味着你每天签到一次。当您实现了一个有意义的更改时，请检查，以便其他开发人员可以访问它。

我们总是在本地集成，针对代码运行测试，当所有测试都通过时，我们就签入。在工作时，我一天大约要签到20-30次。构建服务器获取更改，并针对系统运行构建。持续集成(CI)是一件好事。:D

持续集成-自动构建

从成功构建开始，并尽可能保持这种状态。这在团队环境中是必不可少的。只需记住，构建将会中断。预计它们每隔一段时间就会崩溃。这是一个迹象，表明您只是无意中签入了一些错误的东西，并且您停止了正在做的事情，以使构建再次变得绿色。从未破坏过构建的构建服务器是一个警告信号！

我也同意chadmyers的回答:无论你做什么决定，它都需要自动化和自动化。自动化工具为你做这类事情的最好的事情是，你不再需要考虑它或记住去做它。或者就像查德说的，你不会停止的。我可以推荐一些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

为自动化构建使用一个好工具

.NET领域的大多数人使用NAnt或MSBuild脚本进行自动化构建，稍后可以将这些构建挂接到他们的CI服务器上。如果你刚刚开始，我的建议是使用UppercuT，它是一个非常容易使用的使用NAnt的构建框架。这里有第二个链接，有更深的解释：UppercuT。

针对主动开发的分支与主干

您不需要分支，除非您只为发布版本保持主干开放(这意味着其他每个人都在与您相同的分支中工作)。但我会在主干和活动开发分支上都有CI。

软件开发过程

同样，为了回答关于软件开发过程的问题，答案是响亮的是。但是，除非需要大刀阔斧的改变，否则不要急于做任何事情。选择您想要迁移到的流程，并慢慢开始采用流程。评估，评估，评估。如果特定的流程对你的团队不起作用，找出是你做错了什么，还是你只是需要消除它。然后就去做。无论你最终得到的是什么，都需要对你起作用，否则就不会起作用。

Answer 3

这意味着进行小得多的提交。你提交工作修订的次数越多，你自己的工作副本被破坏的频率就越低。迭代开发从您开始。