1.1.-DevOps
1.1. DevOps, CI/CD y despliegue de aplicaciones¶
Idea principal
DevOps es una forma de trabajar que conecta el desarrollo de software con su operación y mantenimiento. La colaboración se apoya en automatización, pruebas y ciclos breves de retroalimentación para entregar cambios con calidad y poder mantenerlos en funcionamiento.
Una aplicación no termina cuando el código funciona en el ordenador de quien la ha programado: también hay que integrarla con el resto del proyecto, comprobarla, desplegarla y observar cómo se comporta cuando la usan personas reales. DevOps ayuda a organizar ese recorrido y a reducir los problemas que aparecen cuando desarrollo y operaciones trabajan de forma aislada.
En este apartado relacionaremos esa forma de trabajo con CI/CD y con el despliegue web que estudiaremos en el módulo. El objetivo no es memorizar siglas, sino entender qué comprueba cada etapa y qué decisiones siguen siendo responsabilidad del equipo.
Este contenido introduce el RA 6 del módulo y, en particular, el criterio de evaluación CE 6.h. La tabla reproduce sus descriptores oficiales:
| Código | Descripción |
|---|---|
| RA 6 | Elabora la documentación de la aplicación web evaluando y seleccionando herramientas de generación de documentación, control de versiones y de integración continua. |
| CE 6.h | Se han utilizado herramientas para la integración continua del código. |
En este tema se estudia el propósito de la integración continua y se muestra un ejemplo de herramienta. La adquisición completa del CE 6.h requiere además utilizarla en una actividad práctica; leer esta explicación, por sí solo, no demuestra ese desempeño.
Qué deberías saber al terminar
Al acabar este tema deberías poder:
- explicar qué problemas intenta resolver DevOps;
- distinguir integración continua, entrega continua y despliegue continuo;
- reconocer las etapas habituales de un pipeline y justificar para qué sirven las pruebas y los entornos previos a producción;
- identificar prácticas relacionadas, como IaC, monitorización y uso de contenedores.
Mapa del tema
Seguiremos esta secuencia:
- el contexto y el significado de DevOps;
- los beneficios de colaborar y automatizar;
- las diferencias entre CI, entrega continua y despliegue continuo;
- un pipeline desde el cambio de código hasta producción;
- otras prácticas y recomendaciones para trabajar con criterio.
1. DevOps: desarrollo y operaciones en colaboración¶
DevOps combina development (desarrollo) y operations (operaciones). No es un producto que se instala ni una metodología única con pasos obligatorios: es una cultura de colaboración apoyada en prácticas y herramientas que ayudan a construir, desplegar y mantener software.
Definición
DevOps es un enfoque de trabajo que integra a las personas, los procesos y las herramientas de desarrollo y operaciones para entregar software de forma frecuente, fiable y con retroalimentación continua.
Tradicionalmente, las responsabilidades se repartían así:
| Ámbito | Responsabilidades habituales |
|---|---|
| Desarrollo (Dev) | Diseñar y programar funcionalidades; revisar cambios y probar el código. |
| Operaciones (Ops) | Preparar la infraestructura; desplegar, mantener y supervisar los servicios. |
| Trabajo compartido | Acordar cómo se construye, prueba, configura, protege y mantiene la aplicación. |
La separación rígida puede provocar que una aplicación llegue tarde a operaciones, que sus necesidades de ejecución no se conozcan a tiempo o que aparezcan diferencias entre el equipo de desarrollo y el servidor. Con DevOps, ambos ámbitos colaboran durante todo el ciclo, no solo cuando llega el momento de publicar una versión.
Ejemplo: una aplicación web de clase
Un equipo desarrolla una aplicación y otra persona prepara el servidor. Si solo se comparte un archivo comprimido al final, pueden faltar dependencias o instrucciones. Si el equipo versiona el código y la configuración, automatiza pruebas y acuerda cómo desplegar, los problemas se detectan antes y el proceso puede repetirse.
Un perfil profesional DevOps puede trabajar en automatización de despliegues, plataformas en la nube, integración continua o supervisión de servicios. Las funciones concretas dependen de cada organización. Existe demanda de perfiles con estas competencias, aunque sus tareas y su denominación varían. DevOps no significa que una única persona deba asumir todas las tareas ni sustituye la colaboración del equipo.
Nube de palabras sobre perfiles DevOps
Busca una oferta de trabajo relacionada con DevOps, publicada en un portal de empleo o en la página de una empresa. Lee la oferta e identifica las palabras y expresiones técnicas que aparecen en ella, por ejemplo, herramientas, lenguajes,servicios cloud, metodologías o competencias profesionales. ¿qué términos aparecen con más frecuencia y qué relación tienen con los contenidos de este tema? No incluyas datos personales de las personas candidatas ni copies la oferta completa.
2. Por qué importa DevOps¶
Las aplicaciones cambian continuamente: se corrigen errores, se añaden funciones y se publican actualizaciones de seguridad. Si cada cambio depende de tareas manuales, aumenta el tiempo de entrega y también la posibilidad de olvidar un paso.
| Necesidad | Cómo ayuda el enfoque DevOps |
|---|---|
| Publicar cambios con frecuencia | Divide el trabajo en cambios pequeños y repetibles. |
| Evitar «en mi ordenador funciona» | Hace visibles las diferencias entre entornos y automatiza comprobaciones. |
| Detectar fallos pronto | Acerca las pruebas y la revisión al momento en que se hace el cambio. |
| Mejorar la fiabilidad y la seguridad | Facilita integrar controles y reaccionar antes, aunque no las garantiza por sí solo. |
| Colaborar entre perfiles distintos | Comparte objetivos, información y responsabilidad sobre el servicio. |
| Mejorar a partir del uso real | La monitorización aporta datos para corregir problemas y planificar mejoras. |
La automatización reduce tareas repetitivas, pero no elimina todos los errores ni garantiza que una aplicación sea segura. Para obtener esos beneficios hacen falta pruebas adecuadas, revisión, permisos bien configurados y seguimiento después del despliegue.
3. CI/CD: integrar, preparar y desplegar cambios¶
CI y CD describen prácticas relacionadas, pero no significan lo mismo. Un pipeline o flujo de integración y entrega es una secuencia de tareas que una herramienta ejecuta, normalmente, cuando se registra un cambio en el repositorio.
3.1. CI: integración continua¶
La integración continua (Continuous Integration, CI) consiste en incorporar cambios pequeños al repositorio compartido con frecuencia y comprobarlos automáticamente. Las comprobaciones pueden incluir la compilación, pruebas unitarias, pruebas de integración y análisis de calidad.
Así se acorta el tiempo entre introducir un fallo y detectarlo. En un flujo con ramas y solicitudes de cambio (pull requests), las comprobaciones pueden ejecutarse antes de aceptar la integración. La política del repositorio puede bloquear la aceptación si fallan; la herramienta, por sí sola, no decide siempre cómo se gestionará el cambio.
Por ejemplo, un flujo de GitHub Actions puede ejecutar las pruebas al recibir
un push o una solicitud de cambio. Este ejemplo supone un proyecto Python
que ya tiene pruebas escritas con pytest:
name: CI
on: [push, pull_request]
jobs:
pruebas:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: "3.x"
- run: python -m pip install pytest
- run: pytest
Este flujo comprueba el código, pero no lo publica en un servidor. Para que
pytest encuentre pruebas, el proyecto debe incluirlas; en un proyecto real
también se instalarían las dependencias que necesite la aplicación.
3.2. CD: entrega continua y despliegue continuo¶
La sigla CD se usa para dos prácticas distintas. En ambos casos, las comprobaciones anteriores ayudan a mantener versiones listas para avanzar; la diferencia principal es qué ocurre al llegar a producción.
| Práctica | Qué significa | ¿Quién decide cuándo llega a producción? |
|---|---|---|
| Entrega continua (Continuous Delivery) | Cada cambio que supera las comprobaciones queda preparado para publicarse; el despliegue a producción puede requerir una aprobación. | El equipo autoriza el lanzamiento cuando considera que es el momento adecuado. |
| Despliegue continuo (Continuous Deployment) | Cada cambio que supera las comprobaciones y las reglas establecidas se despliega automáticamente en producción. | El pipeline lo hace sin una aprobación manual para cada cambio. |
En ambos enfoques se intenta entregar cambios pequeños y frecuentes, lo que facilita localizar la causa de un problema. El despliegue continuo requiere confianza en las pruebas, controles y mecanismos de recuperación: no significa publicar cualquier cambio sin condiciones.
Una sigla, dos significados
En español, entrega continua y despliegue continuo se parecen, y en inglés comparten las letras CD. Recuerda la diferencia práctica: con entrega continua, una persona puede autorizar cada publicación a producción; con despliegue continuo, esa publicación se automatiza si se cumplen las condiciones acordadas.
4. El pipeline: del cambio a producción¶
Un pipeline habitual comienza cuando se versiona un cambio. Después construye la aplicación, ejecuta comprobaciones y, si todo va bien, prepara una versión para probarla y desplegarla. El orden exacto depende del proyecto.
4.1. Etapas habituales¶
La siguiente imagen representa un pipeline dividido en dos partes: CI, donde se construye y comprueba el cambio, y CD, donde se revisa y se hace pasar por los entornos previos a producción.
La imagen se lee de izquierda a derecha. Cada etiqueta nombra una tarea del recorrido:
| Etapa de la imagen | Qué ocurre |
|---|---|
| Code | Se escribe código para añadir una funcionalidad o corregir un error. |
| Related Code | Se actualizan los elementos relacionados que necesita el cambio, como bibliotecas, scripts, pruebas, configuración o documentación. |
| Commit | Se registra el conjunto de cambios en Git. Según la configuración del repositorio, este commit puede iniciar el pipeline. |
| Build | Se compila o empaqueta el proyecto y se generan los artefactos que después se probarán o distribuirán. |
| Unit Tests | Se comprueba que cada componente funcione de forma aislada. |
| Integration Tests | Se verifica que varios componentes o servicios funcionen correctamente al interactuar. |
| Review | Se revisa el cambio y pueden aplicarse controles de calidad y seguridad antes de avanzar. |
| Staging | Se despliega la versión en preproducción para validar la aplicación en un entorno parecido al de producción. |
| Production | La versión se pone a disposición de las personas usuarias y se supervisa su funcionamiento. |
El entorno de staging se configura para parecerse a producción, pero no es necesariamente idéntico. Una diferencia de datos, permisos, carga o configuración todavía puede revelar un problema al desplegar. La imagen resume un flujo habitual, pero no implica que el paso a producción siempre sea automático: con entrega continua puede requerir aprobación; con despliegue continuo se automatiza cuando se cumplen las condiciones acordadas.
4.2. Vista del flujo¶
El diagrama amplía la imagen anterior: muestra qué sucede cuando fallan las comprobaciones y dónde puede intervenir una aprobación antes de producción.
flowchart TD
A["Cambio de código"] --> B["Commit o pull request"]
B --> C["Build y pruebas automatizadas"]
C --> D{"¿Pasan las comprobaciones?"}
D -->|"No"| E["Corregir el cambio y repetir CI"]
E --> B
D -->|"Sí"| F["Revisión y versión preparada"]
F --> G["Staging o preproducción"]
G --> H{"Estrategia de publicación"}
H -->|"Entrega continua"| I["Aprobación del equipo"]
I --> J["Producción"]
H -->|"Despliegue continuo"| J
J --> K["Monitorización y retroalimentación"]
K --> A
flowchart TB
subgraph cambios[Preparación del cambio]
direction LR
A[Code] --> B[Related Code] --> C[Commit]
end
subgraph ci[CI: construir y probar]
direction LR
D[Build] --> E[Unit Tests] --> F[Integration Tests] --> G{¿Pasan?}
end
C --> D
G -->|No| R[Corregir y repetir CI]
R --> D
G -->|Sí| H[Review]
H --> I[Staging]
subgraph cd[CD: publicar]
direction LR
J{Estrategia} -->|Entrega continua| K[Aprobación]
K --> L[Production]
J -->|Despliegue continuo| L
end
I --> J
L --> M[Monitorización]El flujo muestra dos ideas importantes: si falla una comprobación, el equipo recibe información para corregir el cambio; si se supera, la publicación depende de la estrategia elegida. La retroalimentación de producción vuelve al trabajo de desarrollo y ayuda a decidir qué mejorar.
4.3. Ejemplo paso a paso¶
Imagina que el equipo corrige un formulario de una aplicación web:
- Quien desarrolla el cambio lo registra en Git y abre una solicitud de revisión.
- La herramienta ejecuta la construcción y las pruebas. Si alguna falla, el cambio se revisa antes de continuar.
- Si las comprobaciones pasan y se integra el cambio, se prepara una versión y se prueba en staging.
- Con entrega continua, el equipo puede autorizar el paso a producción; con despliegue continuo, el pipeline lo realiza automáticamente al cumplirse las reglas.
- Tras la publicación, se comprueba el servicio y se atienden los avisos o problemas observados.
Pasar las pruebas no equivale a estar libre de fallos
Las pruebas solo comprueban los casos que se han preparado. También hay que revisar la configuración, los permisos y el comportamiento en el entorno de destino, y vigilar la aplicación una vez publicada.
5. Otras prácticas relacionadas¶
DevOps se apoya en prácticas complementarias. No es necesario aplicar todas las herramientas a cualquier proyecto: se eligen según sus necesidades.
| Práctica | Para qué sirve | Ejemplos |
|---|---|---|
| Automatización | Repetir tareas con menos intervención manual y de forma consistente. | Scripts y pipelines de CI/CD. |
| Infraestructura como código (IaC) | Definir y versionar infraestructura mediante ficheros de configuración. | Terraform aprovisiona recursos; Ansible automatiza configuración. |
| Monitorización | Observar disponibilidad, errores y rendimiento para detectar problemas. | Prometheus recoge métricas; Grafana permite visualizarlas. |
| Contenedores | Empaquetar una aplicación con parte de lo que necesita para ejecutarse. | Docker crea y ejecuta contenedores; Kubernetes los coordina a escala. |
Contenedores y Kubernetes no son sinónimos
Docker permite construir y ejecutar contenedores. Kubernetes es una plataforma de orquestación que coordina contenedores, por ejemplo en distintos nodos. Un contenedor ayuda a reproducir un entorno, pero no garantiza que cualquier aplicación funcione igual en todos los sistemas: también influyen la arquitectura, la configuración y los servicios externos.
En el módulo aplicaremos estas ideas con control de versiones (Git), automatización (GitHub Actions), contenedores (Docker) y documentación. Más adelante podremos relacionarlas con los servidores web y de aplicaciones en los que se ejecutan las aplicaciones desplegadas.
6. Buenas prácticas¶
Para trabajar con CI/CD de forma fiable, conviene:
- Integrar cambios pequeños y frecuentes: son más fáciles de revisar y, si aparece un fallo, ayudan a acotar su origen.
- Automatizar comprobaciones útiles: mantener pruebas actualizadas y hacer que el equipo vea los resultados de cada ejecución.
- Mantener coherencia entre entornos: versionar la configuración que corresponda y validar la aplicación también en preproducción.
- Proteger el pipeline: limitar permisos y guardar contraseñas, tokens y claves en mecanismos seguros de secretos, nunca en el código fuente.
- Preparar la recuperación: vigilar el servicio tras desplegar y acordar cómo detener o revertir una publicación defectuosa.
7. Errores frecuentes¶
| Error frecuente | Por qué ocurre | Cómo evitarlo |
|---|---|---|
| Pensar que DevOps es una herramienta o solo un puesto de trabajo. | Se confunde el nombre con productos o perfiles profesionales concretos. | Entenderlo como una forma de colaboración apoyada en prácticas y herramientas. |
| Confundir integración continua con despliegue continuo. | Ambas prácticas forman parte de CI/CD y comparten automatización. | Identificar si el flujo comprueba cambios, los deja listos o también los publica. |
| Suponer que una prueba correcta garantiza una versión perfecta. | Las pruebas no cubren todos los fallos ni todas las condiciones de producción. | Combinar pruebas con revisión, controles, seguimiento y recuperación. |
| Tratar staging como una copia idéntica de producción. | Se da por hecho que sus datos, permisos y recursos coinciden. | Revisar las diferencias y validar la configuración de destino. |
| Guardar credenciales dentro del repositorio o del fichero del pipeline. | Se prioriza que el despliegue funcione sin considerar el acceso al código. | Usar secretos protegidos y permisos mínimos para cada tarea. |
8. Resumen¶
En este tema has aprendido que:
- DevOps conecta desarrollo y operaciones para mejorar la entrega y el mantenimiento del software;
- CI integra cambios frecuentes y ejecuta comprobaciones automatizadas;
- la entrega continua deja versiones listas para publicar, mientras que el despliegue continuo automatiza también su paso a producción;
- un pipeline puede construir, probar, revisar y desplegar una aplicación en varios entornos, y su resultado debe supervisarse;
- IaC, monitorización, automatización y contenedores ayudan a hacer el proceso más reproducible, pero no sustituyen las decisiones del equipo.
Idea clave
DevOps no consiste en desplegar más deprisa a cualquier precio: consiste en colaborar, comprobar cada cambio y aprender de su funcionamiento para entregar software de forma repetible y fiable.
9. Para seguir practicando¶
- Realiza la práctica de GitHub Actions y documentación: observa qué evento inicia el flujo, qué comprobaciones ejecuta y qué ocurre cuando una prueba falla.
- Dibuja el pipeline de un proyecto propio e indica en qué punto requiere una aprobación manual.
- Explica qué comprobarías en staging antes de publicar una nueva versión.
Bibliografía y fuentes¶
- Humble, J. y Farley, D. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley.
- Atlassian: ¿Qué es DevOps?.
- Red Hat: ¿Qué es DevOps?.
- GitHub Docs: Entender GitHub Actions.