我们如何进行日常构建并努力实现零缺陷环境？这是否意味着直到我杀死了新代码中的所有错误之后，我再也无法回家？还是这意味着我只是在完全测试完代码之后才将代码重新签入，从而使代码有效地分支了更长的时间？

我是第一次与少数程序员一起工作(而不是自己工作，或者仅与另一个程序员一起工作)，所以我只是在第一次像这样的决策中苦苦挣扎。我们应该采用软件开发流程吗？

解决方案

简单：永远不要检入其中包含(已知)错误的代码。这并不意味着我们每天要签入一次。检入何时实施了有意义的更改，以便其他开发人员可以访问它。

我们总是在本地集成，对代码进行测试，所有通过后，我们都会检入。我每天工作约20-30次。构建服务器接收更改，并针对系统运行构建。持续集成(CI)是一件好事。 ：D

持续集成-使构建自动化

从成功构建开始，并尽可能保持这种方式。这在团队环境中至关重要。请记住，构建会中断。预计它们会每隔一段时间破碎一次。这表明我们无意中检查了一些不好的东西，然后停止了重新构建版本的操作。从未中断过构建的构建服务器是一个警告信号！

我也同意chadmyers的回答：无论我们决定什么，它都必须是自动的和自动化的。自动化工具来为我们执行此类操作的最好的事情是，我们不必再考虑或者记住这样做。或者像乍得所说的那样，我们不会停止这样做。
我可以为CI工具推荐一些建议，但请看这里：我们将哪些工具用于自动构建/自动部署？为什么？

获得CI后，如果通过引入损坏的构建令牌注入一些幽默感(和耻辱感)，则可以获得更高的质量！ http://ferventcoder.com/archive/2008/08/20/continuous-integration-enhancement--the-broken-build-token.aspx

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

.NET领域中的大多数人使用NAnt或者MSBuild脚本来进行自动化构建，之后可以将其连接到CI服务器。如果我们刚刚开始，我的建议是使用UppercuT，这是使用NAnt的易于使用的构建框架。这是具有更深层解释的第二个链接：UppercuT。

分支机构与主干进行主动开发

除非我们仅将主干打开以发布版本，否则我们将不必分支(这意味着其他所有人都在与我们相同的分支中工作)。但是我会在主干和活动开发分支上同时使用CI。

软件开发流程

还要回答有关软件开发过程的问题，答案是肯定的。但是，除非需要进行彻底的更改，否则请不要着急。选择要迁移的流程，然后慢慢开始采用流程。并进行评估，评估，评估。如果特定的流程不适用于小组，请确定我们做错了什么还是只需要消除它。然后做。无论我们最终遇到什么过程，都需要为我们工作，否则它将不起作用。

如果我们直到所有缺陷都消除后才回家，那么我们将永远不会回家。

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

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

虽然让分支破坏其构建可能还会有一定程度的污名，但与破坏主干相比，这没有什么问题。

是的，请采用软件开发过程。那里有各种各样的产品，我敢肯定，团队将不胜枚举。即使不是最完美的匹配，也比根本没有流程要好得多。

那么，我的公司如何进行日常制造并努力实现零缺陷？在签入代码之前，我们先运行测试套件。对于我们来说，唯一的问题是我们的测试套件的整个运行需要72个小时以上，因此我们在检入代码之前运行一组有限的单元测试。对于我们的每晚构建，我们运行一组测试，这些测试大约需要8个小时才能运行。然后在周末我们运行完整的测试套件。每个阶段都会遇到越来越多的问题，但是5分钟的开发人员测试捕获了90％以上的问题，而夜间测试则捕获了98％以上的问题。这仍然可以很早地提醒我们注意问题，然后再联系我们的客户，并且要花很多钱才能解决。

早期集成，经常集成，快速集成。而不是"每日构建"，而是每次有人提交并经常提交(每天至少一次，最好是两次以上)时进行构建。

重要提示：对于低缺陷，需要快速反馈。如果构建需要花费几分钟甚至一小时以上的时间，最终我们会讨厌该构建，学会避免使用它，尽可能少地运行它，等等。它的价值迅速下降到一文不值，缺陷数将不断增加。开始暴涨。

提前花一些时间来使构建快速运行。如果有缓慢的东西，找出它为什么缓慢，并消除它。如果不能这样做，那么至少要建立一个级联的构建，以便构建的其余部分可以快速进行(请考虑<2-5分钟)，并且长期运行的内容可以紧随其后并随其所需而用(尽管尝试一下)使其保持在1000万以下)。

不能这么说：快速的变更反馈周期非常重要！

这意味着进行更小的提交。提交工作修订的次数越多，破坏自己的工作副本的机会就越少。迭代开发从我们开始。

诀窍是要尽可能频繁地签入，只是通过了一些测试，很好地签入！修复了一个错误，请检查！
尝试找到较小的增量，然后将其检入！这具有额外的好处，即可以切实可行地写出与实际相关的签入注释，因此这是一个不错的奖励。

当然，这要求我们拥有一个比夜间构建更频繁的CI环境，而在尽可能多的情况下，这实际上是最好的选择。

哦，请记住，如果它永不中断，则说明我们做错了。 (即，我们过于保守，时而有些破损，然后只是表明我们希望将其推开。)

根据我们要构建的内容，采用不允许出现缺陷的方法可能不合适。我个人的看法是，这种情况很少发生，甚至永远不会发生。

缺陷管理系统的全部目的就是要允许我们管理缺陷。如果缺陷是一处令人瞩目的缺陷，那么可以肯定，我们可能不想检入它，但是如果它是次要问题或者边缘情况，那么只要我们知道该缺陷，就可以将其与已知缺陷一起检入。重新追踪。

允许存在缺陷使我们可以专注于更重要的事情，例如，如果我们在发行版中只有有限的时间，则可能没有时间修复所有功能以及获得所有功能，因此，如果要修复10个，则可以选择边缘情况下的小错误，或者创建一项增值功能，那么实用的选择可能是附带已知的错误。

我并不是说零缺陷并不是一个坏主意，事实上我们在每个发布周期结束时都为此而努力，但就像软件开发中的许多事情一样，实用主义通常在现实世界中比纯粹主义者更有效。

我会在CI参数上使用@feverentcoder。 CI是朋友，让他！

至于分支/主干，每个人都应该始终在主干上工作，分支用于峰值和POC，标记所有发布

当涉及到流程时，通常最好先找到与我们相关的实践，然后围绕它们建立微流程。另外，仅使用我们认为可以提高生产率的实践/过程。最后，勇于尝试一两个星期的练习，看看它是否对我们有用；如果没有，请将其丢弃。我们刚刚学会了另一种不做灯泡的方法！

关于零缺陷策略：如果代码中存在已知错误，则可以回家。更重要的是，应该在实施新功能之前修复缺陷。

这不一定适用于整个团队，但是如果开发人员已分配了错误，则该错误的优先级高于该开发人员必须创建的新功能。

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

之后，我强烈建议配对编程。

最终了解诸如CruiseControl之类的工具很有用，但正如Jim Shore所说，持续集成不是一种工具。保持代码正常运行的团队承诺是关键。