Publicar un cambio sin cruzar los dedos.
Para quién
Para empresas y administraciones con aplicaciones o portales que cambian a menudo, y donde publicar depende hoy de una persona, de una lista de pasos y de elegir bien la hora.
El problema
Publicar da miedo. Se hace un viernes por la tarde o de madrugada, a mano, con unos pasos que solo conoce una persona. Si algo se rompe, nadie sabe cómo volver atrás. Así que se publica poco, y cada publicación lleva demasiados cambios juntos.
Cómo lo resolvemos
Automatizamos el camino entero. Cada cambio pasa por pruebas automáticas y por un entorno de preproducción como el real. A producción solo llega lo que se ha probado, cuando una persona lo aprueba. Y si algo va mal, se vuelve a la versión anterior.
Qué incluye
Pruebas automáticas
En cada cambio. Si fallan, el cambio no avanza.
Preproducción
Un entorno como el real donde ver el cambio antes de publicarlo.
Aprobación de una persona
Nada llega a producción sin que alguien lo decida.
Vuelta atrás
La versión anterior queda guardada y se puede recuperar.
Actualizaciones de seguridad
Propuestas cada noche por un bot y revisadas por una persona.
Registro
Qué se publicó, cuándo y quién lo aprobó.
Cómo trabajamos
Empezamos por ver cómo publicas hoy y por escribir esos pasos como código. Montamos preproducción y las pruebas, y publicamos contigo las primeras veces. A partir de ahí, los cambios salen pequeños y a menudo. Quién aprueba el paso a producción lo decides tú.
Qué medimos
Despliegues hechos, despliegues fallidos y vueltas atrás, tiempo desde que un cambio está listo hasta que está en producción y antigüedad de las actualizaciones pendientes.
Casos
Un organismo público: cada cambio de su portal pasa por pruebas y por preproducción antes de publicarse.
Cómo está hecho
Integración y despliegue continuos con GitLab CI. El camino de un cambio está escrito en el repositorio: compilación, pruebas, análisis de calidad y de seguridad, despliegue en preproducción y promoción a producción.
Para pasar a producción hacen falta un 80 % de cobertura mínima de tests y 0 incidencias en SonarQube. El análisis estático de seguridad cubre el código entero y cada cambio se comprueba contra bases de vulnerabilidades conocidas: si aparece un hallazgo nuevo, la integración se detiene.
En los proyectos con contenedores, lo que se publica es exactamente la imagen que se probó en preproducción, identificada por su huella, y no una compilación nueva. La versión anterior se conserva y se puede volver a ella. La promoción a producción es un paso manual: lo lanza una persona.
Cada noche un bot (Renovate) revisa las dependencias y propone actualizaciones, que revisa una persona antes de aplicarlas. Los secretos del despliegue están en un gestor y se entregan al ejecutar; no están en el repositorio. Antes de producción, cada cambio lo revisan además cuatro agentes (seguridad, accesibilidad, calidad y funcionalidad) y una persona.
Preguntas frecuentes
¿Qué pasa si un despliegue sale mal?
Se vuelve a la versión anterior, que queda guardada. Después se busca la causa con calma, con el servicio funcionando.
¿Quién decide que algo pasa a producción?
Una persona, siempre. Las pruebas dicen si un cambio puede publicarse; cuándo se publica lo decide quien tú digas.
¿Hay que parar el servicio para publicar?
Depende de la aplicación. Lo vemos en el inventario inicial y, si hace falta una parada, acordamos contigo el momento.
¿Podéis automatizar los despliegues de una aplicación que ya existe?
Sí. Empezamos por escribir como código los pasos que hoy se hacen a mano y por añadir las pruebas que falten.
También en Sistemas gestionados
Copias de seguridad
Cifradas y comprobadas: restauramos de verdad, no solo copiamos.
Monitorización
Vigilancia de errores y de disponibilidad, con el arreglo ya preparado.
El siguiente paso
Cuéntanos cómo trabaja hoy tu empresa y te decimos por dónde empezar.