Formación escrita en DevOps

¿Cómo diseñar su canalización de entrega y despliegue continuos con DevOps?

En muchas organizaciones, probablemente incluida la suya, los desarrolladores programan de forma aislada en ramas de código separadas. Aunque pueda parecer que esta forma de trabajar favorece la productividad individual, perjudica la del equipo.

Las ramas separadas dificultan la fusión de código de distintos desarrolladores. Integrar las piezas, conseguir que funcionen juntas y entregar ventajas y funcionalidades a los clientes suele requerir la participación de varios desarrolladores, mucho trabajo repetido y resolver conflictos que se deberían haber resuelto hace tiempo.

El problema se agrava si no integra continuamente

Como fusionar código resulta difícil y agotador durante la construcción, la mayoría de los equipos de desarrollo, por desgracia, no lo fusiona hasta justo antes de entregar la aplicación a quienes realizan las pruebas de integración o de aceptación de usuarios. Esto agrava el problema. Dejan en manos de aseguramiento de la calidad toda la responsabilidad sobre la integración y la calidad del trabajo conjunto. Además de ser absurdo, esto explica por qué se retrasan los proyectos, se disparan los déficits presupuestarios, caen la moral y la motivación, se incumplen los objetivos y las promesas de la organización, y las empresas de todo el mundo malgastan unos 600 mil millones de USD al año en trabajo de TI sin presupuestar ni programar. En otras palabras, en rehacer trabajo de TI o en aplicar soluciones provisionales.

¿Cómo puede ayudarle el desarrollo basado en el tronco (rama principal)?

La solución es combinar el desarrollo basado en el tronco (rama principal del código) con la integración continua y la automatización de pruebas. Es un modelo de ramas de control de versiones en el que los desarrolladores colaboran en una única rama llamada «tronco». Evitan crear otras ramas de desarrollo de larga duración, aunque haya presión para hacerlo.

El desarrollo basado en el tronco facilita la integración continua y, por extensión, la entrega continua. Cuando los desarrolladores registran cambios en el tronco varias veces al día, es fácil cumplir el requisito central de la integración continua: que todo el equipo registre cambios en el tronco al menos una vez cada 24 horas. Así el código siempre está listo para publicar bajo demanda y se hace posible la entrega continua.

La integración continua permite entregar código en partes más pequeñas y listas para desplegar

Al registrar cambios con frecuencia, el equipo desarrolla y entrega en lotes pequeños, lo que mejora la calidad y facilita resolver problemas y conflictos. La integración continua con cambios diarios anima al equipo a construir piezas pequeñas de código útiles y listas para desplegar, sin comprometer la integridad de los marcos de integración y entrega continuas. Las actualizaciones del repositorio compartido también dan a todos un medio para coordinarse, tomar decisiones y recibir comentarios rápidamente.

Cada vez que se registra código, el sistema de integración continua ejecuta casos de prueba automatizados para las funciones y funcionalidades que dependen del módulo cambiado o se ven afectadas por él. Si algo deja de funcionar, la persona responsable del cambio debe corregirlo con la máxima prioridad. En ese momento nada importa más que permitir al resto del equipo seguir integrando su trabajo en el tronco. Hasta corregir o revertir rápidamente el cambio erróneo, no se permiten más cambios en ese módulo del tronco, para preservar su estabilidad y fiabilidad.

Si discrepa de este principio fundamental de DevOps, pregúntese por qué añadiría código nuevo a un módulo que ya tiene errores.

Puede tener razones válidas, pero procure evitar la deuda técnica y acumular soluciones provisionales sobre otras.

Commits sujetos a validación como protección adicional para el desarrollo basado en el tronco

Su equipo de DevOps también puede recurrir a commits sujetos a validación, que mejoran la calidad y añaden otra capa de protección al tronco.

Cada vez que un desarrollador intenta registrar código, se ejecutan primero las pruebas automatizadas para validarlo. El código solo se registra formalmente en el tronco cuando supera la validación.

Use entornos similares a producción en cada etapa del flujo de valor de ingeniería de software

