构建服务器是用来构建应用的专用机器。构建服务器通常称为持续集成服务器;这两个理念有点不同,但是它们通常都绑定在同一台服务器上。开发人员每次添加新代码,添加内容会通知到构建服务器。服务器会相应得从代码仓库里pull新代码,从头构建,并且运行所有单元测试。最终结果是包含当前所有最新代码的干净构建。
技术经理有时质疑构建服务器没用,因为似乎单个开发人员通过在本地机器上构建也能达到相同的结果。但是,构建服务器和开发人员自行构建方案相比有几个重要优势。
受控、独立、可重复
构建服务器确保只有合适的代码进入构建。开发人员在其本地机器上使用新的软件产品,工具库或者其他工具。安装和卸载这些工具可能会留下
一些DLL,它们可能会被误用到构建里。这会导致通常会遇到的那句话:“但是这个在我的机器上能构建。”没有检查的源码也经常会听到这句话。有了专用构建服务器时,如果在build服务器上无法构建,就一定是什么地方出问题了。
另一个构建服务器能防范的错误根源是创建一个发布构建,而不是调试构建。测试中,开发人员可能会构建包含额外嵌入信息的代码来辅助调试。这样的信息减缓执行速度,并且增加了应用的大小,但是在解决问题时又不可或缺。构建服务器能够被配置来以发布模式构建应用,这时会移除所有的调试信息,使得应用足够小并且足够快。构建还能轻松扩展,为多种目标硬件构建,比如32或者64bit。
强制执行单元测试
强制执行单元测试是构建服务器的另一个职责。开发人员在提交代码时很容易忘记运行单元测试,或者在变化很小时觉得不需要运行完整的单元测试。构建服务器能够强制验证单元测试是否成功,如果在构建过程中任何单元测试失败了,甚至会拒绝开发人员添加的代码。
应用通常要求更多时间和数据敏感的测试,称为集成测试。这些测试以某种方式和周围环境交互,通常会从数据库查询数据。一般来说,这些测试要求数据库服务器上存在着一些特别的数据集,以支撑测试通过。
不仅仅要求特别的设置,这些测试还通常需要很长的运行时间。正确配置的持续集成服务器能够存储一个测试数据库,其中配置好了合适的数据,然后运行集成测试。花费大量时间的测试可以安排在下班时间运行。
保证代码质量
构建服务器提供了中央控制点来衡量代码质量。在构建时,可以生成测试覆盖率指标及其他代码质量度量,提供进度和质量的增量分析。甚至可以在覆盖率下降到某个百分比时拒绝代码的更新。
QA团队的集中测试位置
构建服务器的一大优势不仅仅有利于开发人员。有了可用的构建服务器,QA团队能够准确了解需要测试的是哪个版本。他们还通过引入自动化测试工具来流水线自己的工作流。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
作者
Brad Irby has been a developer and systems architect since 1990, designing and implementing systems using the Microsoft stack.
相关推荐
-
防止重构问题最佳方法
在我们的“Ask The Experts”会话中,Brad Irby回答了这一问题:如何重构问题未发生之前防止它?
-
集成测试工具和服务一览
本文建议软件开发人员将评估集成于测试及某些现有工具,同时了解特定工具如何工作及能做什么。
-
代码审查是如何抹杀开发者积极性的?
代码审查本应该是相互合作/学习,整合团体动力,而大多数人则认为,他们看到的是它需要花掉一些人的一些额外的时间,那些本应该用来继续做开发的时间。
-
集成测试所面临的挑战
集成测试已经与我们并肩作战多年,但是它仍旧有点像虚空领域。一项服务如何同另一项服务交互,还有一项服务如何同软件栈中更深层的底层对象和功能进行交互依然是个谜。