¿Cómo se puede usar CI para los idiomas interpretados?

Nunca he usado un sistema de integración continua (CI) antes. Codifico principalmente en MATLAB, Python o PHP. Ninguno de estos tiene un paso de compilación y no veo cómo se podría utilizar un CI para mi trabajo. Un amigo en un gran proyecto en una gran empresa me dijo que el idioma no importa.

No veo cómo CI me sería útil si no tengo un paso de compilación. Puedo pensar en CI como un entorno de prueba que ejecutaría pruebas unitarias. ¿Me estoy perdiendo de algo?

La integración continua como término se refiere a dos ideas distintas.

El primero es un flujo de trabajo: en lugar de que todos en un equipo trabajen en su propia sucursal y luego, después de un par de semanas de programación, intenten fusionar sus cambios en la línea principal, esos cambios se integran (casi) continuamente. Esto permite que los problemas surjan temprano y evita cambios incompatibles. Sin embargo, eso requiere que podamos verificar fácilmente si un cambio "funciona".

Aquí es donde entra la segunda idea, que resultó mucho más popular. Un servidor CI es un entorno limpio donde los cambios se prueban lo más rápido posible. El ambiente limpio es necesario para que la construcción sea reproducible. Si funciona una vez, siempre debería funcionar. Esto evita problemas "pero funcionó en mi máquina". En particular, un servidor CI es valioso cuando su software se ejecuta en diferentes sistemas o en diferentes configuraciones y debe asegurarse de que todo funcione.

La falta de un paso de construcción es irrelevante. Sin embargo, CI solo tiene sentido si tiene un conjunto de pruebas. Este conjunto de pruebas debe ser automático y no debe tener fallas. Si las pruebas fallan, el desarrollador apropiado debería recibir una notificación para que puedan solucionar el problema que introdujeron ("romper la compilación", incluso cuando no hay compilación como compilación).

Resulta que dicho servidor es valioso para algo más que solo pruebas. De hecho, la mayoría del software de CI es realmente malo para ejecutar pruebas en varias configuraciones, pero bueno para administrar todo tipo de trabajos. Por ejemplo, además de las pruebas unitarias "continuas", podría haber una prueba completa como una construcción nocturna. El software se puede probar con múltiples versiones de Python, diferentes versiones de biblioteca. Un sitio web podría ser probado para enlaces muertos. Podemos ejecutar análisis estáticos, verificadores de estilo, herramientas de cobertura de prueba, etc. sobre el código. Se puede generar documentación. Cuando pasan todas las suites de prueba, el proceso de empaquetado puede iniciarse para que esté listo para lanzar su software. Esto es útil en una configuración ágil donde desea un producto desplegable (y demoable) en todo momento. Con el auge de las aplicaciones web, también existe la idea de una implementación continua: Si pasan todas las pruebas, podemos impulsar automáticamente los cambios a producción. Por supuesto, esto requiere que tenga mucha confianza en su conjunto de pruebas (si no, tiene problemas más grandes).

Es cierto que no tiene una necesidad particular de un sistema de CI para realizar compilaciones y verificar que esas compilaciones sean correctas, pero eso es solo una parte de lo que se trata CI.

El propósito de CI es detectar errores lo antes posible, porque en términos generales, cuanto antes se detecta un error, más barato es repararlo. Con ese fin, en el caso de que no sea necesario un paso de compilación, un sistema de CI todavía puede automatizar el uso de herramientas de análisis de código, implementación en un entorno de prueba, unidad / integración / regresión / otras pruebas que puede automatizar y cualquier otro paso puede realizar automáticamente para verificar si hay errores.

La integración continua realiza más que una compilación del código. ¡Si eso fue todo, entonces no necesitaríamos tantas herramientas para ello!

Algunas otras tareas que se me ocurren de manera manual que a menudo realiza una tubería de integración continua:

• Ejecución de pruebas automáticas. (Python tiene una gran cantidad de bibliotecas de pruebas automatizadas, y PHP tiene al menos algunas. No puedo hablar con MATLAB).
• Agrupación del software para su distribución. Al automatizar este proceso, se asegura de que se realice de manera exacta, consistente y repetible cada vez. Ningún paso será olvidado; generar dicho paquete de distribución requiere como máximo un clic. (¡Combinar su aplicación Python como una rueda es una gran idea!)
• Etiquetar confirmaciones de hitos. Cada vez que crea un paquete para producción, probablemente quiera etiquetarlo.
• Números de versión con incremento automático. Por lo general, esto sería solo el número de "compilación" y no las partes más significativas, pero puede ser bueno identificar de forma única una compilación en particular, para que sepa qué se implementa dónde.

Yendo un poco más allá de la línea fronteriza de "integración continua" en sentido estricto, también podría hacer esto:

• Tenga un proceso automatizado para configurar un sistema operativo e instalar sus dependencias.
• Implementación automática de copias del software (principalmente útil para aplicaciones web o software distribuido por un administrador de paquetes). Algunos equipos realmente usan esto para implementarlo en producción (entrega continua), pero incluso si no lo hace, aún puede aprovechar esto para implementar copias adicionales del código que no sean de producción. Para algunos proyectos donde trabajo, tenemos una copia para que los desarrolladores prueben su código antes de ponerlo a disposición de QA, una copia para QA para probar y una copia más "estable" para fines de demostración.

El punto es simplemente esto: hay tareas que debe realizar periódicamente en el proceso de desarrollo de software además de simplemente escribir el código. Al automatizar estas tareas y hacer que se ejecuten en un servidor, obtienes

• Proceso consistente (No tendrás a Stan y Sally haciendo las cosas de diferentes maneras).
• Conocimiento de los procesos registrados en el código (cualquiera que pueda leer los scripts puede aprender los pasos involucrados en la implementación, en lugar de que Sally sea la única que lo haga o sepa cómo hacerlo).
• Duplicación de procesos más simple (Fácil de implementar múltiples copias del sitio web: ¡solo proporciona una nueva configuración!)
• Pruebas más exhaustivas (Bob solo probó su página, pero sus cambios rompieron la página de Sally. Sally olvidó enviar un archivo. Stan agregó una nueva dependencia que debe instalarse junto con la aplicación pero no se dio cuenta porque el IDE la instala automáticamente He visto todo esto de una forma u otra).

Y probablemente algunos otros beneficios que ni siquiera se te ocurren.

Es posible que no necesite compilar las soluciones, pero CI aún puede ayudarlo cambiando los archivos de configuración / rutas de carpetas, etc. y si está en un equipo, promoviendo los cambios al estado de producción y desplegándolos

Supongamos que implementa su código Python en 5 servidores de control de calidad diferentes y necesita que apunte a diferentes bases de datos de control de calidad, y luego, una vez que se ejecuta la prueba automatizada (activada por CI), promueve la compilación a producción y la implementa allí con los cambios de configuración adecuados para cada servidor de producción .