构建服务器的优势?

有很多优点,而不仅仅是更早地发现编译器错误(这是很重要的):

• 为每个签入生成一个完全干净的构建(或每天或无论如何配置)
• 生成一致的构建,因为之前的构建遗留的工件不太可能刚刚工作。
• 提供一个变更实际上破坏了构建的历史记录
• 为自动化其他相关流程(如部署到测试计算机)提供良好的机制。

• 持续集成揭示了全局中的任何问题,因为不同的团队/开发人员在代码/应用程序/系统的不同部分工作
• 在每个构建中运行的单元测试和集成测试更深入,并暴露出开发人员工作站上可能看不到的问题。
• 免费咖啡/糖果/啤酒。当有人破坏了构建,他/她会为其他团队成员弥补…

我认为如果你能说服你的团队成员,在开发期间会有错误和集成问题没有被暴露出来,那就足够了。

当然,你可以告诉他们,如果你不运行连续的构建,团队在现代世界看起来会很古老。

见 Continuous Integration: Benefits of Continuous Integration :

总的来说,我认为持续集成的最大和最广泛的好处是降低风险。我的思想仍然回到我在第一段中提到的早期软件项目。他们在那里完成了一个漫长的项目(他们希望如此),但却不知道还要多久才能完成。

…

因此,具有持续集成的项目在生产和过程中的错误都会显著减少。但是我要强调的是,这种好处的程度直接关系到您的测试套件有多好。您应该发现构建一个具有显著差异的测试套件并不太困难。然而,通常情况下,团队需要一段时间才能真正达到他们有可能达到的低级别的bug。达到这一目标意味着不断地努力和改进你的测试。

如果您有持续的集成,它将消除频繁部署的最大障碍之一。频繁的部署是有价值的,因为它允许您的用户更快地获得新功能,对这些功能提供更快的反馈,并且通常在开发周期中变得更加协作。这有助于打破客户和开发之间的障碍——我认为这是成功软件开发的最大障碍。

根据我的个人经验,建立一个构建服务器和实现CI过程,确实改变了项目的执行方式。生成一个构建的行为变成了一个平安无事的日常事情,因为你每天都在做。这可以让你更早地抓住事情并变得更敏捷。

还要注意,设置构建服务器只是CI过程的一部分,包括设置测试并最终实现部署自动化(非常有用)。

另一个经常不被提及的副作用是CI工具 CruiseControl.NET 成为所有分支(包括内部RCS)的所有版本号的中央颁发者。然后,您可以强制您的团队始终发送一个来自CI工具的构建,即使它是产品的自定义版本。

对损坏或不兼容代码的早期警告意味着所有冲突都会尽快识别,从而避免在发布日期出现最后一分钟的混乱。

• 当你的老板说“我需要一份最新的代码尽快”时,你可以在5分钟内把它交给他们。

• 您可以让内部测试人员很容易地使用这个构建,当他们报告一个bug时,他们可以很容易地告诉您“这是4月1日的夜间构建”,这样您就可以使用相同版本的源代码了。

• 您将确保有一种自动化的方法来构建代码,这种方法不依赖于库/环境变量/脚本等,这些库/环境变量/脚本是在开发人员的环境中设置的,但很难被其他想使用代码的人复制。

我们发现,自动VCS标记的确切代码,产生一个版本非常有助于回到特定版本复制问题。

整合是一个盲点
集成常常得不到任何尊重-“我们只是把二进制文件扔到一个安装工具中”。如果它不起作用,那是安装人员的错。

稳定的构建环境
防止诸如“这种错误有时会在乔的机器上出现”之类的借口。防止在Mikes机器上构建时意外使用旧的依赖库。

真正的恶作剧
您的内部测试人员和用户拥有真正的客户体验。您的开发人员对复制错误有明确的参考。

我的经理告诉我们需要设置它们有两个主要原因。没有人真正与最终项目有关,但要确保签入或处理的内容是正确的。

首先清理DLL地狱。当有人在本地机器上构建时,他们可以指向任何引用文件夹。很多项目都是从没有更新本地文件夹的人那里用错误版本的DLL构建的。在构建服务器中,它将始终由同一个源构建。你所要做的就是获取最新的参考资料。

对我们来说,第二件重要的事情是支持那些对项目知之甚少的项目。任何开发人员都可以去获取源代码,并在需要时执行一个小的修复。他们不必花数小时的时间设置或寻找参考资料。我们有一个海外团队,主要负责一个项目,但如果在我们工作的时间内有紧急修复,我们可以抓住最新的,并能够建立不必担心破坏源或什么没有得到登记。封闭式签入可以节省团队中的其他人时间。