ci-cd-pipeline
$
npx mdskill add 686f6c61/alfred-dev/ci-cd-pipelineAutomatize CI/CD pipelines across GitHub, GitLab, and other platforms.
- Generates tailored pipelines for linting, testing, and deployment automation.
- Integrates with GitHub Actions, GitLab CI, Bitbucket, CircleCI, and Jenkins.
- Detects project stack to recommend the optimal CI/CD platform.
- Outputs ready-to-deploy configuration files in the detected platform format.
SKILL.md
.github/skills/ci-cd-pipelineView on GitHub ↗
--- name: ci-cd-pipeline description: "Configurar pipeline CI/CD adaptado al proyecto. Activar cuando el usuario quiera configurar CI, crear GitHub Actions, configurar GitLab CI, montar un pipeline de despliegue, automatizar tests o implementar integracion continua." --- # 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.
More from 686f6c61/alfred-dev
- acceptance-criteriaGenerar criterios de aceptación en formato Given/When/Then. Activar cuando el usuario quiera definir criterios de aceptacion, usar formato Given When Then, escribir en Gherkin, saber como determinar que algo esta terminado o establecer una definicion de hecho.
- architecture-docsUsar para documentar la arquitectura del sistema. Activar ante: documentar arquitectura, diagrama del sistema, como funciona el proyecto, vision general tecnica
- bundle-sizeAnalizar y reducir el tamaño de bundles frontend. Activar cuando el bundle sea grande, se quiera reducir tamaño, aplicar tree shaking, configurar lazy loading, usar webpack analyzer o analizar el peso de la aplicacion.
- choose-stackUsar para evaluar y elegir tecnologías con matriz de decisión ponderada. Activar cuando el usuario quiera elegir tecnología, comparar frameworks, decidir entre alternativas técnicas, construir una matriz de decisión, evaluar stack, seleccionar base de datos, elegir lenguaje o comparar herramientas.
- code-review-responseUsar al recibir feedback de code review para responder técnicamente. Activar cuando el usuario quiera responder a comentarios de PR, gestionar feedback de code review, resolver comentarios de un revisor, o cuando el revisor pide cambios en el código.
- compliance-checkUsar para verificar cumplimiento RGPD, NIS2 y CRA. También: verificar RGPD, cumplimiento normativo, NIS2, CRA, Cyber Resilience Act, protección de datos, regulación europea.
- copy-reviewRevisar textos publicos: claridad, tono, ortografia y CTAs. Activar ante: revisar textos, mejorar copy, tono de comunicacion, textos de la web, landing page copy
- dependency-strategyEstrategia integral de gestion de dependencias: inventario, evaluacion de riesgo, politica de actualizaciones y documentacion. Usar para auditar el estado global de las dependencias del proyecto.
- dependency-updateRevisar dependencias desactualizadas, con CVEs o end-of-life, y proponer actualizaciones seguras. También: actualizar paquetes, actualizar dependencias, Dependabot, Renovate, versión desactualizada, breaking changes.
- deploy-configConfigurar despliegue según hosting. Activar cuando el usuario quiera desplegar en Vercel, Railway, AWS, configurar hosting, preparar para produccion o gestionar variables de entorno de despliegue.