[ca] 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.

[en] 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.