¿Despliegue continuo solo implica gestionar despliegues? ¿Quieres saber lo que realmente implica el despliegue continuo?

Últimamente cuando escucho a ciertos vendedores de herramientas para automatización de despliegues me pongo de los nervios. Soy fiel defensora de la Integración Continua, e incluso en ciertas empresas, por qué no, de la entrega continua o del despliegue continuo.
Es muy llamativo vender una herramienta de despliegues contándote lo que es el despliegue continuo, lo maravilloso que es programar una funcionalidad y que suba a producción poco tiempo después. Es muy llamativo decir que con solo dar a un botón subimos a producción (entrega continua) o que directamente el código puede subir a producción sin que nos demos cuenta, cuando terminemos de programar. ¡Si es solo darle a un botón, o se sube solo, yo lo quiero en mi empresa! ¿Qué hacemos que no estamos pasando a producción cada poco tiempo? ¡Estamos perdiendo dinero!
Todo esto vende muy bien la herramienta, sí. En algunas empresas esa herramienta será útil, si. Pero si no tienes bien ciertos procesos en los que poder usar la herramienta…no será realmente efectiva.
Tener automatizado el despliegue no es despliegue continuo, ni entrega continua.
Despliegue continuo, entrega continua, son palabras mayores, que habría que tratar con respeto.
Subir un cambio a producción, rápido, cada poco tiempo, no implica descontrol, ni prueba y error. Al contrario. Exige mucho más rigor, calidad, planificación, y una muy buena base técnica y cultural de toda la organización. En el mundo del software, muchas veces la rapidez sin seguridad no da calidad, sino que hacer las cosas bien es lo que te ayuda a ser rápido.
Ahora te estarás preguntando…¿por qué despliegue continuo no es solo automatizar despliegues? Mi respuesta es sencilla: porque además de eso, necesitas prestar atención a cosas como las siguientes:

1 – Funcionalidades bien definidas y tareas pequeñas y acotadas.

Si quieres subir cambios a producción cada poco tiempo, no puedes tardar 2 semanas en desarrollar cada funcionalidad. Eso no es ágil, ni rápido, y si los equipos de desarrollo son muy grandes las integraciones de código (los merges temidos) pueden llegar a ser un infierno. Si este es tu caso, tendrás que desgranar las tareas un poco más.
Muchas veces cuando se habla de despliegue continuo en conferencias, charlas, y salen ejemplos de cómo trabaja Google, alguien siempre suelta: “Claro, si suben un pequeño cambio de diseño, de html o lo que sea, ¡así cualquiera!”. Vale, totalmente de acuerdo, pero…¿tu empresa es capaz de subir ese pequeño cambio rápidamente? ¿Tu empresa es capaz de responder tan rápido si algo no va bien? ¿Tu empresa es capaz de subir con seguridad y en un tiempo razonable tanto un cambio “sencillo” como uno más complejo? ¿O para “poner un botón” en tu aplicación pueden pasar días? Piénsalo.
Este último razonamiento, además, nos lleva al siguiente punto…

2 – Arquitectura del software.

Sí, la arquitectura de tu software influye y mucho, a la hora de poder pasar a producción más a menudo. Si tu aplicación es monolítica, con muchísimas dependencias y mucho acoplamiento, será más complicado el despliegue continuo. Incluso habrá que enfocarlo de otra manera, con otras estrategias.
Lo más probable es que en este caso, subir ese pequeño cambio a producción te implique compilar y subir varios componentes del código, o incluso tener que redesplegar casi toda la aplicación entera.
Muchas empresas que cambian al despliegue o entrega continua, evolucionan su arquitectura: van dividiendo la aplicación por componentes lo más independientes posibles, optan por arquitecturas como microservicios (en vez de tener una sola aplicación que hace todo, tengo pequeñas aplicaciones que se comunican entre sí, y cada aplicación hace una funcionalidad muy concreta).
Incluso no toda la plataforma tiene que estar tan dividida (esto aporta más complejidad). Podemos separar en componentes aquellas zonas que más cambian, lo que en relación esfuerzo – beneficio nos salga más rentable.

