Managing Software Build Inflation

每当开发人员将代码更改推送到版本控制系统时，持续集成(CI)服务器都会自动构建和测试项目的源代码，以尽快检测故障并合并冲突。CI管道由一系列构建阶段(例如，“编译”后跟“测试”)组成，每个阶段都包含一个或多个并行构建作业(例如，Java 6和7上的“编译”)。构建作业的行为是通过特定于域的语言(如GNU make)中的构建脚本指定的。 虽然在概念上，CI服务器被描绘为对每个新代码更改执行一次构建，但实际上它的角色要复杂得多。首先，像Mozilla这样的大型组织的构建仪表板汇总了多个构建管道的结果。此外，对于给定的代码更改，每个这样的流水线不是只运行一次，而是多次运行，因为在每个构建阶段，运行多个作业以覆盖为代码库设计的软件功能和运行时环境的主要配置。软件产品应该支持的大量特征、操作系统、处理器型号等产生针对给定代码更改运行的构建作业的组合爆炸。 随之而来的CI构建的复杂性不仅使构建结果更难解释，而且还增加了组织的构建基础设施成本，这是我们称之为“构建通货膨胀”的现象。然而，并不是所有的版本都具有同等的价值。例如，单元测试构建作业由于与平台相关的错误而失败，将导致一个构建失败和N-1个构建成功。虽然每一次构建成功都会向组织提供一些反馈，但开发人员实际上希望获得有关失败环境的更详细信息。 由于即使是最大的开源或商业组织也不得不放弃为每个单独的代码更改运行构建的想法，该提案旨在开发创新的方法来优化所有CI管道的构建成本，并改进跨配置和环境的构建失败的解释： (1)从价值和成本的角度对建筑作业进行经验表征。 (2)设计了白盒构建作业调度方法，允许跨功能和环境配置优化构建作业调度。 (3)跨配置和环境的构建作业结果的可视摘要。 (4)依赖于配置的构建作业失败的根本原因分析。 鉴于CI管道在现代软件开发中的核心作用，我们的研究成果将直接适用于加拿大行业，为育碧、IBM和RIM等大型软件公司以及萨凡菲尔Linux等较小的中小企业提供竞争优势。HQP将在经验研究技术和工业级CI系统方面获得丰富的实践经验，使他们有资格担任广受欢迎的构建和发布工程师的角色。

Continuous integration (CI) servers automatically build and test the source code of a project whenever a developer pushes a code change to the version control system, to detect faults and merge conflicts as soon as possible. A CI pipeline consists of a sequence of build stages (e.g., "compile" followed by "test"), each of which comprising one or more parallel build jobs (e.g., "compile" on Java 6 and 7). The behaviour of a build job is specified via build scripts in a domain-specific language like GNU Make. While, conceptually, a CI server is pictured as performing one build for each new code change, in practice its role is much more complex. First of all, the build dashboard of large organizations like Mozilla summarize results for multiple build pipelines. Furthermore, each such pipeline is not run just once for a given code change, but multiple times, since, in each build stage, multiple jobs are run to cover the major configurations of software features and run-time environments the code base is designed for. The large number of features, operating systems, processor models, etc. that the software product should support, yields a combinatorial explosion of build jobs to run for a given code change. The resulting complexity of CI builds not only makes build results harder to interpret, but also increases the build infrastructure cost for organizations, which is a phenomenon that we named "build inflation". Yet, not all builds are equally valuable. For example, a unit test build job failing due to a platform-dependent fault would lead to one build failure and N-1 build successes. While every additional build success does provide some feedback to the organization, developers actually would like to obtain more detailed information about the failing environments. Since even the largest open source or commercial organizations have had to abandon the idea of running builds for each individual code change, this proposal aims to develop innovative methodologies to optimize the cost of builds across all CI pipelines and to improve the interpretation of build failures across configurations and environments: (1) Empirical characterization of build jobs in terms of value and cost. (2) Design of white box build job scheduling approaches, allowing to optimize build job scheduling across feature and environment configurations. (3) Visual summaries of build job results across configurations and environments. (4) Root cause analysis of configuration-(in)dependent build job failures. Given the central role of CI pipelines in modern software development, our research results will be directly applicable by the Canadian industry, providing competitive advantages to both large software companies like Ubisoft, IBM and RIM, and smaller SMEs like Savoir-Faire Linux. The HQP will gain extensive hands-on experience with empirical research techniques and industry-grade CI systems that qualifies them for the much sought after roles of build and release engineers.