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