3 – Coordinación de equipos y releases.

Tener una buena arquitectura y separación por componentes, ayuda muchísimo también a coordinar y organizar equipos.
Nos permite crear equipos multifuncionales que se encarguen de cada componente, intentando afectar lo menos posible a los otros equipos.
Las dependencias entre equipos son cosas que hay que tener muy en cuenta siempre, pero con el despliegue continuo aún más. Probar mi código en los distintos entornos previos tan a menudo, no debería impedir trabajar a los demás equipos o eliminar sus cambios.

4 – Automatización de despliegues.

Para el despliegue continuo necesitamos herramientas que nos permitan automatizar las subidas a los entornos, tanto de código, como de cambios de base de datos.
Mientras que la automatización de le gestión de cambios de base de datos podía ser opcional en Integración Continua, aquí lo veo como obligatorio. También hay que tener en cuenta que como los despliegues serán más a menudo, los cambios de base de datos serán pequeños y menos traumáticos.

5 – Política de control de versiones, versiones de código, trazabilidad.

Necesitamos saber qué versión de código ha pasado por qué entorno, qué se ha probado, qué cambios se han subido, a qué funcionalidades se corresponde el código subido…Para poder pasar a producción más a menudo, todo esto tiene que estar perfectamente controlado.

6 – Rollback, gestión de riesgos.

También hay que analizar qué implica cada cambio, y ser capaces de restaurar producción a una versión anterior estable si algo no va bien, hasta que se encuentre el problema.
A la hora de realizar un cambio plantéate: ¿a qué componentes afecta ese cambio? ¿Son partes indispensables de mi negocio? ¿Qué pasa si algo falla? Pongámonos en el caso de Amazon. No es lo mismo que al subir a producción un cambio se descuadre un elemento del sitio web a que no se puedan realizar compras.
Incluso, se puede optar por estabilizar los cambios en una “copia” de producción, y hacerlos visibles a los usuarios cuando todo sea estable.

7 – Monitorización.

Al subir cambios tan a menudo, pueden surgir problemas que no hayamos previsto. Deberíamos darnos cuenta de que algo no va bien antes que los usuarios, tenerlo todo monitorizado y bajo control.
Deberíamos ser capaces de detectar si una subida ha hecho que se detengan las ventas, que se ralenticen ciertas máquinas, etc.

8 – Pruebas automáticas.

Para mi decir que se puede subir un cambio en una línea de código sin probar, es arriesgarse demasiado, por no llamarlo una locura. Un cambio en línea de código puede hacer que se rompan otros componentes del software.
Aunque no podemos detectar todos los errores del mundo, y tener una fiabilidad del 100%, una estrategia de pruebas a distintos niveles puede detectar y solucionar muchos bugs.
Como desplegamos más a menudo y rápido, una buena parte de las ejecuciones de pruebas deben ser automáticas (aunque podamos compaginarlas con testing manual).

9 – Integración Continua.

No nos olvidemos que la base para llegar al despliegue o entrega continua, es tener un buen proceso de integración continua. Ciertos puntos que he comentado, como por ejemplo el 1, 5, 4, 8, se tratan a la hora de implantar Integración Continua.

Terminando…

En este post, solo he puesto las principales consideraciones sobre despliegue continuo que se me han venido a la cabeza, pero espero que entiendas como puedo llegar a sufrir cuando alguien me dice que despliegue continuo es solo darle a un botón, que es automatizar el despliegue del código, o que es que el desarrollador termine el código y lo suba a producción directamente (que lo he escuchado)…
Despliegue continuo implica además mucha parte de testeo, de sistemas y de gestión.

0 comentarios en “¿Despliegue continuo solo implica gestionar despliegues? ¿Quieres saber lo que realmente implica el despliegue continuo?”

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba