Curso de DevOps con Github Actions para tu equipo de Desarrollo

Relación entre repositorios locales, remotos, commits, referencias, ramas y tags.

Creación de commits pequeños, trazables y adecuados para procesos de integración continua.

Estrategias de ramas para equipos que realizan despliegues frecuentes.

Uso profesional de `merge`, `rebase`, `squash` y resolución de conflictos.

Diferencias entre ramas de feature, release, hotfix y rama principal.

Pull requests como unidad de revisión, validación automatizada e integración.

Draft pull requests para activar procesos de colaboración antes de solicitar integración.

Reviewers y políticas de revisión de cambios.

CODEOWNERS para asignar responsabilidad sobre código y configuración de pipelines.

Branch protection y rulesets para proteger ramas y tags críticos.

Required status checks asociados a resultados generados por GitHub Actions.

Restricción de integraciones cuando compilación, tests o controles de seguridad no son satisfactorios.

Gestión del historial y trazabilidad entre commits, pull requests, issues y releases.

Tags como identificadores inmutables de versiones y puntos de liberación.

Estrategias para main, desarrollo, releases y correcciones urgentes.

Protección específica de `.github/workflows` frente a modificaciones no controladas.

Sintaxis YAML necesaria para construir y mantener workflows de GitHub Actions.

Mappings, sequences, strings, booleanos, indentación y jerarquía de configuración.

Estructura de un archivo `.yml` o `.yaml` dentro de `.github/workflows`.

Uso de `name` y `run-name` para identificar workflows y ejecuciones.

Configuración de `on` para determinar los eventos que activan una automatización.

Definición de jobs y relación entre trabajos independientes y dependientes.

Selección del entorno mediante `runs-on`.

Definición de steps y diferencias entre `uses` y `run`.

Uso de `id` para referenciar resultados producidos por un step.

Variables mediante `env` a nivel de workflow, job y step.

Configuración de `defaults`, shell y `working-directory`.

Límites mediante `timeout-minutes` y comportamiento de `continue-on-error`.

Sintaxis de expressions mediante `${{ }}`.

Operadores, comparaciones y funciones utilizadas por el motor de expresiones.

Condiciones mediante `if` para controlar jobs y steps.

Uso correcto de `success()`, `failure()`, `always()` y `cancelled()`.

Patrones de estructuración para mantener workflows extensos legibles y mantenibles.

Modelo de eventos de GitHub y relación entre actividad del repositorio y ejecución de workflows.

Automatizaciones basadas en `push` y filtrado por ramas, tags y rutas.

Uso de `pull_request` para validaciones asociadas al ciclo de revisión.

Diferencias de seguridad entre `pull_request` y `pull_request_target`.

Ejecuciones manuales mediante `workflow_dispatch` e inputs parametrizados.

Automatizaciones programadas mediante `schedule` y expresiones cron.

Utilización de `workflow_call` para invocar workflows reutilizables.

Encadenamiento de automatizaciones mediante `workflow_run`.

Filtros `paths`, `paths-ignore`, branches y tags para reducir ejecuciones innecesarias.

Contextos `github`, `runner`, `job`, `steps`, `needs`, `inputs`, `vars` y `secrets`.

Diferencias entre contexts, variables de configuración y variables de entorno.

Creación de outputs desde steps.

Exposición de outputs desde jobs para otros trabajos.

Intercambio de información mediante `needs`.

Ejecución condicional según resultados, eventos, ramas, inputs o características del cambio.

Tratamiento de datos procedentes del evento como contenido potencialmente no confiable.

Prevención de script injection al interpolar valores dentro de comandos shell.

Diseño de workflows con múltiples jobs especializados.

Ejecución paralela de jobs sin dependencias.

Secuenciación mediante `needs`.

Estrategias matrix para ejecutar múltiples combinaciones de configuración.

Matrices por versión de lenguaje, dependencia, sistema operativo o arquitectura.

