Managing Software Build Inflation

点击翻译按钮获取中文摘要

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.