5.4Despliegue & CI/CD (GitHub Actions, cloud)
Lo esencial en 30 segundos
- CI guardiana : en cada push, checkout → install → ruff + pytest — el rojo bloquea, el verde autoriza.
- Entregar versionado : imagen Docker al registro o plataforma conectada al depósito — cada puesta en línea es trazable.
- Prod sobria : secretos fuera del YAML, logs y /health, rollback probado — desplegar es poder volver.
Mini-caso hilado — Nabil publica en línea en Argel
El análisis contenerizado de Nabil gira bien — pero solo en los puestos del equipo en Argel. Lo pone en línea : depósito Git conectado, workflow GitHub Actions que lanza ruff y pytest en cada push, imagen versionada entregada en una plataforma conectada al depósito, logs y endpoint de salud en su sitio. Último episodio de los casos 5.1-5.3 — Nabil cierra del código pro a la app viva.
Último episodio de los casos 5.1-5.3 — Nabil cierra diseño, async y Docker con la puesta en producción.
1. La CI : probar en cada push
El workflow GitHub Actions es el guardián : checkout → instalar Python → pip install -r requirements → ruff + pytest. Cada push se prueba en minutos : el rojo bloquea la fusión, el verde autoriza. La CI no es una opción que se « pondrá más tarde » — está en su sitio desde el primer test. Nabil provoca voluntariamente un fallo para ver la alerta : el día que falle de verdad, sabrá leer el rojo.
La insignia verde del README prueba la exigencia : estilo + tests en cada cambio, sin intervención humana.
2. Entregar : imagen o plataforma
Dos vías complementarias. La imagen Docker subida al registro (ver 5.3) : trazable, reproducible, desplegada donde se quiera. O la plataforma conectada al depósito (tipo Render, Railway, Fly y equivalentes) : cada push verde actualiza el sitio automáticamente — simple para empezar. Secretos en secrets del depósito, nunca en el YAML : la prod se configura, no se codifica. Nabil compara las ofertas al elegir (las fórmulas evolucionan) y apunta a la vía simple primero, el control después.
En ambos casos, cada entrega está versionada (tags, SHA) : se sabe exactamente qué hay en línea.
3. El mínimo prod : logs, salud, rollback
Desplegar = poder volver. El mínimo : logs estructurados (logging), endpoint /health para la supervisión, versiones para volver atrás. Sin rollback probado, cada puesta en prod es un salto sin paracaídas. Nabil prueba el retorno antes de la gran noche : el día de un incidente, restaura en lugar de improvisar — y hace validar la elección de infraestructura y los accesos por su DSI antes de exponer datos reales.
Sin este trío, no se despliega : se apuesta.
🔎 Ejemplo concreto — El workflow de Nabil
Estilo + tests en cada push, insignia verde en prueba.
name: ci
on: [push]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with: {python-version: "3.12"}
- run: pip install -r requirements.txt
- run: ruff check . && pytest -qLectura : estilo + tests en cada push — el rojo bloquea la fusión.
Lección : la insignia verde del README prueba la exigencia en continuo.
Vocabulario de la sección
- Despliegue
- Hacer la app accesible en línea, fuera de vuestro puesto.
Ejemplo sencillo: El análisis de Nabil deja localhost por una dirección pública.
Lo que no es: un script que solo gira en su PC.
Reflejo: ¿mi app es alcanzable fuera de mi puesto?
- CI
- Probar automáticamente cada cambio, desde el primer test.
Ejemplo sencillo: Cada push de Nabil lanza ruff y pytest.
Lo que no es: tests lanzados a mano cuando se piensa.
Reflejo: ¿un push puede pasar sin prueba?
- Pipeline
- Serie de pasos auto (tests, build, despliegue) activada en cada push.
Ejemplo sencillo: El workflow de Nabil : instalar, controlar, probar.
Lo que no es: una puesta en línea manual a base de copiar-pegar.
Reflejo: ¿mi entrega es reproducible?
- GitHub Actions
- Pipelines descritos en YAML versionado en .github/workflows.
Ejemplo sencillo: El archivo ci.yml de Nabil, releído como código.
Lo que no es: un servidor misterioso que despliega no se sabe cómo.
Reflejo: ¿mi pipeline está versionado y es releíble?
- Rollback
- Volver a la versión anterior, probado antes de necesitarlo.
Ejemplo sencillo: Nabil restaura la versión anterior tras un incidente.
Lo que no es: reparar en pánico directamente en prod.
Reflejo: ¿he probado mi vuelta atrás?
En la práctica — Automatizar tests y despliegue
- Versionad vuestro proyecto con Git y subidlo a un depósito GitHub (git init, add, commit, push).
- Cread un workflow GitHub Actions (.github/workflows/ci.yml) que instale las dependencias y lance pytest en cada push.
- Verificad en la pestaña « Actions » que el pipeline se ejecuta y pasa en verde ; provocad un fallo de test para ver la alerta.
- Desplegad la aplicación en una plataforma cloud (Render/Railway) conectada al depósito : cada push actualiza el sitio automáticamente.
Guion listo para decir — anunciar la puesta en línea
« Nuestro análisis está listo para salir de localhost : pongo la CI desde el primer test — ruff y pytest en cada push, el rojo bloquea. Entrego versionado vía la plataforma conectada al depósito, secretos en secrets del depósito, logs y endpoint de salud en su sitio, rollback probado. Antes de exponer datos reales, hago validar la infraestructura y los accesos por la DSI. »
Para decir al responsable para validar la puesta en línea y el circuito DSI sobre los datos sensibles.
Modelo copiar-pegar — workflow CI Python genérico
name: ci
on: [push]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with: {python-version: "3.12"}
- run: pip install -r requirements.txt
- run: ruff check . && pytest -qSolo / presupuesto pequeño
Nabil solo : el workflow mínimo (ruff + pytest) basta — la CI gratuita del depósito guarda la prod.
PYME / equipo reducido
Insignia verde + rojo que bloquea la fusión : nadie entrega sin prueba, ni con prisa.
PYME en Argel
Nabil hace validar alojador, accesos y copias por la DSI en Argel antes de exponer datos reales.
Equipo que empieza
Pareja : uno escribe el workflow, el otro verifica secretos, /health y rollback ; revisión antes de la primera prod.
✓ Buenas prácticas
- CI desde el primer test : el verde autoriza, el rojo bloquea.
- Secretos en secrets del depósito, nunca en claro en el YAML.
- Rollback probado antes de la prod : desplegar es poder volver.
✗ Errores frecuentes
- « Pondremos la CI más tarde » (las regresiones salen en silencio).
- Secretos en claro en el YAML versionado.
- Desplegar sin vuelta posible ni supervisión (/health, logs).
Puntos clave
- El despliegue hace la aplicación accesible en línea (cloud/PaaS).
- La CI/CD automatiza tests y puesta en línea en cada cambio del código.
- GitHub Actions describe los pipelines en un archivo YAML versionado.
- Git/GitHub es la base : versionado, colaboración y disparador de los pipelines.
Reto 48h — aplica mañana
Añadid el workflow anterior a 1 depósito : ¿sube en verde — y el rojo bloquea tras un fallo provocado?
- Puedo explicar CI vs CD en una frase.
- Mi workflow prueba en cada push (verde probado).
- Sé dónde van los secretos (fuera del YAML).
Preguntas frecuentes
¿Qué aporta la CI/CD frente a un despliegue manual?
Elimina los errores humanos y el tiempo perdido : en cada modificación, los tests se ejecutan automáticamente y, si pasan, la aplicación se pone en línea sin intervención. Se entrega más a menudo, más rápido y más seguro — un estándar de los equipos modernos. Y el rojo que bloquea la fusión vale todas las llamadas al orden.
¿Dónde alojar una aplicación Python a menor coste?
Plataformas conectadas al depósito (tipo Render, Railway, Fly y equivalentes) proponen tramos de entrada y un despliegue automático desde GitHub : ideal para empezar. Para más control, las grandes clouds son más potentes pero más complejas — por reservar a las necesidades que lo justifiquen. Comparad las ofertas al elegir (evolucionan) y haced validar por la DSI antes de exponer datos sensibles.
¿Qué hace un pipeline CI/CD (p. ej. GitHub Actions)?