Search

Context Building past source code snapshots of a software product is necessary both for research (analyzing the past state of a program) and industry (increasing trustability by reproducibility of past versions, finding bugs by bisecting, backporting bug fixes, among others). A study by Tufano et al. showed in 2016 that many past snapshots cannot be built. Objective We replicate Tufano et al.’s study in 2020, to verify its results and to study what has changed during this time in terms of compilability of a project. Also, we extend it by studying a different set of projects, using additional techniques for building past snapshots, with the aim of extending the validity of its results. Method (i) Replication of the original study, obtaining past snapshots from 79 repositories (with a total of 139,389 commits); and (ii) Reproduction of the original study on a different set of 80 large Java projects, extending the heuristics for building snapshots (300,873 commits). Results We observed degradation of compilability over time, due to vanishing of dependencies and other external artifacts. We validated that the most influential error causing failures in builds are missing external artifacts, and the less influential is compiling errors. We observed some facts that could lead to the effect of the build tool on past compilability. Conclusions We provide details on what aspects have a strong and a shallow influence on past compilability, giving ideas of how to improve it. We could extend previous research on the matter, but could not validate some of the previous results. We offer recommendations on how to make this kind of studies more replicable.

Continuous integration systems allow for easy identification of build and test failures in software projects. However, in projects with many developers and deliverables, where the same code is used with different configurations for many different products, it is not easy to identify what changes in the code caused the failures. This usually results on involving a team to make sure that the failures are identified as soon as possible so the broken code can get reverted, and it does not affect future rounds. Early failure detection prevents the products which are going to be released to be faulty, and helps developers work with a stable codebase that will help them identifying the result of their modifications without the noise generated by other developers' issues. A way to solve this problem is developing a strategy that allows the build and test failures, and their root causes, to be identified automatically. The strategy must be based on the identification of possible candidates for the broken builds/tests, evaluating the changes between the last successful integration and the failing one. Furthermore, a strategy to evaluate if the offending commit (the one which caused the failure) should be automatically reverted or not could be developed, as well. The state of this project after the development phase demonstrates the possibility of developing a system capable of automating failure detection on a complex integration system, where manually finding the responsible changes of the failures can take from a few minutes from a few hours, meaning that the figure of a full time system integrator is needed. With the automated failure detection tool, finding the offending commits takes just a few seconds, making it much easier for the system integrator to revert the changes that caused the failure. Los sistemas de integración continua permiten identificar fácilmente los fallos de construcción y de prueba en los proyectos de software. Sin embargo, en los proyectos con muchos desarrolladores y entregables, en los que se utiliza el mismo código con diferentes configuraciones para muchos productos diferentes, no es fácil identificar qué cambios en el código causaron los fallos. Esto suele resultar en la participación de un equipo para asegurarse de que los fallos se identifiquen lo antes posible para que el código roto pueda revertirse, y no afecte a las futuras rondas. La detección temprana de fallos evita que los productos que se van a lanzar al mercado sean defectuosos, y ayuda a los desarrolladores a trabajar con una base de código estable que les ayudará a identificar el resultado de sus modificaciones sin el ruido generado por los problemas de otros desarrolladores. Una forma de resolver este problema es desarrollar una estrategia que permita identificar automáticamente los fallos de construcción y prueba, y sus causas fundamentales. La estrategia debe basarse en la identificación de posibles candidatos para las construcciones/pruebas fallidas, evaluando los cambios entre la última integración exitosa y la fallida. Además, también podría desarrollarse una estrategia para evaluar si el compromiso infractor (el que causó el fallo) debe revertirse automáticamente o no. El estado de este proyecto después de la fase de desarrollo demuestra la posibilidad de desarrollar un sistema capaz de automatizar la detección de fallos en un sistema de integración complejo, en el que la búsqueda manual de los cambios responsables de los fallos puede llevar desde unos minutos hasta unas horas, lo que significa que se necesita la figura de un integrador de sistemas a tiempo completo. Con la herramienta de detección automatizada de fallos, encontrar los responsables de estos lleva sólo unos pocos segundos, lo que hace mucho más fácil para el integrador de sistemas revertir los cambios que lo causaron. Traducción realizada con la versión gratuita del traductor www.DeepL.com/Translator Els sistemes d'integració contínua permeten identificar fàcilment les fallades de construcció i de prova en els projectes de programari. No obstant això, en els projectes amb molts desenvolupadors i lliurables, en els quals s'utilitza el mateix codi amb diferents configuracions per a molts productes diferents, no és fàcil identificar quins canvis en el codi van causar les fallades. Això sol resultar en la participació d'un equip per a assegurar-se que les fallades s'identifiquin al més aviat possible perquè el codi trencat pugui revertir-se, i no afecti les futures rondes. La detecció precoç de fallades evita que els productes que es llançaran al mercat siguin defectuosos, i ajuda als desenvolupadors a treballar amb una base de codi estable que els ajudarà a identificar el resultat de les seves modificacions sense el soroll generat pels problemes d'altres desenvolupadors. Una manera de resoldre aquest problema és desenvolupar una estratègia que permeti identificar automàticament les fallades de construcció i prova, i les seves causes fonamentals. L'estratègia ha de basar-se en la identificació de possibles candidats per a les construccions/proves fallides, avaluant els canvis entre l'última integració reeixida i la fallida. A més, també podria desenvolupar-se una estratègia per a avaluar si el compromís infractor (el que va causar la fallada) ha de revertir-se automàticament o no. L'estat d'aquest projecte després de la fase de desenvolupament demostra la possibilitat de desenvolupar un sistema capaç d'automatitzar la detecció de fallades en un sistema d'integració complex, en el qual la cerca manual dels canvis responsables de les fallades pot portar des d'uns minuts fins a unes hores, la qual cosa significa que es necessita la figura d'un integrador de sistemes a temps complet. Amb l'eina de detecció automatitzada de fallades, trobar els responsables d'aquests porta només uns pocs segons, la qual cosa fa molt més fàcil per a l'integrador de sistemes revertir els canvis que ho van causar.

Continuous Integration (CI) and Continuous Delivery (CD) are widespread in both industrial and open-source software (OSS) projects. Recent research characterized build failures in CI and identified factors potentially correlated to them. However, most observations and findings of previous work are exclusively based on OSS projects or data from a single industrial organization. This paper provides a first attempt to compare the CI processes and occurrences of build failures in 349 Java OSS projects and 418 projects from a financial organization, ING Nederland. Through the analysis of 34,182 failing builds (26% of the total number of observed builds), we derived a taxonomy of failures that affect the observed CI processes. Using cluster analysis, we observed that in some cases OSS and ING projects share similar build failure patterns (e.g., few compilation failures as compared to frequent testing failures), while in other cases completely different patterns emerge. In short, we explain how OSS and ING CI processes exhibit commonalities, yet are substantially different in their design and in the failures they report.