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

[es] 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