Uso de `include` y `exclude` para personalizar combinaciones.

Configuración de `fail-fast` según la finalidad de la matriz.

Control de paralelismo mediante `max-parallel`.

Generación dinámica de matrices utilizando outputs de trabajos anteriores.

Concepto de workflow artifact y diferencias respecto a un paquete publicado.

Subida y descarga de binaries, informes, resultados de tests y otros artifacts.

Transferencia de resultados entre jobs sin recompilar.

Políticas de retención de artifacts.

Diferencias entre artifacts y dependency cache.

Construcción de claves de caché utilizando archivos lock y hashes.

Restore keys y estrategias de recuperación parcial.

Caché de npm, Maven, Gradle, pip y otros gestores de dependencias.

Riesgos de cache poisoning y prohibición de almacenar secretos en cachés.

Uso de `concurrency` para impedir ejecuciones o despliegues incompatibles.

`cancel-in-progress` para eliminar trabajo obsoleto y optimizar capacidad.

Función del runner como entorno donde se ejecutan los jobs de GitHub Actions.

Ciclo de asignación de un job desde GitHub hasta un runner disponible.

GitHub-hosted runners con Ubuntu, Windows y macOS.

Arquitecturas x64 y ARM64 y selección según el software que debe construirse.

Software preinstalado y consulta del contenido de las imágenes gestionadas por GitHub.

Naturaleza efímera de los entornos GitHub-hosted entre diferentes jobs.

Selección de runners mediante labels en `runs-on`.

Evaluación de CPU, RAM, almacenamiento y duración según el workload.

Larger runners para cargas que requieren mayor capacidad o características específicas.

Opciones de CPU, memoria, arquitectura y runners con GPU.

IP estática y escenarios donde facilita integración con controles de red.

Private networking disponible para determinados escenarios de larger runners.

Runner groups para organizar capacidad y limitar qué repositorios pueden utilizarla.

Autoscaling administrado de larger runners.

Máxima concurrencia y relación entre capacidad, cola y coste.

Selección del tamaño de runner según compilación, testing y procesamiento.

Análisis del coste frente al ahorro de tiempo obtenido con mayor capacidad.

Casos en los que resulta adecuado ejecutar GitHub Actions sobre infraestructura propia.

Diferencias operativas y de seguridad entre GitHub-hosted y self-hosted runners.

Registro de self-hosted runners en repositorios y organizaciones.

Labels personalizados para enrutar workloads hacia infraestructuras especializadas.

Runner groups como frontera de acceso entre repositorios y capacidad de ejecución.

Acceso desde runners propios a redes, servicios y recursos internos.

Gestión del software instalado y actualización de runners.

Riesgos derivados de la persistencia del workspace y del estado entre ejecuciones.

Separación de workloads confiables y código procedente de fuentes no confiables.

Runners efímeros como patrón para reducir persistencia y contaminación entre jobs.

Arquitectura de Actions Runner Controller como operador de Kubernetes.

Runner scale sets y escalado automático según demanda.

Instalación de ARC mediante sus Helm charts oficiales.

Separación de namespaces para controlador y workloads de runners.

Configuración del mínimo y máximo de runners de un scale set.

Modos de ejecución para container jobs y servicios.

Observabilidad del controlador, listeners y runners efímeros.

Hardening del clúster y aislamiento respecto a workloads de producción.

Diseño del pipeline de integración continua a partir de los eventos del repositorio.

Checkout seguro y reproducible del código fuente.

Preparación automatizada de Node.js, Java, .NET, Python, Go y otros runtimes.

Restauración de dependencias mediante los gestores de paquetes correspondientes.

Acceso autenticado a dependencias privadas.

Validación de archivos lock para mejorar la reproducibilidad.

Compilación de aplicaciones y detección temprana de errores.

Separación entre instalación, build, test y empaquetado.

Generación de binaries y outputs preparados para etapas posteriores.

Identificación de builds mediante commit SHA, rama, tag y versión.

