Un viernes a las seis
Una gestoría de Zaragoza tiene una aplicación que calcula las nóminas de sus clientes.
Un viernes por la tarde, Andrés sube un cambio pequeño directamente al servidor. No lo prueba. El lunes, cuarenta empresas reciben nóminas con el IRPF mal calculado.
Muchos equipos ya no suben nada a mano. Una cadena de pasos automáticos lo comprueba antes.
Al final de esta lección
Nota
Puedo describir un pipeline que prueba y publica el código.
Palabras clave
| Palabra | Qué significa | Ejemplo |
|---|---|---|
| Pipeline | una cadena de pasos automáticos que recorre cada cambio | |
| Etapa | uno de los pasos del pipeline | probar |
| Prueba automática | un código que comprueba otro código | |
| Integración continua | probar cada cambio en cuanto se sube | |
| Despliegue continuo | publicar solo los cambios que pasan las pruebas | |
| Artefacto | el paquete que sale del pipeline | una imagen |
Las celdas que rellenan los estudiantes quedan en blanco en esta vista previa.
Cada cambio recorre las mismas etapas
Con integración continua, cada cambio que llega al repositorio pone en marcha un pipeline.
El pipeline instala las dependencias, ejecuta las pruebas automáticas y empaqueta el resultado. Ese paquete es el artefacto.
Con despliegue continuo, el artefacto llega a producción sin que nadie lo copie a mano. Solo llega si todas las etapas anteriores salen bien.
Una etapa en rojo para todo lo demás
Este guion de Bash hace de pipeline pequeño. La primera línea, set -e, para el guion en cuanto una orden falla.
La prueba comprueba la nómina neta de un sueldo de 2000 € con 300 € de retención.
Ejecútalo tal como está. Después haz el cambio del último comentario y vuelve a ejecutarlo.
Un pipeline en Bash
mkdir -p nominas && cd nominas
printf 'gross=2000\ntax=300\n' > nomina.conf
cat > pipeline.sh <<'FIN'
set -e # si una orden falla, el guion se para aquí
echo "1. Instalar: listo"
echo "2. Probar"
source nomina.conf
test $((gross - tax)) -eq 1700 # la prueba: el neto debe ser 1700
echo " Pruebas superadas"
echo "3. Empaquetar: nominas-2.1.zip"
echo "4. Publicar en producción"
FIN
bash pipeline.sh || echo "Pipeline en rojo: no se publica nada"
# Cambia 1700 por 1800 en la prueba, ejecuta y mira qué etapas faltan.
Un error frecuente
Advertencia
Mucha gente cree que un pipeline en verde significa que el código no tiene errores. No es así. Solo dice que las pruebas que existen han pasado. Si nadie escribió una prueba para un caso, el pipeline no puede verlo.
El pipeline se describe en un archivo
En el trabajo, el pipeline vive en un archivo dentro del repositorio. Así cualquier persona del equipo puede leerlo y proponer cambios.
Herramientas como GitHub Actions, GitLab CI o Jenkins leen ese archivo. El de abajo es de GitHub Actions y está escrito en YAML. Fíjate en needs: publicar espera a que probar termine bien.
Un archivo de pipeline real
# Archivo .github/workflows/pipeline.yml (no se ejecuta aquí)
on: push
jobs:
probar:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: pip install -r requirements.txt
- run: pytest
publicar:
needs: probar # solo empieza si probar sale bien
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
steps:
- run: ./publicar.sh