Si todavía no tienes claro en que consiste DevOps, te invito que leas el artículo Entre más DevOps… antes de continuar.
Cuando empezamos un proyecto de software y todo nuestro avance no pasa de unas 500 líneas de código y estas se encuentran organizadas en algunos cuantos archivos que alcanzamos a ver en el Explorador de Soluciones de Visual Studio sin la necesidad de hacer scroll down, en realidad no hay mucho de qué preocuparse cuando viene un cambio y que por accidente provoque un error (issue), puesto que se puede identificar fácilmente y desplegar la aplicación de software sin muchos rodeos.
Otro escenario muy distinto es cuando nuestro código se encuentran en el orden de los miles o decenas de miles de líneas de código, trabajando de manera conjunta entre muchos desarrolladores al mismo tiempo, pequeños cambios pueden producir errores bloqueantes o de mayor severidad que si no se detectan antes de salir en ambientes de uso real en producción, de seguro nos traerán muchos dolores de cabeza con los usuarios finales.
La Integración Continua ó Continuous Integration forma parte de la metodología DevOps, y es un método comprobado para asegurar que el desarrollo software se integre de manera correcta con el resto de la plataforma, por lo que viene a mitigar situaciones como las del caso anterior.
La Integración Continua promulga que:
- La integración debe hacerse tan frecuentemente como sea posible, idealmente en cada commit.
- Debe haber automatización de la generación de los builds para nuestro desarrollo, incluyendo procesos como: compilación, empaquetado y pruebas.
- El último commit del día se queda en el repositorio master, este cambio no implica ningún error en la versión actual.
- Lo ideal es mantener un único repositorio de código.
- Todos los recursos necesarios para efectuar un build en el proyecto debe estar en el repositorio, sin dependencias externas.
- Los build deben ser automatizados.
- No solo se trata de compilar, si no que se debe generar nueva documentación y métricas.
- Por cada build deberían ejecutarse todos los casos de prueba con el fin de confirmar que el funcionamiento se comporta como se espera.
- Cuando se realizan commits frecuentes, se reducen el número de potenciales conflictos.
- Todos los desarrolladores deberían hacer al menos un commit al final del día.
- Cada commit debería desencadenar un proceso de build en una máquina de integración.
- Es necesario realizar pruebas en un entorno idéntico al de producción, puesto que el entorno de producción puede llegar a ser significativamente diferente al de pruebas.
- Todos saben que está pasando, si un build falla es importante que cualquiera pueda saber en qué estado queda el sistema y que provocó el error.
¿Herramientas?
Muchas pueden figurar en este sentido, sin embargo, las más populares son:
- Jenkins.
- Git.
- Visual Studio Team Services.
Vemos ahora como se implemente la integración continua con Microsoft Azure, GitHub y Visual Studio:
Sígueme en Twitter @vmorenoz
¿Te gustó este artículo? Únete a Facebook en MicrosoftLand