Builds asociados a pull requests para validar cambios antes de integrarlos.

Builds sobre la rama principal como candidatos a entrega.

Ejecuciones programadas para procesos de validación o mantenimiento.

Creación de artifacts reutilizables por los jobs de deployment.

Paralelización de procesos independientes para reducir duración.

Utilización de caché sin comprometer la reproducibilidad.

Identificación de cuellos de botella dentro de la fase CI.

Definición del concepto de pipeline verde y criterios mínimos para permitir la integración.

Integración de unit tests dentro del pipeline.

Ejecución de integration tests sobre servicios reales o efímeros.

Automatización de pruebas end-to-end.

Smoke tests para validar rápidamente builds y despliegues.

Linters y formatters como controles automáticos previos a la integración.

Análisis estático de código dentro de la validación continua.

Publicación de resultados de tests para facilitar su revisión.

Generación y análisis de code coverage.

Definición de umbrales de cobertura según el nivel de riesgo del proyecto.

Matrices de testing sobre diferentes versiones de runtime.

Validación multiplataforma sobre Linux, Windows y macOS.

Service containers para dependencias utilizadas durante las pruebas.

PostgreSQL, MySQL, Redis y otros servicios como dependencias de integration testing.

Health checks para controlar cuándo un servicio está preparado.

Preparación y aislamiento de datos de prueba.

Gestión de tests flaky sin ocultar problemas reales.

Paralelización del test suite.

Required status checks para impedir merges cuando no se superan los controles.

Construcción de quality gates coherentes con criticidad, mantenibilidad y velocidad de entrega.

Diferencias entre workflow, reusable workflow y action.

Utilización de Actions oficiales mantenidas por GitHub.

Localización de componentes reutilizables mediante GitHub Marketplace.

Evaluación del mantenedor, actividad, código y documentación de una Action externa.

Revisión de permisos y comportamiento antes de incorporar una dependencia crítica.

Riesgos derivados de referenciar Actions únicamente mediante tags mutables.

Pinning a commit SHA completo como mecanismo de protección de la supply chain.

Actualización controlada de versiones de Actions externas.

Composite actions para encapsular secuencias de steps reutilizables.

Inputs y outputs de una composite action.

Creación de JavaScript actions para comportamientos que requieren mayor control.

Uso de los toolkits oficiales `@actions/core` y `@actions/github`.

Gestión de errores y outputs desde una JavaScript action.

Docker container actions para ejecutar lógica dentro de un entorno encapsulado.

Selección entre composite, JavaScript y Docker actions.

Versionado semántico de Actions internas.

Publicación y distribución de Actions dentro de una organización.

Ownership, documentación y compatibilidad de componentes reutilizables.

Diferencias entre reusable workflow y composite action.

Declaración de workflows invocables mediante `workflow_call`.

Inputs tipados y parámetros obligatorios o predeterminados.

Paso controlado de secrets entre workflow consumidor y workflow reutilizable.

Uso de `secrets: inherit` y evaluación de sus implicaciones de seguridad.

Outputs de reusable workflows.

Invocación de workflows compartidos desde diferentes repositorios.

Reusable workflows anidados y límites de composición.

Uso de matrices con workflows reutilizables.

Centralización de pipelines estándar por tecnología.

Pipelines compartidos para Java, .NET, Node.js, Python y contenedores.

Workflows corporativos de análisis, seguridad y despliegue.

Workflow templates para acelerar el onboarding de nuevos repositorios.

Repositorios centrales destinados a la automatización de la organización.

Versionado de workflows compartidos sin romper repositorios consumidores.

Interfaces estables mediante inputs, secrets y outputs documentados.

Ownership mediante CODEOWNERS.

Reducción de duplicación y deuda técnica en organizaciones con muchos repositorios.

Diseño de GitHub Actions como plataforma interna de ingeniería.

Diferencias entre variables, secrets y datos incorporados directamente al workflow.

