您如何进行日常构建并努力实现零缺陷环境？这是否意味着在我杀死新代码中的所有错误之前我永远不会回家？或者它是否意味着我只是在我完全测试它之前不再检查我的代码，这使得代码有效地分支了更长的时间？
我第一次与少数程序员合作（而不是单独工作，或只与其他一个程序员一起工作），所以我只是第一次与这样的决定搏斗。我们应该采用软件开发流程吗？
答案 0 :(得分：15)
简单：永远不要使用（已知）错误来检入代码。这并不意味着您每天登记一次。在您实施有意义的更改时签入，以便其他开发人员可以访问它。
我们总是在本地集成，对代码运行我们的测试，当所有通过时，我们都会检查。我在工作时每天检查大约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。
除非您仅为发布版本打开trunk（这意味着其他所有人都在与您相同的分支中工作），否则您不必进行分支。但我会在主干和活动开发分支上都有CI。
同样回答关于软件开发过程的问题，答案是肯定的。但除非需要进行大幅度的改变，否则不要急于做任何事情。选择要迁移的流程，然后慢慢开始采用流程。并评估，评估，评估。如果特定过程对您的小组不起作用，请确定您是否做错了或者只是需要消除它。然后呢。无论你最终需要什么过程都需要为你工作，否则它将无法工作。
答案 1 :(得分：6)
是的，请采用软件开发流程。那里有各种各样的，我相信不止一个适合你的团队。即使是一个不完美匹配的东西也比没有完全匹配好得多。
那么我的公司如何进行日常构建并努力实现零缺陷？我们在检查代码之前运行测试套件。对我们来说唯一的问题是我们的测试套件的完整运行时间超过72小时，因此我们在检入代码之前运行一组有限的单元测试。对于我们的夜间构建，我们运行一组测试，大约需要8个小时才能运行。然后在周末我们运行完整的测试套件。每个阶段都会遇到越来越多的问题，但是超过90％的问题都是在5分钟的开发人员测试中发现的，而夜间测试可能会超过98％。在他们向我们的客户出去并且需要花费很多钱来修复之前，这仍然会让我们很早就发现问题。
答案 2 :(得分：4)
这意味着提交更小的提交。您提交工作修订的频率越高，您自己的工作副本就越少被破坏。迭代开发始于你。
答案 3 :(得分：3)
早期集成，经常集成，快速集成。每次有人经常提交和承诺（至少每天一次，最好超过2次），而不是“每日构建”。
重要提示：低缺陷需要快速反馈。如果你的构建需要花费很多分钟甚至超过一个小时，最终你会变得讨厌构建，学会避免它，尽可能少地运行它等等。它的价值迅速下降到无价值且你的缺陷数量将会开始暴涨。
预先投入一些时间让您的构建快速运行。如果有慢的东西，找出它为什么慢，并消除它。如果你不能，那么至少设置一个级联构建，以便构建的其余部分变得快速（想想<2-5分钟），并且长时间运行的东西可以在之后立即跟随并且只要它想要（尽管尽量将它保持在10米以下。）
说不够：变化的快速反馈循环非常重要！
答案 4 :(得分：2)
诀窍是尽可能经常办理登机手续，只是让一些测试通过，好好检查一下！修复了一个bug，检查一下！ 尝试找到可能的小增量并检查它！这有一个额外的好处，实际上使写入签名评论实际上是可能的和有意义的，这是一个很好的奖金。
当然要求你拥有一个比夜晚更频繁建造的CI环境，尽可能经常是最好的选择。
哦，记住，如果永远不会打破，那么你做错了。 （即你过于保守，现在有点破损，然后才表明你有希望推动它。）
答案 5 :(得分：1)
如果你没有回家，直到你的所有缺陷都消失了，那你永远不会回家。
我对此的看法是每日构建应该在某些时候自动化。在此之前未签入的任何代码都没有构建，如果连续2天（构建）没有来自某人的签名，那么构建系统应该通知他们和技术主管，因为这是一个警告标志。
答案 6 :(得分：1)
一种可能更实用的方法是在主干上有零缺陷，并为所有开发分支，然后在主干和分支上都可以进行每日构建，但零缺陷不适用于开发分支。
虽然让你的分支打破它的构建可能仍然存在一定程度的耻辱，但它比打破行李箱更不是一个问题。
答案 7 :(得分：1)
关于零缺陷策略：如果您的代码中存在已知错误，您可以回家。更重要的是，在实现新功能之前，应该修复缺陷。
这不一定适用于整个团队，但如果开发人员分配了错误，那么该错误优先于开发人员必须创建的新功能。
答案 8 :(得分：1)
通过答案我很惊讶没人提到测试驱动开发。如果您的目标是零缺陷，那么这是最好的起点。
之后我强烈推荐配对编程。
最后要明白像CruiseControl这样的工具很有用，但正如Jim Shore所说，continuous integration is an attitude not a tool。小组致力于保持代码的正常运行。
答案 9 :(得分：0)
根据您正在构建的内容，采用不允许存在缺陷的方法可能不合适。我的个人意见是，它很少，如果有的话。
缺陷管理系统的关键在于 - 允许您管理缺陷。如果缺陷是显示停止的那么肯定，你可能不想检查它，但如果它是一个小的或边缘的情况，那么只要你'检查已知的缺陷可能是有意义的重新跟踪它。
允许存在缺陷让您专注于更重要的事情 - 例如，如果您在发布中只有有限的时间，您可能没有时间修复所有内容以及获取所有功能，所以如果它是在修复十个边缘小错误或创建一个增值功能之间做出选择，然后务实的选择可能是附带已知的错误。
我并不是说零缺陷是一个坏主意 - 事实上我们在每个发布周期结束时都会努力 - 但就像软件开发中的许多事情一样，实用主义在现实世界中通常比清教主义更好。
答案 10 :(得分：0)
我会在CI参数上使用@feverentcoder。 CI是你的朋友，让他来帮助你！
至于分支/主干点 - 每个人都应该始终使用主干，分支 es用于尖峰和POC，标记全部版本
当涉及到流程时，找到与您相关的实践通常是有益的，然后围绕它们构建微流程。此外，只使用您认为可以提高生产力的那些实践/流程。最后，要勇敢 - 尝试一两个星期的练习，看看它是否适合你;如果没有，扔掉它。你刚刚学会了另一种不来制作灯泡的方法！