如何进行日常构建并努力实现零缺陷环境？这是否意味着我永远不能回家，直到我杀死了我新代码中的所有错误？或者这意味着我只是在完全测试代码之前不重新检查代码，这会使代码有效地分支更长的时间？
我是第一次和少数程序员一起工作（而不是独自工作，或者只和另一个程序员一起工作），所以我只是第一次在做这样的决定。我们应该采用软件开发过程吗？
简单：永远不要签入有（已知）错误的代码。这并不意味着你每天签入一次。当你实现了一个有意义的更改，以便其他开发人员可以访问它时，请登录。
我们总是在本地集成，根据代码运行测试，当一切顺利时，我们就会进行检查。我每天工作时大约检查20-30次。生成服务器接收更改并针对系统运行生成。持续集成（CI）是一件好事D
持续集成-自动化构建
从成功的构建开始，并尽可能保持这种状态。这在团队环境中是至关重要的。请记住，构建会崩溃。预计它们每隔一段时间就会断裂。这是一个迹象，表明你只是无意中检查了一些不好的东西，并且你停止了你正在做的事情，使建筑再次变绿。一个从未破坏过构建的构建服务器是一个警告信号！
我也同意chadmeyers的回答：无论你做什么决定，都需要自动化。自动化工具为你做这类事情最好的一点是，你不再需要思考或记住去做。或者就像Chad说的那样，你不会停止做。我可以建议您推荐CI工具，但请看这里：您在自动构建/自动部署中使用哪些工具？为什么？
一旦你有了CI，如果你能通过引入一个破碎的构建令牌来注入一些幽默（和羞耻），你就能获得更高的质量！http://ferventcoder.com/archive/2008/08/20/continuous-integration-enhancement--the-broken-build-token.aspx
使用一个好的工具进行自动生成
.NET领域的大多数人都使用NAnt或MSBuild脚本来实现自动化构建，以便以后连接到CI服务器。如果你刚开始，我的建议是使用Upperct，这是一个使用NAnt的非常容易使用的构建框架。这里有第二个链接，有更深入的解释：UppermT。
积极发展的分支与主干
除非您只为发布打开trunk（这意味着其他所有人都和您在同一个分支中工作），否则您不必进行分支。但我会在主干和活跃的开发分支上都有CI。
软件开发过程
同样要回答软件开发过程的问题，答案是肯定的。但是，除非需要大幅度的改变，否则不要急于做任何事情。选择一个要迁移到的流程，然后慢慢开始采用流程。评估，评估，评估。如果特定的过程对你的团队不起作用，弄清楚你是做错了什么，还是只需要消除它。然后去做。无论你最终采用什么过程，都需要对你起作用，否则就行不通了。
是的，请采用软件开发流程。有很多种，我相信不止一种适合你的团队。即使是一个不完美的匹配也比没有任何过程要好得多。
那么，我的公司是如何进行日常构建并努力实现零缺陷的呢？我们在签入代码之前先运行测试套件。对我们来说，唯一的问题是，测试套件的完整运行需要72个多小时，所以我们在签入代码之前运行一组有限的单元测试。对于我们的夜间构建，我们运行一组大约需要8小时的测试。然后在周末我们运行完整的测试套件。每个阶段都会遇到越来越多的问题，但超过90%的问题是通过5分钟的开发人员测试发现的，可能超过98%的问题是在夜间测试中发现的。这仍然很早就提醒我们问题，然后再将其告知我们的客户，并花费大量时间进行修复。
这意味着要进行更小的提交。你提交工作修订的频率越高，你自己的工作副本被破坏的频率就越低。迭代开发从您开始。
早期集成，经常集成，快速集成。与其说是"每日构建"，不如说是在每次有人提交时构建，并经常提交（每天至少一次，最好超过2次）。
重要提示：快速反馈对于低缺陷是必要的。如果你的构建需要几分钟甚至一个多小时，最终你会变得讨厌这个构建，学会避免它，尽可能少地运行它，等等。它的价值会迅速下降到毫无价值的地步，你的缺陷数量会开始飙升。
提前投入一些时间，让你的构建快速运行。如果有慢的东西，找出它慢的原因并消除它。如果你做不到，那么至少要设置一个级联构建，这样构建的其余部分就可以快速进行（想想<2-5分钟），并且长时间运行的东西可以立即跟进，并且需要多长时间（尽管尽量将其保持在10米以下）。
说得再多也不为过：对变化的快速反馈周期极其重要！
诀窍是尽可能频繁地签入，刚刚通过了一些测试，很好地签入了！修复了一个错误，请检查！试着找到可能的小增量并将其签入！这还有一个额外的好处，那就是可以方便地编写实际相关的签入评论，所以这是一个不错的奖励。
当然，这需要你有一个比夜间更频繁地构建的CI环境，尽可能频繁地构建确实是最好的选择。
哦，记住，如果它从未中断，那么你就做错了。（也就是说，你过于保守，偶尔会有一点破损，这只会表明你有希望推动它。）
如果你在所有缺陷都消除之前不回家，那么你永远不会回家。
我的想法是，日常构建应该在特定时间实现自动化。在此之前未签入的任何代码都不会构建，如果连续2天（构建）没有来自某人的签入，那么构建系统应该通知他们和技术负责人，因为这是一个警告信号，那么在主干和分支上都可以进行日常构建，但零缺陷不适用于dev分支。
虽然你的分支破坏了它的构建可能仍然会有一定程度的耻辱感，但这比破坏主干问题小。
仔细查看答案，我很惊讶没有人提到测试驱动开发。如果你的目标是零缺陷，那是最好的开始。
在那之后，我强烈推荐结对编程。
最后要明白，像CruiseControl这样的工具是有用的，但正如Jim Shore所说，持续集成是一种态度，而不是一种工具。关键是团队对保持代码工作的承诺。
关于零缺陷策略：如果代码中有已知的错误，您可以回家。更重要的是，在实现新功能之前，应该修复缺陷。
这一定不适用于整个团队，但如果一个开发人员分配了一个bug，那么这个bug优先于这个开发人员必须创建的新功能。
根据您正在构建的内容，采用不允许缺陷的方法可能是不合适的。我个人的看法是，它很少，如果有的话。
缺陷管理系统的全部意义正是——允许您管理缺陷。如果缺陷是一个令人惊叹的缺陷，那么当然，你可能不想检查它，但如果它是次要的或边缘情况，那么只要你在跟踪它，就可以用已知的缺陷检查它。
允许缺陷的存在可以让你专注于更重要的事情——例如，如果你在一个版本中只有有限的时间，你可能没有时间修复所有东西，也没有时间获得所有功能，所以如果是在修复十个边缘情况下的小错误还是创建一个增值功能之间做出选择，那么务实的选择可能是附带已知的错误。
我并不是说零缺陷是个坏主意——事实上，我们在每个发布周期结束时都会努力做到这一点——但就像软件开发中的许多事情一样，实用主义在现实世界中通常比清教主义更有效。
我会在CI参数上使用@feverentcoder。CI是你的朋友，让他来帮你吧！
至于分支/主干点-每个人都应该始终在主干上工作，分支用于尖峰和POC，tag所有版本
当涉及到流程时，找到与您相关的实践，然后围绕它们构建微流程通常是有益的。此外，只使用那些你认为可以提高生产力的做法/流程。最后，要有勇气——试着练习一两周，看看它是否对你有效；如果没有，就扔掉。你刚刚学会了制作灯泡的另一种方法而不是！