Repository variables, organization variables y environment variables.

Repository secrets, organization secrets y environment secrets.

Ámbito y precedencia de variables y secretos.

Enmascarado de valores sensibles y limitaciones de los mecanismos de masking.

Prevención de filtraciones mediante logs, artifacts, caches y outputs.

Funcionamiento del `GITHUB_TOKEN` generado para cada ejecución.

Configuración explícita del bloque `permissions`.

Aplicación del principio de mínimo privilegio.

Permisos sobre contents, packages, pull requests, issues y otros recursos.

Riesgos derivados de `write-all` y permisos globales innecesarios.

Fine-grained personal access tokens cuando un workflow necesita capacidades no cubiertas por `GITHUB_TOKEN`.

GitHub Apps como alternativa para automatizaciones con identidad y permisos específicos.

Fundamentos de OpenID Connect en GitHub Actions.

Emisión de tokens temporales mediante el permiso `id-token`.

Claims OIDC para limitar confianza por repositorio, rama y environment.

Integración federada con AWS.

Integración federada con Microsoft Azure.

Integración federada con Google Cloud.

Eliminación de credenciales cloud de larga duración cuando existe soporte OIDC.

GitHub Actions como superficie de ejecución con capacidad para ejecutar código y acceder a recursos.

Threat modeling específico de workflows CI/CD.

Aplicación sistemática de permisos mínimos.

Riesgos de Actions y reusable workflows de terceros.

Pinning a SHA completo de dependencias críticas.

Políticas organizativas para restringir Actions externas.

Actualización de dependencias de Actions mediante Dependabot.

Riesgos específicos de workflows ejecutados desde forks.

Protección de secretos frente a pull requests no confiables.

Uso seguro de `pull_request_target`.

Script injection mediante contexts controlables por un atacante.

Dependency graph y análisis de componentes utilizados por el proyecto.

Dependency review para detectar cambios de riesgo introducidos por pull requests.

GitHub Code Security para code scanning y CodeQL sobre repositorios privados.

GitHub Secret Protection para secret scanning y push protection en repositorios privados.

Dependabot alerts y security updates dentro del ciclo de mantenimiento.

Generación y utilización de Software Bill of Materials en formato compatible con SPDX.

Artifact attestations para demostrar procedencia e integridad de los builds.

Verificación de attestations antes de utilizar artifacts críticos.

Protección específica de self-hosted runners frente a persistencia y ejecución de código no confiable.

Integración de la seguridad como quality gate continuo y no como revisión final.

Papel de los contenedores dentro de pipelines modernos de CI/CD.

Construcción automática de imágenes Docker desde GitHub Actions.

Dockerfiles reproducibles y optimizados.

Multi-stage builds para reducir tamaño y superficie de la imagen final.

Uso de `.dockerignore` para controlar el contexto de construcción.

Tags basados en versión, commit SHA y estrategia de release.

Uso de identificadores inmutables para evitar ambigüedad entre builds.

GitHub Container Registry como registro integrado para imágenes OCI.

Autenticación y autorización sobre GHCR.

Publicación y consumo de imágenes privadas.

GitHub Packages para npm, Maven, NuGet y otros ecosistemas soportados.

Permisos de `GITHUB_TOKEN` para trabajar con packages.

Integración con Amazon ECR, Azure Container Registry y Google Artifact Registry.

Escaneo de imágenes antes de su promoción.

Generación de metadata y SBOM.

Artifact attestations para imágenes y paquetes.

Control para impedir publicación cuando no se superan tests o análisis.

Políticas de limpieza, conservación y retención de paquetes.

Concepto de environment como destino de despliegue en GitHub Actions.

Modelado de development, testing, staging y production.

Asociación de jobs de deployment a environments.

Environment variables y environment secrets.

Acceso a secrets únicamente cuando se satisfacen las reglas correspondientes.

Restricciones de ramas y tags autorizados para desplegar.

