continuous-integration - 每日构建与零缺陷

Question

您如何进行日常构建并努力实现零缺陷环境？这是否意味着在我杀死新代码中的所有错误之前，我永远无法回家？或者这是否意味着在我完全测试完代码之前我不会重新检查我的代码，这会使代码有效地分支更长的时间？

我是第一次与少数程序员一起工作(而不是独自工作，或者只与其他编码员一起工作)，所以我只是第一次为这样的决定而苦苦挣扎。我们应该采用软件开发流程吗？

Answer 1

简单:永远不要使用 checkin 代码(已知)里面的 bug 。这并不意味着您每天签到一次。当您实现了有意义的更改时 checkin ，以便其他开发人员可以访问它。

我们总是在本地集成，针对代码运行我们的测试，当一切都通过时，我们 checkin 。我每天工作时 checkin 大约 20-30 次。构建服务器获取更改并针对系统运行构建。持续集成 (CI) 是一件好事。 :D

持续集成 - 自动化您的构建

从成功构建开始，并尽可能保持这种状态。这在团队环境中是必不可少的。请记住，构建会中断。预计它们每隔一段时间就会破裂。这表明您只是无意中 checkin 了一些不好的东西，并且您停止了正在执行的操作以使构建再次变绿。从未破坏过构建的构建服务器是一个警告信号!

我也同意 chadmyers 的回答:无论您决定什么，都需要自动化和自动化。自动化工具为你做这类事情的最好的事情是你不再需要考虑或记住去做。或者就像乍得说的，你不要停止这样做。
我可以推荐推荐 CI 工具，但请看这里:What tools do you use for Automated Builds / Automated Deployments? Why?

一旦你有了 CI，如果你可以通过引入一个损坏的构建 token 来注入(inject)一些幽默(和羞耻)，你可以获得更高的质量! http://ferventcoder.com/archive/2008/08/20/continuous-integration-enhancement--the-broken-build-token.aspx

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

.NET 领域的大多数人使用 NAnt 或 MSBuild 脚本来进行自动化构建，以后可以连接到他们的 CI 服务器。如果您刚刚开始，我的建议是使用 UppercuT ，它是一个非常容易使用的使用 NAnt 的构建框架。这是第二个链接，有更深入的解释:UppercuT .

主动开发的分支与主干

除非您只为发布版本打开主干(这意味着其他所有人都与您在同一个分支中工作)，否则您不必分支。但我会在主干和事件开发分支上都有 CI。

软件开发过程

同样要回答有关软件开发过程的问题，答案是肯定的。但是，除非需要进行剧烈的改变，否则不要急于求成。选择一个您想要迁移的流程，然后慢慢开始采用流程。评价，评价，评价。如果特定过程不适用于您的团队，请确定您是否做错了什么，或者您是否只需要消除它。然后做。无论您最终采用哪种流程，都需要为您工作，否则它将无法正常工作。