Managing Software Build Inflation

每当开发人员将代码更改推送到版本控制系统时，持续集成（CI）服务器都会自动构建和测试项目的源代码，以便尽快检测错误并合并冲突。CI管道由一系列构建阶段组成（例如，“编译”紧跟着“测试”），每个阶段都包含一个或多个并行构建作业（例如，Java 6和7上的“编译”）。构建作业的行为是通过使用特定于领域的语言（如GNU Make）的构建脚本指定的。虽然从概念上讲，CI服务器被描述为为每个新的代码更改执行一次构建，但实际上它的角色要复杂得多。首先，像Mozilla这样的大型组织的构建仪表板总结了多个构建管道的结果。此外，对于给定的代码更改，每个这样的管道不是只运行一次，而是多次运行，因为在每个构建阶段，要运行多个作业，以涵盖软件特性的主要配置和代码库设计的运行时环境。软件产品应该支持的大量特性、操作系统、处理器模型等，产生了为给定代码更改而运行的构建作业的组合爆炸。CI构建的复杂性不仅使构建结果难以解释，而且还增加了组织的构建基础设施成本，这是一种我们称之为“构建膨胀”的现象。然而，并不是所有的构建都具有同样的价值。例如，由于平台相关的错误而导致单元测试构建作业失败将导致一个构建失败和N-1个构建成功。虽然每个额外的构建成功确实为组织提供了一些反馈，但开发人员实际上希望获得有关失败环境的更详细信息。由于即使是最大的开源或商业组织也不得不放弃为每个单独的代码更改运行构建的想法，本建议旨在开发创新的方法，以优化跨所有CI管道的构建成本，并改进跨配置和环境的构建失败的解释：(1)根据价值和成本对构建工作进行经验表征。(2)白盒构建作业调度方法的设计，允许跨功能和环境配置优化构建作业调度。(3)跨配置和环境的构建作业结果的可视化总结。(4)对依赖于配置的构建作业失败进行根本原因分析。鉴于CI管道在现代软件开发中的核心作用，我们的研究结果将直接适用于加拿大的行业，为大型软件公司（如Ubisoft， IBM和RIM）和小型中小型企业（如Savoir-Faire 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.