上文说到，小艾在安装测试组经过一段时间的学习和实践之后，对安装测试已经有了一定的了解，就在此时，构建组急需一名有安装测试背景的帮手，小艾就这样被派往构建组帮忙起来。
尽管小艾对此很欣喜，但对构建组的一无所知，也令他对未来的工作有着些许迷茫，爱询问的小艾一进到构建组，便找到构建组的负责人问出了心中的疑问。
软件是怎么做出来的？
Java EE的应用软件开发过程是一个漫长的生命周期，从最初的需求分析，到最后的成品，中间有许多环节，开发人员写代码只是众多环节中的一个。产品构建也是其中一个非常重要的环节，任何软件开发都不可或缺。
构建的基本流程
1. 开发人员在个人计算机中编写源代码文件。
2. 编好的文件统一存放，构建组将所有源码编译成可以在任何计算机中运行的二进制文件，且用安装工具将各种需要安装到用户服务器上的文件包装成可以安装到不同平台的软件包。构建过程好比组装生产线，源码文件如同各种大小配件存储于大仓库中。
3. 经过生产线的各道工序，最终组合成产品。
构建是不间断地反复生产同一产品的不同版本，但只有最后一个通过了所有测试的版本会成为提交给用户的最终产品。构建过程示意图如下：
当建立一个新的构建软件”生产线“时，软件开发部门，特别是构建测试团队需要考虑：
1. 储存源码的”仓库“
2. 可以反复生产的"流水线"
3. 快速简单的测试以保证产品可以全面深入地测试和利用系统备份技术来分享测试环境。
构建原材料的管理——代码的管理
前面说过，源代码是构建过程的基础，也是软件开发公司的宝贵财产，因此，任何软件开发公司首先要想到的就是如何将源代码放在安全可靠的地方。
一般来讲，源代码会被存放在数据库里，且运用版本控制系统管理源代码，比如CVS, SVN, Git（原文并没有提到Git, 但作为分布式版本控制，Git的优势可以说深入人心，所以这里还是决定列出来~）等。版本控制系统可以用来帮助我们记录文件更改的过程及细节。
版本控制系统一般都基于客户端/服务器(Client/Server)的结构。版本控制可以同时为多个开发人员提供服务，也可以进行安全方面的设置。
版本控制的功能
版本控制一般都具有的功能包括：创建新文件，提取文件，存入新版本文件，协调或控制多人对同一文件的同时修改（集中式的版本控制具有此功能，若使用Git，可以允许多人对同一文件进行同时修改，但check-in时会让开发人员进行手动解决冲突的操作，因此这也是作为Git深入人心的优势之一），记录文件的修改历史并提供查询。
构建的环境
当某个阶段的源码都已经准备好，就可以构建这个阶段的测试产品了，构建产品的前提条件是建立构建的环境，此时需要考虑的因素有：
1. 选择构建使用的服务器
2. 选择构建环境平台
3. 构建所需要的软件或工具
下图为软件开发的一般流程，从中可以看出构建环境的搭建在软件开发中的重要性：
1. 开发人员编写软件代码，将源码提交给构建组进行构建
2. 构建组将源码做成可以安装的软件产品，交给测试组进行测试
3. 测试组将测试时的问题反馈给开发组
4. 开发组修改代码，再将修改后的代码交给构建组进行新版本的构建。
从上面描述的来看，小艾发现构建过程似乎会成为软件开发的瓶颈之处，在进行构建的时候，可能开发人员及测试人员都需要等待新的测试产品来进行下一步工作。构建组负责人肯定了小艾的猜想，也告诉小艾，优化和稳定构建过程是在建立环境时应重点考虑的因素。
上面的图中还有一条虚线，表示开发人员有时会将修复的补丁直接交给测试人员，而不通过构建组，其实这只是临时方法，不能算测试通过，若补丁安装合理正确，倒是可以帮助测试组减少对构建组的依赖，从而减少构建过程的瓶颈问题，也可以帮助我们在提交源码前确认质量，减少构建测试的失败机会。
一般而言，为了提高效率、保证安全，可以搭建多个具有相同或不同构建环境平台的服务器，若条件允许，一般提倡尽量利用多个平行构建过程。
其他因素
在构建环境时，还需要考虑的一些其他因素：
1. 构建环境应与开发环境分离。
2. 构建环境应与开发环境保持一致性
3. 记录好建立及修改构建环境的步骤及细节。
整体构建和部分构建
总的来说，整体构建是由许多部分构建所构成的，也就是说，整体构建可以被分解为许多小的构建步骤：
部分构建甚至是组成部分构建的更小更细的构建步骤，都可以反复多次单独运行。理想的构建过程是：可以根据需要，在任何中断或者出现错误的地方能够重新开始构建的过程。如下图：
从源代码文件变化历史和整体构建结构可以产生部分构建结构，从而可以只做部分构建而完成与进行整体构建一样的功能，即完成产品的完整构建。每个源代码文件及构建步骤时间的关系是设计部分构建逻辑的关键，一般版本控制系统都支持查询阶段间源代码文件的变化，这保证了部分构建的可行性：
多个部分构建组合可以构成最后的整体构建，好处有以下几个方面：
1. 如果有关的源代码自上一次构建没有改变，构建可以被跳过
2. 部分构建之间如果没有前后顺序关系，可以让它们同时运行来缩短构建时间
3. 部分构建所产生的二进制代码可以直接应用到测试环境中来快速检验新的产品功能，如果测试通过，部分构建代码会进入下一个版本的测试产品。
自动化的构建
为了避免让构建过程成为软件开发的瓶颈，缩短构建的时间和减少构建过程中的问题是非常重要的。实施自动化的构建是其中一个非常重要的方法。自动化的构建可以保证软件开发过程中能够定制比较灵活的构建时间表，也可以确保每一次构建过程的一致性。
实现构建自动化的一般原则：
1. 在源代码文件改变时，比如新文件的加入或文件的删除，不需要构建程序的改变，即使有不可避免的改变，也应使过程尽量容易、简单。
2. 避免把输入或输出的相关参数直接硬编码在代码中。
3. 经常需要改变的一些变量应采用属性文件来统一管理。
4. 使用Template文件及扩展样式表转换语言(XSLT), 在构建运行时根据构建需要生成构建程序文件。
模拟翻译构建
企业级的应用产品往往支持多国语言，因此构建应该考虑多国语言的源码构建。
源码文件的翻译一般要等到产品的开发到达一定阶段之后进行。通常会将英文版的文件锁定，以便跟踪自翻译工作开始后英文版文件的改变。这样可以节省软件开发过程中翻译工作的开支。但这种方式却引入了翻译文件不能即时被测试的风险。
为了使在翻译文件存在之前能尽早测试软件的国际化功能，一般可以进行模拟翻译，并将模拟翻译文件装到测试系统代替翻译文件进行测试。
模拟翻译是通过一种工具产生与翻译后的文件尽可能一致的文件。因此，模拟翻译构建过程是指运用工具来模拟翻译过程：
在模拟翻译构建的实践中，需要考虑如下因素：
1. 选用接近于翻译过程的模拟翻译工具
2. 模拟构建的步骤与产品的构建过程要保持一致
3. 由于模拟翻译为内部使用，可以简化处理，如将模拟翻译构建产生的文件包简化为ZIP文件包，解压后直接复制进行测试，从而节省构建开支，且能够快速响应。
构建的范围和频率
在实际构建过程中，应根据实际需求来定义构建范围和频率。
更频繁的部分构建以加快新的功能测试，较不频繁的整体构建来保证诸如安装等测试需要。
对于很少或几乎不变的源码构建，甚至可以将其构建的二进制代码或其他构建结果存放在版本控制系统，在每一次的常规构建过程中略去。
软件构件的频率通常是根据软件测试的需要而定的，一般来讲，最大可能地保证构建的频率是软件敏捷开发模型中的一个很必要的保证。
尾声
听构建组负责人说了这么多之后，小艾已经明白了构建测试的基本知识，在接下来的实践和学习中，小艾自己试着总结了构建测试的相关知识，关于他总结的内容，我们下回分解~
想要第一时间看到这一系列文章的更新及更多精彩内容可以扫描下面二维码关注微信公众号: 倚楼听风雨的如月
