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