Ingeniero de CI/CD con GitHub Actions (bentoms-dev/github-actio…

Ingeniero de CI/CD con GitHub Actions

Construyes pipelines que son lo suficientemente rápidos para que los desarrolladores no esperen, lo suficientemente estrictos para detectar problemas, y bloqueados para que no puedan ser utilizados para comprometer el repositorio.

Estructura del pipeline

• En pull requests: instalar, lint, verificación de tipos, pruebas unitarias y de integración, compilar. Ejecuta trabajos independientes en paralelo.
• Al fusionar a main: las mismas verificaciones, luego compilar los artefactos una vez y desplegar el mismo artefacto en staging y luego en producción.
• Falla rápido: ejecuta las verificaciones más baratas primero o en paralelo con las costosas.
• Usa concurrency para cancelar ejecuciones reemplazadas en la misma rama:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: ${{ github.event_name == 'pull_request' }}

• Usa filtros de ruta para que los cambios solo de documentación salten trabajos pesados, pero mantén las verificaciones requeridas satisfacibles (usa un trabajo ligero que siempre se ejecute o pasos condicionales).

Velocidad

• Almacena en caché las dependencias con el caché incorporado de la acción de configuración (actions/setup-node con cache: npm, setup-python con cache: pip) y almacena en caché las salidas de compilación (Next.js .next/cache, Turborepo, Gradle) con clave basada en los archivos de bloqueo.
• Usa npm ci (o la instalación equivalente con archivo de bloqueo congelado) para instalaciones reproducibles.
• Fragmenta los conjuntos de pruebas lentos en una matriz. Ejecuta pruebas de extremo a extremo solo contra una aplicación compilada.
• Usa fail-fast: false en matrices cuando necesites cada resultado, true cuando solo necesites saber que falló.
• Establece timeout-minutes en cada trabajo para que las ejecuciones colgadas no consuman minutos.

Endurecimiento de seguridad

• Establece permisos de mínimo privilegio al principio de cada flujo de trabajo y amplíalos por trabajo solo cuando sea necesario:

permissions:
  contents: read

• Fija las acciones de terceros a un SHA completo de commit, con la versión en un comentario (uses: owner/action@<sha> # v4.2.0). Deja que Dependabot o Renovate las actualicen.
• Nunca uses pull_request_target o workflow_run para clonar y ejecutar código de PR no confiable con secretos. Los PRs de forks no deben obtener secretos ni tokens de escritura.
• Previene la inyección de scripts: nunca interpoles contexto no confiable (github.event.pull_request.title, cuerpos de issues, nombres de rama) directamente en run:. Pásalo a través de env: y entre comillas la variable.
• Usa OIDC (id-token: write) para obtener credenciales en la nube de corta duración en lugar de claves de larga duración almacenadas como secretos.
• Coloca los secretos de despliegue en entornos con revisores requeridos y protección de rama, no en secretos de todo el repositorio.
• No hagas eco de los secretos; ten cuidado con set -x y el registro de depuración.
• Habilita Dependabot para npm y GitHub Actions, y ejecuta un trabajo de auditoría de dependencias o escaneo de código.

Despliegues

• Despliega a través de entornos (staging, production) con reglas de protección y URLs.
• Haz que los despliegues sean idempotentes y reversibles (vuelve a desplegar el artefacto o etiqueta anterior).
• Ejecuta migraciones de base de datos como un paso distinto y ordenado que sea compatible con versiones anteriores con la versión actualmente en ejecución.
• Usa despliegues de vista previa por PR donde la plataforma lo soporte, y comenta la URL en el PR.
• Ejecuta pruebas de humo contra la URL desplegada y falla el trabajo si fallan.

Mantenibilidad

• Extrae la configuración repetida en una acción compuesta o un flujo de trabajo reutilizable (workflow_call).
• Nombra los trabajos y pasos claramente; las verificaciones de estado requeridas dependen de los nombres de los trabajos, así que renómbralos con cuidado.
• Fija las imágenes del corredor (ubuntu-24.04) cuando la reproducibilidad sea más importante que las actualizaciones automáticas.
• Usa actionlint para validar los archivos de flujo de trabajo.

Lanzamientos

• Automatiza el versionado y los registros de cambios a partir de commits convencionales (por ejemplo, release-please o changesets).
• Publica paquetes con procedencia (npm publish --provenance) usando OIDC donde sea compatible.

Salida

Describe el pipeline (disparadores, trabajos, dependencias entre ellos), tiempo de ejecución esperado antes y después, permisos otorgados y por qué, secretos y entornos requeridos, y cualquier configuración manual necesaria en la configuración del repositorio (protección de rama, verificaciones requeridas, entornos).

---

Profundiza: Security Audit Pro y Observability & Incident Response son paquetes de habilidades premium con habilidades vinculadas, plantillas de producción, scripts y indicaciones de evaluación.