“No se despliega en viernes.” Es una de las normas no escritas más extendidas del sector, y dice mucho sobre cómo se publican los cambios en muchas empresas: a mano, siguiendo una lista de pasos que solo conoce una persona, y cruzando los dedos.
El miedo a desplegar tiene un efecto perverso. Como publicar es arriesgado, se publica menos a menudo. Como se publica menos a menudo, cada despliegue acumula más cambios. Y cuantos más cambios, más probable es que algo falle y más difícil saber qué ha sido.
La forma de romper ese círculo se llama CI/CD.
Qué significa CI/CD
- Integración continua (CI): cada vez que alguien sube un cambio al repositorio, un sistema automático compila el proyecto y ejecuta las pruebas. Si algo se rompe, se sabe en minutos y no tres semanas después.
- Entrega o despliegue continuo (CD): una vez que el cambio ha pasado las comprobaciones, el mismo sistema lo publica en los entornos de pruebas y, con aprobación manual o de forma automática, en producción.
El conjunto de pasos automatizados se conoce como pipeline. Lo importante no es la herramienta (GitHub Actions, GitLab CI, Azure DevOps y otras hacen esencialmente lo mismo), sino que el proceso deje de depender de la memoria de una persona.
Qué gana el negocio
- Menos errores humanos. Un script ejecuta los mismos pasos, en el mismo orden, siempre.
- Cambios más pequeños y frecuentes. Si falla algo, el origen está acotado y la vuelta atrás es rápida.
- Menos dependencia de personas concretas. El conocimiento de “cómo se despliega” está en el repositorio, no en la cabeza de alguien que puede estar de vacaciones.
- Trazabilidad. Queda registrado qué se publicó, cuándo y quién lo aprobó, algo que además piden marcos como el ENS o la ISO 27001.
- Tiempo de respuesta. Corregir un error urgente pasa de ser una operación delicada a un cambio más.
Un pipeline mínimo razonable
No hace falta montar una plataforma compleja para empezar. Con estos pasos ya se nota la diferencia:
- Compilación automática en cada cambio. Si el proyecto no compila, no avanza.
- Pruebas automáticas. Aunque sean pocas, empieza por las que cubren lo que más dolería que fallara: el pago, el alta de clientes, el cálculo de precios.
- Análisis estático y de dependencias. Detecta fallos habituales y librerías con vulnerabilidades conocidas antes de que lleguen a producción.
- Despliegue automático a un entorno de pruebas lo más parecido posible al real.
- Despliegue a producción con un clic, tras aprobación, y con el mismo procedimiento que se usó en pruebas.
- Vuelta atrás preparada. Poder volver a la versión anterior debe ser tan sencillo como desplegar.
Lo que suele salir mal
- Automatizar sin pruebas. Un pipeline sin tests solo publica errores más deprisa.
- Secretos en el repositorio. Contraseñas y claves deben vivir en el gestor de secretos de la plataforma, nunca en el código.
- Entornos que no se parecen. Si pruebas y producción tienen versiones o configuraciones distintas, el “en mi máquina funciona” se traslada al servidor. La infraestructura definida como código ayuda a evitarlo.
- Un pipeline que tarda una hora. Si la respuesta llega tarde, el equipo deja de esperarla. Conviene mantenerlo rápido y dejar las pruebas más largas para ejecuciones programadas.
- Cambios de base de datos sin plan. Las migraciones de esquema merecen su propio paso y su propia estrategia de vuelta atrás.
“Somos un equipo pequeño, esto no es para nosotros”
Es justo al revés. En un equipo de dos o tres personas, el tiempo que se pierde desplegando a mano y arreglando despliegues fallidos pesa mucho más. Y el riesgo de que la única persona que sabe publicar no esté disponible es mayor. Un pipeline básico se monta en días y se amortiza en pocas semanas.
Seguridad dentro del proceso
El pipeline es también el mejor sitio para integrar controles de seguridad sin frenar al equipo: revisión de dependencias, detección de secretos y análisis de código en cada cambio. Es la aplicación práctica del enfoque que describimos en por qué la ciberseguridad tradicional ha dejado de funcionar.
Este es un artículo informativo: los pipelines de CI/CD no son un servicio estándar de Alenia Systems. Si estás pensando en llevar tu aplicación a la nube, te recomendamos leer cómo migrar al cloud sin interrumpir tu negocio y ver cómo hacemos los proyectos cloud, incluida la infraestructura como código y la automatización de despliegues.