Configurar pipeline CI/CD

Resumen

Este skill genera la configuración de un pipeline de integración y despliegue continuo adaptado al stack y la plataforma del proyecto. El pipeline automatiza las verificaciones de calidad (lint, tests, seguridad) y el despliegue, eliminando pasos manuales propensos a error.

Un buen pipeline es rápido (feedback en minutos, no en horas), fiable (no falla aleatoriamente) y seguro (no expone secretos ni permite despliegues sin verificación).

Proceso

1. Detectar la plataforma de CI/CD. Consultar el stack detectado en la configuración de Alfred para adaptar el pipeline al lenguaje, framework y herramientas del proyecto. Identificar dónde se ejecutará el pipeline:

   • GitHub Actions: .github/workflows/.
   • GitLab CI: .gitlab-ci.yml.
   • Bitbucket Pipelines: bitbucket-pipelines.yml.
   • CircleCI: .circleci/config.yml.
   • Jenkins: Jenkinsfile.

   Si no hay preferencia, recomendar GitHub Actions por su ecosistema y facilidad de uso.

2. Definir los stages del pipeline. El orden estándar es:

   Stage	Propósito	Falla si...
   Lint	Verificar estilo y errores estáticos	Hay errores de linter
   Test	Ejecutar tests unitarios e integración	Algún test falla
   Build	Compilar/construir el artefacto	La build falla
   Security	Escanear vulnerabilidades	Hay CVE críticos o altos
   Deploy	Desplegar al entorno objetivo	El despliegue falla

3. Configurar caché de dependencias. Evitar descargar las mismas dependencias en cada ejecución:

   • Node.js: cachear node_modules con key basada en package-lock.json.
   • Python: cachear el directorio de pip con key basada en requirements.txt.
   • Rust: cachear target/ y el directorio de cargo.

4. Gestionar secretos. Los secretos (tokens, contraseñas, API keys) nunca van en el código:

   • Usar el sistema de secretos de la plataforma (GitHub Secrets, GitLab Variables, etc.).
   • Referenciar como variables de entorno en el pipeline.
   • Documentar qué secretos son necesarios y dónde se configuran.

5. Configurar triggers. Definir cuándo se ejecuta el pipeline:

   • Push a ramas principales (main, develop): pipeline completo.
   • Pull requests: lint + test + build (sin deploy).
   • Tags de versión: pipeline completo con deploy a producción.

6. Configurar notificaciones de fallo. El equipo debe enterarse rápidamente cuando algo falla:

   • Notificación a Slack, email o similar cuando un stage falla.
   • Indicar qué stage falló y enlace al log.

7. Configurar estrategia de deploy. Según el entorno:

   • Staging: deploy automático en cada merge a develop.
   • Producción: deploy manual o automático en cada tag de versión, según la preferencia del equipo.

8. Documentar el pipeline. Añadir un comentario en el fichero de configuración explicando cada stage y cómo añadir nuevos pasos.

Criterios de éxito

• El pipeline cubre lint, test, build, security y deploy.
• Las dependencias se cachean para acelerar la ejecución.
• Los secretos se gestionan vía variables de entorno de la plataforma, no en el código.
• Los triggers están configurados para PRs, pushes y tags.
• Hay notificaciones de fallo configuradas.
• El fichero de configuración está documentado con comentarios.

Que NO hacer

• No crear pipelines sin paso de tests. Un pipeline sin verificación automática no aporta confianza; simplemente automatiza despliegues potencialmente rotos.
• No guardar secretos en el código del pipeline. Los tokens, contraseñas y API keys se gestionan exclusivamente a través del sistema de secretos de la plataforma (GitHub Secrets, GitLab Variables, etc.), nunca en texto plano en el fichero de configuración.