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.