Required reviewers para aprobar despliegues sensibles.

Prevención de self-review cuando la segregación de funciones lo requiere.

Wait timers para introducir ventanas controladas antes de un despliegue.

Deployment protection rules y relación con los procesos de aprobación.

Integración con sistemas de observabilidad, ITSM o control de cambios mediante GitHub Apps.

Historial de deployments y trazabilidad de versiones.

Promoción de un mismo artifact entre entornos evitando recompilaciones.

Concurrency para impedir despliegues simultáneos incompatibles.

Cancelación de despliegues obsoletos.

Políticas de bypass administrativo y tratamiento de emergencias.

Workflows de rollback y criterios para activarlos.

Separación de responsabilidades entre desarrollo y aprobación de producción.

Patrón general de despliegue desde GitHub Actions hacia un proveedor cloud.

Federación de identidad mediante OIDC en lugar de access keys permanentes.

Aplicación del principio de mínimo privilegio a identidades utilizadas por pipelines.

Patrones de despliegue sobre AWS.

Patrones de despliegue sobre Microsoft Azure.

Patrones de despliegue sobre Google Cloud.

Infrastructure as Code como parte del pipeline de entrega.

Automatización de `terraform fmt` y `terraform validate`.

Generación de `terraform plan` para revisar cambios antes de aplicarlos.

Protección de `terraform apply` mediante environments y controles de aprobación.

Gestión segura del state de Terraform.

Integración con clústeres Kubernetes desde GitHub Actions.

Aplicación y validación de manifests.

Namespaces, ConfigMaps y gestión segura de configuración.

Helm charts como unidad reutilizable de despliegue Kubernetes.

Values diferenciados por entorno.

`helm upgrade` y mecanismos de rollback.

Readiness y health checks posteriores al despliegue.

Smoke tests sobre servicios desplegados.

Diferencias entre CD push-based y GitOps pull-based.

Integración conceptual con Argo CD o Flux para arquitecturas GitOps.

Separación entre pipeline CI y reconciliación continua del estado deseado.

Release management como proceso independiente de la compilación.

Semantic Versioning mediante versiones major, minor y patch.

Creación de tags como referencias de release.

Automatización del cálculo y actualización de versiones.

Generación de changelogs a partir de cambios integrados.

GitHub Releases como registro de una versión publicada.

Adjuntos, packages e imágenes asociados a una release.

Prereleases y release candidates.

Generación automatizada de release notes.

Inmutabilidad del artifact entre construcción y promoción.

Feature flags para desacoplar deployment y activación funcional.

Rolling deployments y sustitución progresiva de instancias.

Estrategia blue-green y cambio controlado entre versiones.

Canary deployment para limitar inicialmente la exposición de una versión.

Progressive delivery basada en validaciones y métricas.

Smoke tests y health checks posteriores al deployment.

Métricas operativas como criterio para mantener o revertir una versión.

Rollback manual y automatizado.

Hotfixes y liberaciones urgentes.

Coordinación de migraciones de base de datos con la versión de aplicación.

Trazabilidad entre commit, pull request, build, artifact, release y deployment.

Historial de workflow runs como punto de partida para diagnóstico.

Visualización de jobs, dependencias y estados dentro de una ejecución.

Análisis detallado de logs de steps.

Búsqueda y descarga de logs para investigación.

Debug logging y runner diagnostic logging.

Diagnóstico de workflows que no se activan.

Resolución de errores de sintaxis y evaluación de expressions.

Investigación de condiciones que producen ejecuciones inesperadas.

Diagnóstico de permisos insuficientes de `GITHUB_TOKEN`.

Fallos relacionados con secrets, variables y environments.

Problemas de checkout, dependencias, artifacts y cache.

Diagnóstico de timeouts y jobs bloqueados.

Self-hosted runners offline y problemas de capacidad.

Análisis de colas y falta de runners disponibles.

Medición de duración por workflow, job y step.

