2010-03-02 102 views
24

我们知道这很好,但我发现自己向我的雇主证明了这一点。请仔细阅读为什么开发团队需要构建服务器。为什么我的开发团队需要构建服务器?

+1

非常感谢你们的回复,这里是原始问题的一个转折点。 我的雇主可以让机器做CI任务。我现在面临的挑战是证明为什么这台机器应该是独立的。我一直在使用整个公司用来测试的服务器,这意味着每个人都在搞这个。 我的观点是我们需要一个受控制的环境(就像弗拉基米尔指出的那样)。 你的想法是什么? 和 你更喜欢虚拟机还是专用机器? – 2010-03-07 01:25:05

+1

@ H。亚伯拉罕查韦斯:这是一个不同的问题。你应该把它作为一个新问题,而不是在评论中。 – 2010-03-09 17:25:00

回答

18

使用构建服务器有多种原因。没有特定的顺序,我的头顶上:

  1. 您简化了开发人员的工作流程,并减少了出错的几率。您的构建服务器可以处理多个步骤,例如查看最新代码,安装所需的软件等。开发人员在他们的机器上不会有一些可能会导致构建通过或失败的杂散DLL的机会。

    您的构建服务器可以复制您的目标环境(操作系统等),并且在开发人员的桌面上工作的几率较低,并且会破坏生产。

  2. 尽管开发人员测试他们签入的所有内容是一种很好的做法,但有时候他们却没有。那么最好在那里安装构建服务器来捕获测试错误,并让团队知道产品已经损坏。

  3. 集中式构建提供了对代码度量的简单访问 - 哪些测试通过了,哪些失败了,测试代码覆盖的频率如何,等等。对代码库的质量状态有深入的理解,可以减少维护并通过提供及时的反馈来测试成本,以便快速轻松地修复错误。

  4. 产品部署简化 - 开发人员或QA不必记住多个手动步骤。它可以很容易地自动化。

  5. 简化了开发人员与QA之间的链接。 QA人员可以到一个已知的位置去获取最新的,版本更新的版本。

  6. 设置发布分支的版本很容易,在发布阶段为产品提供额外的安全网,因为在更改代码时必须特别小心。

20

避免“但它适用于我的包装盒”问题。

有一个一致的,已知的环境,其中构建软件以避免依赖本地开发框。

如果需要,您可以使用虚拟服务器来避免(多)额外的成本。

4

ASAP知道什么单元测试目前正在工作,哪些没有;此外,你还会知道一旦通过单元测试开始失败。

3

这是一个持续的质量测试仪表板;它会向您显示关于软件质量如何的统计数据,并且现在向您显示。 (JUnit,Cobertura)

它确保开发人员不会受到其他开发人员破坏构建的阻碍,并鼓励开发人员编写更好的代码。 (FindBugs,PMD)

它通过第一次从开发人员获得更好的代码 - 在测试和重新测试中获得更少的代码 - 并通过从同一开发人员获得更多代码,因为它们更少,从而为您节省时间和金钱可能会彼此绊倒。

3

主要有两个原因非技术人员可以涉及到:

  • 因为问题先前确定它提高了开发团队的生产力。

  • 它使项目的状态非常明显。我已经向管理层展示了构建状态仪表板,现在他们一直在查看它。

还有一件事。像哈德森这样的东西设置起来非常简单 - 您可能只想在角落的某个地方运行一段时间,然后再显示它。

2

这是我的主要论点:

  • 所有正式发布必须建立在一个可控的环境。没有例外。

只是因为你永远不知道开发者如何创建他们的个人发布。

您也不需要谈论如“在手臂和腿上花费的刀片”那样构建服务器。我设置的第一台构建服务器是一台桌面机器,它在一个角落里拔掉。它为我们服务了3年多。

一个你有你的生成机器,你可以开始添加一些功能(哈德森是伟大的),并实施其他海报提到的一切。

一旦你的构建机器变得不可缺少对您的组织(和每个人看到它的好处),你就可以要求一个崭新的刀片,如果你想:-)

0

你可以做最简单的事情说服你的雇主有一个构建服务器是告诉他们他们将能够更快地发布更好的质量

更快的版本来自对构建质量的即时反馈。如果有人破坏了构建,他或她可以立即修复损坏的构建,从而避免构建和发布时间表的延迟。如果没有构建服务器,团队将不得不花费时间来查找发生什么事情以及如何解决问题。

更好的质量是通过构建服务器每次有人检查更改为版本控制系统时自动运行缺陷检测工具来实现的。你没有提及你的组织中主要的开发语言是什么,但是这些先进但商业和简单却免费的工具几乎适用于所有语言。想到Lint,FxCop,FindBugs和PMD。

您也可以查看此presentation on benefits of continuous integration进行更广泛的讨论。

相关问题