Integración continua: requisitos
A continuación se muestra la lista de los requisitos más importantes para la integración continua.
Check-In Regularly- La práctica más importante para que la integración continua funcione correctamente son los controles frecuentes en el tronco o en la línea principal del repositorio de código fuente. El registro del código debe realizarse al menos un par de veces al día. Registrarse regularmente trae muchos otros beneficios. Hace que los cambios sean más pequeños y, por lo tanto, es menos probable que se rompa la construcción. Significa que se conoce la versión más reciente del software a la que se puede volver cuando se comete un error en cualquier compilación posterior.
También ayuda ser más disciplinado sobre la refactorización del código y ceñirse a pequeños cambios que preservan el comportamiento. Ayuda a garantizar que los cambios que alteran una gran cantidad de archivos tengan menos probabilidades de entrar en conflicto con el trabajo de otras personas. Permite a los desarrolladores ser más exploradores, probando ideas y descartándolas volviendo a la última versión comprometida.
Create a Comprehensive Automated Test Suite- Si no tiene un conjunto completo de pruebas automatizadas, una compilación aprobada solo significa que la aplicación se puede compilar y ensamblar. Si bien para algunos equipos este es un gran paso, es esencial tener algún nivel de pruebas automatizadas para brindar confianza de que su aplicación realmente está funcionando.
Normalmente, hay 3 tipos de pruebas realizadas en Integración Continua a saber unit tests, component testsy acceptance tests.
Las pruebas unitarias están escritas para probar el comportamiento de pequeñas partes de su aplicación de forma aislada. Por lo general, se pueden ejecutar sin iniciar toda la aplicación. No llegan a la base de datos (si su aplicación tiene una), al sistema de archivos ni a la red. No requieren que su aplicación se ejecute en un entorno de producción. Las pruebas unitarias deben ejecutarse muy rápido: todo su conjunto, incluso para una aplicación grande, debe poder ejecutarse en menos de diez minutos.
Las pruebas de componentes prueban el comportamiento de varios componentes de su aplicación. Al igual que las pruebas unitarias, no siempre requieren iniciar toda la aplicación. Sin embargo, pueden afectar la base de datos, el sistema de archivos u otros sistemas (que pueden estar bloqueados). Las pruebas de componentes suelen tardar más en ejecutarse.
Keep the Build and Test Process Short - Si se tarda demasiado en compilar el código y ejecutar las pruebas unitarias, se encontrará con los siguientes problemas.
La gente dejará de hacer una compilación completa y ejecutará las pruebas antes de registrarse. Comenzará a tener más compilaciones fallidas.
El proceso de integración continua tomará tanto tiempo que se habrán realizado varias confirmaciones para cuando pueda ejecutar la compilación nuevamente, por lo que no sabrá qué registro rompió la compilación.
Las personas se registrarán con menos frecuencia porque tienen que sentarse durante años esperando que se compile el software y se ejecuten las pruebas.
Don’t Check-In on a Broken Build- El mayor error de la integración continua es verificar una compilación defectuosa. Si la compilación se rompe, los desarrolladores responsables están esperando para solucionarlo. Identifican la causa de la rotura lo antes posible y la arreglan. Si adoptamos esta estrategia, siempre estaremos en la mejor posición para averiguar qué causó la rotura y solucionarlo de inmediato.
Si uno de nuestros colegas ha realizado un registro y, como resultado, ha roto la compilación, entonces, para tener la mejor oportunidad de solucionarlo, necesitará una prueba clara del problema. Cuando se rompe esta regla, inevitablemente se tarda mucho más en arreglar la construcción. La gente se acostumbra a ver que la construcción está rota y muy rápidamente te encuentras en una situación en la que la construcción permanece rota todo el tiempo.
Always Run All Commit Tests Locally Before Committing- Asegúrese siempre de que las pruebas diseñadas para la aplicación se ejecuten primero en una máquina local antes de ejecutarlas en el servidor CI. Esto es para garantizar que se escriban los casos de prueba correctos y si hay alguna falla en el proceso de CI, es debido a los resultados de la prueba fallidos.
Take Responsibility for All Breakages that Result from Your Changes- Si realiza un cambio y todas las pruebas que escribió pasan, pero otras se rompen, la compilación aún no funciona. Por lo general, esto significa que ha introducido un error de regresión en la aplicación. Es su responsabilidad, debido a que realizó el cambio, corregir todas las pruebas que no se aprueben como resultado de sus cambios. En el contexto de la IC, esto parece obvio, pero en realidad no es una práctica común en muchos proyectos.