Identificación de etapas con mayor coste temporal.

Optimización de matrices y paralelismo.

Mejora del cache hit rate.

Reducción de descargas y transferencia innecesaria de artifacts.

Selección del tamaño adecuado de runner.

Cancelación temprana de ejecuciones obsoletas.

Control de retención y almacenamiento.

Métricas internas de salud y rendimiento de la plataforma CI/CD.

Diferencias entre monorepos y arquitecturas multirepositorio.

Detección de componentes afectados por un cambio.

Uso de filtros de rutas para evitar pipelines innecesarios.

Creación de matrices dinámicas a partir de módulos modificados.

Construcción y testing únicamente de componentes afectados.

Coordinación de pipelines para frontend, backend, librerías e infraestructura.

Gestión independiente de múltiples servicios dentro del mismo repositorio.

Concurrency por aplicación, servicio o entorno.

Pipelines para builds x64 y ARM64.

Gestión de múltiples cuentas, suscripciones o proyectos cloud.

Separación de permisos por entorno y servicio.

Reusable workflows como capa común para cientos de repositorios.

Políticas organizativas sobre Actions y reusable workflows permitidos.

Requerimiento corporativo de pinning de Actions a SHA completo.

Gobierno de organization secrets, variables y runner groups.

CODEOWNERS aplicado a `.github/workflows` y repositorios centrales de automatización.

Audit log y trazabilidad de cambios en configuraciones críticas.

GitHub CLI mediante `gh workflow` y `gh run`.

API REST de GitHub Actions para workflows, runs y artifacts.

Automatización administrativa mediante GitHub Apps y webhooks.

Definición de estándares y golden paths para nuevos repositorios.

Métricas corporativas de uso, rendimiento, coste y fiabilidad.

Gestión de GitHub Actions como plataforma interna y no como colección aislada de scripts.

Definición de la arquitectura DevOps y del flujo desde el desarrollo hasta producción.

Configuración de repositorio, estrategia de ramas, pull requests, CODEOWNERS y rulesets.

Creación del pipeline de validación para pull requests.

Preparación del runtime y restauración reproducible de dependencias.

Implementación de dependency caching.

Integración de linting, análisis estático y pruebas unitarias.

Ejecución de integration tests y generación de informes.

Configuración de cobertura y quality gates.

Construcción de la aplicación y generación del artifact inmutable.

Creación de una imagen Docker identificada mediante commit y versión.

Publicación en GitHub Container Registry u otro registry definido.

Integración de GitHub Code Security y CodeQL.

Aplicación de GitHub Secret Protection y controles sobre secretos.

Generación de SBOM y artifact attestations.

Creación de reusable workflows para procesos compartidos.

Extracción de lógica común mediante composite actions.

Reducción explícita de permisos de `GITHUB_TOKEN`.

Configuración de federación OIDC con el proveedor cloud seleccionado.

Definición de environments de desarrollo, staging y producción.

Incorporación de aprobación previa al despliegue productivo.

Configuración de concurrency para evitar despliegues incompatibles.

Gestión de infraestructura mediante Terraform.

Despliegue de aplicaciones o servicios sobre Kubernetes.

Utilización de Helm para parametrización y promoción entre entornos.

Ejecución de smoke tests y health checks posteriores al deployment.

Definición de estrategia de rollback.

Automatización del versionado, changelog y GitHub Release.

Diseño de runners según seguridad, capacidad, aislamiento y coste.

Implementación de un runner scale set mediante Actions Runner Controller.

Definición de observabilidad y procedimientos de troubleshooting.

Optimización de caché, matrices, paralelismo, concurrencia y runner sizing.

Creación de una política para adopción y actualización de Actions externas.

Documentación de permisos, runners, environments, dependencias e integraciones.

Elaboración de runbooks de CI/CD, deployment, rollback e incidencias.

Evaluación final de seguridad, velocidad, mantenibilidad, coste, escalabilidad y capacidad de recuperación.