Otro problema habitual en muchas organizaciones de TI son las diferencias entre producción y preproducción (desarrollo, integración y pruebas). Hay diferencias en la configuración, las versiones y los niveles de parches de sistemas operativos, bases de datos, herramientas de terceros y API. También puede haber distintas versiones de su propio código repartidas por varios entornos. Incluso diferencias mínimas entre las versiones de JVM de preproducción y producción pueden determinar si el despliegue funciona o falla por completo. Si no controla sus entornos y no sabe qué contienen, no puede saber qué resultados obtendrá.

Incorpore la gestión de entornos al trabajo diario de desarrollo y entrega de software

Por ello, los sistemas de preproducción deben ser réplicas de los de producción. Permita que su equipo cree entornos de autoservicio de forma automatizada y bajo demanda para realizar con seguridad su trabajo diario de ingeniería en condiciones similares a producción.

El flujo de valor de TI aporta valor tanto con el código del software como con los entornos donde se ejecuta. Los especialistas de desarrollo y operaciones deben asumir que consta de dos componentes igual de importantes:

1. Código para construir el software que aporta valor a sus clientes internos o externos, o a ambos.
2. Código para construir los entornos de preproducción y producción que alojan su software.

Use su fuente única de información (el tronco) para controlar el software y los entornos
(es decir, adopte la infraestructura como código, IaC)

Con DevOps, las tareas para construir los entornos de preproducción y producción pasan a formar parte del tronco, la definición más pura de infraestructura como código (IaC). Los especialistas de desarrollo y operaciones colaboran para crearla, en vez de dejarla a equipos de operaciones aislados que apenas conocen las particularidades del software que alojarán los entornos.

Para dar la misma importancia al código del software y al de los entornos, guarde ambos en su fuente única de información, el tronco.

Para construir por completo sus sistemas de preproducción y producción y la canalización de despliegue, incluidos los marcos de integración y entrega continuas, guarde en el control de versiones el código del software, las configuraciones, los scripts y todo lo necesario para construir la cadena de entrega de principio a fin. Si quiere cambiar de forma permanente un ajuste de configuración de un entorno, cámbielo en los scripts que lo construyen. Así, la próxima persona que cree un entorno no tendrá que reinventar la rueda.

La mayor parte de la documentación detallada queda obsoleta enseguida. Le conviene más invertir el esfuerzo en mantener al día los scripts que crean los entornos. Sin entornos de autoservicio bajo demanda, la infraestructura en la nube será otra plataforma de alojamiento infrautilizada y la iniciativa DevOps se quedará en otro intento de mejora de procesos poco aprovechado. Debería poder crear entornos completos de producción y preproducción a partir del control de versiones. Con DevOps, reconstruir un entorno es más fácil y rápido que repararlo. Ya no se permiten cambios manuales en los entornos. Solo el código y la configuración deben reconstruirlos, configurarlos y ponerlos en marcha.

Adopte una nueva definición de terminado (DoD)

Cuando estén operativos el marco de entrega continua y la canalización de despliegue, necesitará una nueva definición de terminado (DoD).

Una tarea se considera «terminada» cuando las funcionalidades y ventajas asociadas para el cliente se han:

• creado desde el tronco de forma automática o con un solo clic,
• validado con pruebas automatizadas en entornos similares a producción,
• demostrado en entornos similares a producción,
• dejado listas para desplegar o, mejor aún, ya desplegadas en entornos de producción en funcionamiento, de nuevo de forma automática o con un solo clic.

CONCLUSIÓN

Con DevOps, integrar el código forma parte del trabajo diario en vez de dejarse para el final de los proyectos. Los desarrolladores, los equipos de operaciones y los especialistas de seguridad de la información ensayan muchas veces el despliegue durante el ciclo de vida de la ingeniería de software. Esto aumenta sin duda las posibilidades de que los despliegues en producción transcurran sin problemas.

Adoptar la integración continua también aporta mayor capacidad de entrega del negocio, más estabilidad del software y los entornos, mayor satisfacción laboral y un mejor servicio a clientes internos y externos.