DevOps es un conjunto de prácticas, herramientas y hábitos que acerca a quienes desarrollan el software (Dev) y a quienes lo gestionan en producción (Ops). El objetivo es fácil de enunciar: llevar un cambio desde el ordenador de un desarrollador hasta los usuarios de forma rápida, repetible y segura.
Para quien decide en la empresa, importa menos la lista de herramientas y más el recorrido. Cada cambio, ya sea una función nueva o la corrección de un error, sigue siempre el mismo camino, controlado por máquinas donde se puede y por personas donde hace falta. Cuando ese camino existe, publicar una versión deja de ser un acontecimiento y se vuelve rutina.
Aquí lo seguimos etapa por etapa, con las herramientas más extendidas y algunos ejemplos de nuestros proyectos.
Versiones: ramas y pull requests
Todo empieza en Git, el sistema de control de versiones. Cada cambio nace en una rama (branch), una línea de trabajo separada, y vuelve a la rama principal con una pull request (merge request en GitLab): una solicitud de integración que un compañero revisa antes de aprobarla. La rama principal está protegida, nadie escribe en ella directamente, y los cambios son pequeños, para que la revisión sea real y no un trámite.
Este ritmo encaja con el de los sprints, que describimos en nuestro artículo sobre Agile Scrum: cada historia se convierte en uno o varios cambios pequeños, revisados e integrados pronto.
Integración continua: los controles automáticos
La CI (continuous integration, integración continua) es un pipeline, una secuencia de pasos automáticos, que se pone en marcha con cada cambio propuesto:
- Build: compila el proyecto y resuelve sus dependencias.
- Pruebas: unitarias, de integración y, donde hacen falta, end-to-end sobre la interfaz.
- Calidad: linters y análisis estático, por ejemplo con SonarQube, con umbrales que bloquean el merge.
- Seguridad: análisis del código (por ejemplo con Semgrep), de las librerías con vulnerabilidades conocidas y de los secretos que hayan acabado por error en el repositorio.
Si un paso falla, el cambio no entra. Las herramientas más usadas son GitHub Actions, GitLab CI/CD y Jenkins; en todas, el pipeline se describe en un archivo que vive en el repositorio junto al código, así que se versiona y se revisa como todo lo demás.
Contenedores: el mismo paquete en cada entorno
Superados los controles, el pipeline crea una imagen de contenedor: un paquete, normalmente construido con Docker, que contiene la aplicación con todo lo que necesita para funcionar. La imagen se construye una sola vez, recibe una etiqueta ligada a la versión y se guarda en un registro; después, esa misma imagen pasa de las pruebas a producción. Se acabó el clásico “en mi ordenador funciona”.
Los contenedores no son solo cosa del cloud: en el ERP para las licitaciones de Atac, desarrollado para Ernst & Young, cada microservicio funciona en un contenedor Docker en el sistema on-premise del cliente.
Despliegue automático en los entornos
La entrega continua (continuous delivery) lleva la imagen a los entornos, normalmente desarrollo, preproducción y producción, con el mismo procedimiento automático. Cuando hay muchos servicios que deben escalar se suele usar Kubernetes, que reparte los contenedores entre los servidores, los reinicia si caen y actualiza las versiones poco a poco; en otros casos bastan los servicios gestionados de un proveedor cloud o un único servidor con Docker. Lo decide el proyecto, no la costumbre.
Dos ejemplos de nuestro trabajo. En 2VitaBCognitive para Atlantia, el despliegue de los 6 microservicios pasa por AWS CodeCommit, CodePipeline y CodeDeploy, y los servicios funcionan en contenedores Docker en Amazon ECS. En ATS, nuestro sistema de selección de personal, GitHub Actions lleva el código a Docker en el servidor, detrás de Caddy, con copia de seguridad y vuelta atrás automática.
Infraestructura como código
También servidores, redes y bases de datos se describen en archivos versionados. Con Terraform (o su fork de código abierto OpenTofu) se declaran los recursos cloud y con Ansible se configuran los servidores. La ventaja es concreta: los entornos se recrean idénticos, los cambios de infraestructura pasan por revisión como el código y, tras una avería, se parte de una descripción conocida y no de la memoria de alguien.
Monitorización, alertas y rollback
El trabajo no termina con el despliegue. Prometheus recoge las métricas (tiempos de respuesta, errores, uso de recursos), Grafana las muestra en paneles y las alertas avisan al equipo cuando se supera un umbral, a ser posible antes de que lo noten los usuarios. Los logs centralizados ayudan después a entender qué ha pasado.
Cuando una versión sale mal hace falta un rollback, es decir, volver a la versión anterior. Con imágenes versionadas basta con volver a poner en servicio la anterior; el punto delicado son los datos, así que los cambios en la base de datos deben pensarse para seguir siendo compatibles con la versión anterior al menos durante una entrega.
La parte que no se automatiza
DevOps es ante todo una forma de trabajar:
- Entregas pequeñas y frecuentes: un cambio pequeño se revisa mejor, se prueba mejor y, si hace falta, se deshace rápido.
- Responsabilidad compartida: quien desarrolla sigue también el comportamiento en producción, y quien gestiona la infraestructura participa en las decisiones del proyecto.
- Análisis sin culpables: tras un incidente se busca la causa en el proceso, no a una persona a quien culpar, y se añade un control para que no se repita.
- Medidas compartidas: las investigaciones DORA (DevOps Research and Assessment) han popularizado indicadores como la frecuencia de despliegue, el tiempo desde el cambio hasta producción, el porcentaje de despliegues que causan problemas y el tiempo de recuperación.
Si queréis construir o revisar el camino que lleva vuestro código a producción, o sumar a vuestro equipo uno que ya trabaja así, hablemos.
