Cuando alguien empieza en CI/CD, el mayor obstáculo no suele ser el concepto: es el ruido. Jenkins, GitHub Actions, GitLab CI, CircleCI, Travis CI, Azure DevOps, Argo CD, Tekton, Spinnaker, Drone, Buildkite... la lista parece infinita y da la impresión de que hay que elegir bien o se pierden meses. Esta lección es un mapa, no un tutorial. Su objetivo es que sepas colocar cada herramienta en su casilla, entender qué categorías existen y por qué, y descubrir algo que tranquiliza mucho: el 80 % de lo que aprendas en una herramienta se transfiere a las demás, porque todas implementan los mismos conceptos que vimos en 01-01. Al final justificaremos por qué el curso usa GitHub Actions y veremos el mismo trabajo trivial escrito en dos herramientas distintas, para que compruebes de primera mano que lo que cambia es la sintaxis, no la idea.

1. Cómo está organizado el ecosistema
2. Categoría 1: servidores de CI/CD (el corazón del pipeline)
3. Categoría 2: orquestadores de contenedores
4. Categoría 3: registros de artefactos
5. Categoría 4: infraestructura como código
6. Categoría 5: despliegue continuo GitOps
7. Las herramientas, una a una
8. Tabla comparativa de alto nivel
9. Por qué este curso usa GitHub Actions
10. El mismo trabajo en dos herramientas
11. Errores comunes y consejos
12. Ejercicios
13. Conclusión

El primer error al mirar este panorama es meter todas las herramientas en el mismo saco y compararlas entre sí. Argo CD no compite con Jenkins, igual que un destornillador no compite con una caja de herramientas: hacen cosas distintas en momentos distintos del proceso.

La forma útil de organizar el ecosistema es por qué parte del recorrido de un cambio cubre cada herramienta:

Cinco categorías, cinco funciones distintas:

Un proyecto real usa una de cada categoría, no una sola herramienta. Reservalia, al final del curso, usará: GitHub Actions (servidor de CI/CD) + Amazon ECR (registro) + ECS Fargate (orquestador) + Terraform (IaC). Nada de eso es redundante.

Es la categoría que ocupa la mayor parte de este curso, y la que más confusión genera. Dentro de ella, la distinción estructural más importante es alojado (SaaS) frente a autogestionado.

Hay un modelo intermedio muy usado: plataforma alojada con runners propios. Es decir, GitHub Actions coordina y muestra la interfaz, pero los jobs se ejecutan en máquinas tuyas dentro de tu red privada. Combina la comodidad del SaaS con el acceso a sistemas internos y suele ser la elección de empresas medianas con requisitos de red o de cumplimiento.

Otra distinción que marca mucho la experiencia diaria:

• En el repositorio (pipeline as code). El pipeline es un fichero YAML versionado junto al código: se revisa en pull requests, se puede volver atrás, viaja con las ramas. Es el modelo de GitHub Actions, GitLab CI, CircleCI, Travis CI, Tekton y Jenkins moderno con Jenkinsfile.
• En la interfaz del servidor (configuración clicada). El pipeline se configura pinchando en formularios web y vive en la base de datos del servidor. Es el modelo clásico de Jenkins con freestyle jobs, y también es posible en Azure DevOps.

La segunda opción es un antipatrón bien documentado: la configuración no se versiona, nadie sabe quién cambió qué, no se puede reproducir y recuperar el servidor tras un desastre es una pesadilla. Regla práctica: si tu pipeline no está en el repositorio, no está bajo control. Profundizaremos en esto en la lección 04-05.

Un servidor de CI/CD construye y lanza el despliegue, pero no mantiene tu aplicación viva. De eso se encarga el orquestador: decide en qué máquina corre cada contenedor, lo reinicia si muere, lo escala si hay carga, comprueba su salud y sustituye versiones sin cortar el servicio.

Reservalia usará ECS Fargate. Es una decisión deliberada y realista para un equipo de tres personas: Kubernetes para tres servicios y una SRE a tiempo parcial es sobreingeniería. Kubernetes se ve en la lección 06-05, y el caso de microservicios en 05-03.

Recuerda la regla de oro de 01-01: construir una vez, promocionar el mismo artefacto. Para que eso sea posible, el artefacto tiene que vivir en algún sitio del que todos los entornos puedan recuperarlo. Ese sitio es el registro.

Una propiedad crítica de un registro bien usado: los artefactos son inmutables. La etiqueta reservalia/api:a3f9c21 debe apuntar siempre a los mismos bytes. Reetiquetar o sobrescribir destruye la trazabilidad y hace imposible saber qué hay realmente en producción. Por eso etiquetamos con el SHA del commit y no con latest.

Nuria, la SRE de Reservalia, creó a mano en la consola de AWS la base de datos RDS, el balanceador y las reglas de red. Es rápido... una vez. El problema aparece cuando hay que crear un entorno de staging idéntico, o cuando alguien cambia algo un martes y en octubre nadie recuerda por qué.

La infraestructura como código define esos recursos en ficheros versionados:

Lo relevante para esta lección es la categoría: estas herramientas no ejecutan pipelines, definen infraestructura. El pipeline las invoca. Terraform, OpenTofu, Pulumi, CloudFormation y Ansible juegan aquí. Lo desarrollaremos en la lección 03-03.

Es la categoría más reciente y la que peor se entiende, así que merece una explicación del mecanismo.

Los servidores de CI/CD tradicionales usan un modelo push: el pipeline termina y empuja el despliegue al entorno. Para eso, el pipeline necesita credenciales con permiso para modificar producción.

GitOps invierte la dirección. Es un modelo pull: un agente instalado dentro del clúster vigila continuamente un repositorio Git que describe el estado deseado. Cuando detecta una diferencia entre lo que dice el repositorio y lo que hay en el clúster, la corrige él mismo.

Ventajas del modelo pull: el pipeline nunca necesita credenciales de producción (mejora de seguridad importante), el repositorio es la fuente de verdad auditable, y las desviaciones manuales se revierten solas. Inconveniente: añade una pieza más y hoy está muy ligado a Kubernetes.

Herramientas: Argo CD (interfaz web muy visual, muy adoptado) y Flux (más minimalista, sin interfaz propia por defecto).

Ahora sí, la presentación individual. Para cada una: modelo de ejecución, dónde se define el pipeline y SaaS o autoalojado.

• Modelo de ejecución: workflows disparados por eventos del repositorio (push, pull_request, etiquetas, cron, despacho manual). Cada workflow contiene jobs; cada job corre en un runner efímero (máquina virtual limpia que se destruye al terminar).
• Dónde se define: ficheros YAML en .github/workflows/ dentro del propio repositorio.
• SaaS o autoalojado: SaaS, con opción de runners autoalojados en tu infraestructura.
• Rasgo distintivo: el Marketplace de acciones, un catálogo enorme de pasos reutilizables (actions/checkout, actions/setup-node, aws-actions/configure-aws-credentials...). Reduce muchísimo el código que escribes, pero introduce dependencias de terceros que hay que fijar y auditar (lección 04-03).
• Punto fuerte: cercanía total al repositorio. El evento, el código, la revisión y el resultado están en el mismo sitio.
• Punto débil: el modelo de reutilización (workflows reutilizables y acciones compuestas) es menos flexible que un lenguaje de programación real, y los pipelines muy complejos pueden volverse verbosos.

• Modelo de ejecución: un fichero de pipeline con stages que agrupan jobs; cada job lo recoge un runner (con distintos ejecutores: Docker, shell, Kubernetes).
• Dónde se define: .gitlab-ci.yml en la raíz del repositorio.
• SaaS o autoalojado: ambos. GitLab.com es SaaS; GitLab autogestionado es una de las opciones autoalojadas más completas del mercado.
• Rasgo distintivo: es una plataforma DevOps integrada: repositorio, CI/CD, registro de contenedores, gestión de incidencias, escaneo de seguridad y entornos, todo en el mismo producto y con la misma autenticación.
• Punto fuerte: integración vertical y un modelo de plantillas (include, extends) muy potente para reutilizar configuración entre proyectos.
• Punto débil: si te autogestionas GitLab, te haces cargo de una pieza de infraestructura grande.

• Modelo de ejecución: un servidor controlador que orquesta y unos agentes que ejecutan los jobs. Modelo clásico de servidor persistente.
• Dónde se define: idealmente en un Jenkinsfile en el repositorio, escrito en un DSL basado en Groovy (declarativo o scripted). Históricamente también mediante formularios en la interfaz web, lo que produce la deuda técnica que mencionábamos.
• SaaS o autoalojado: autoalojado, siempre. Es software libre que instalas tú.
• Rasgo distintivo: un ecosistema de más de mil plugins. Puede integrarse literalmente con cualquier cosa. Esa es también su maldición: los plugins tienen calidades y ritmos de mantenimiento muy dispares, y las incompatibilidades entre versiones son un clásico.
• Punto fuerte: control absoluto, madurez de más de dos décadas, y el Jenkinsfile al ser código real permite lógica compleja que en YAML sería imposible.
• Punto débil: coste de administración alto (actualizaciones, seguridad, gestión de agentes) y una interfaz que muestra su edad. Aun así, sigue siendo dominante en grandes empresas y en entornos con sistemas internos que nunca saldrán a la nube.
• Lección 06-01.

• Modelo de ejecución: jobs que se ejecutan en contenedores Docker o máquinas virtuales, con soporte nativo para paralelización y división automática de la suite de tests.
• Dónde se define: .circleci/config.yml en el repositorio.
• SaaS o autoalojado: principalmente SaaS; ofrece runners propios y una edición para servidor.
• Rasgo distintivo: los orbs, paquetes reutilizables de configuración (equivalente conceptual a las acciones de GitHub), y una atención muy marcada al rendimiento y al tiempo de ejecución del pipeline.
• Punto fuerte: rapidez, buenas herramientas de caché y paralelismo, agnóstico respecto al proveedor de repositorio.
• Punto débil: una pieza más fuera de tu plataforma de repositorio, con su propia facturación y su propia gestión de accesos.
• Lección 06-03.

• Modelo de ejecución: builds disparadas por eventos del repositorio, ejecutadas en máquinas virtuales o contenedores.
• Dónde se define: .travis.yml en la raíz del repositorio.
• SaaS o autoalojado: SaaS (con una edición empresarial).
• Rasgo distintivo: es históricamente importante: fue el primero en popularizar el modelo de "un YAML en tu repositorio dispara tu CI" y en ofrecerlo gratis a proyectos de código abierto. Prácticamente todo lo que hoy damos por sentado empezó ahí.
• Situación actual: tras el cambio de su modelo gratuito para código abierto, gran parte del ecosistema migró a GitHub Actions y su cuota se redujo mucho. Lo estudiaremos en 06-04 por dos razones: sigue habiendo proyectos que lo usan y hay que saber leerlo, y su configuración es la más sencilla de todas, lo que la hace excelente para entender la esencia de un pipeline.

• Modelo de ejecución: pipelines con stages, jobs y steps, ejecutados en agentes alojados por Microsoft o propios.
• Dónde se define: azure-pipelines.yml en el repositorio (o mediante el editor clásico visual, que es el modelo antiguo).
• SaaS o autoalojado: SaaS (Azure DevOps Services) o autoalojado (Azure DevOps Server, antes TFS).
• Rasgo distintivo: forma parte de una suite completa (Boards, Repos, Artifacts, Test Plans) muy implantada en organizaciones con inversión en el ecosistema Microsoft, y con soporte excelente para .NET y Windows.
• Punto fuerte: entornos de aprobación y controles de gobernanza muy elaborados, útiles en empresas con procesos formales de release.
• Punto débil: conviven dos modelos (clásico visual y YAML) y la documentación histórica mezcla ambos, lo que confunde a quien empieza.

• Modelo de ejecución: no es un servidor de CI. Es un controlador que vive dentro de un clúster de Kubernetes y reconcilia continuamente el estado del clúster con lo declarado en un repositorio Git.
• Dónde se define: manifiestos de Kubernetes (o Helm/Kustomize) en un repositorio Git.
• SaaS o autoalojado: autoalojado en tu clúster (hay ofertas gestionadas de terceros).
• Rasgo distintivo: es la referencia de GitOps. Se combina, no se sustituye: GitHub Actions construye y publica el artefacto, actualiza el manifiesto, y Argo CD se encarga de llevarlo al clúster.
• Cuándo tiene sentido: cuando ya usas Kubernetes. Sin Kubernetes, hoy por hoy, no aplica.

• Modelo de ejecución: un framework de CI/CD nativo de Kubernetes: cada paso del pipeline es un contenedor y cada ejecución es un recurso de Kubernetes (Task, Pipeline, PipelineRun).
• Dónde se define: manifiestos YAML de Kubernetes, versionados en el repositorio.
• SaaS o autoalojado: autoalojado sobre Kubernetes; es la base de varios productos comerciales.
• Rasgo distintivo: no es una herramienta "de usar", es una base para construir tu propia plataforma de CI/CD. Muy potente y muy de bajo nivel.
• Cuándo tiene sentido: organizaciones grandes que construyen una plataforma interna para muchos equipos. Para un equipo de tres personas es claramente excesivo.

Una advertencia sobre esta tabla: no elijas por número de casillas verdes. En la práctica, el criterio que más pesa es dónde vive tu código y qué sabe mantener tu equipo. Los criterios formales de elección los sistematizaremos en la lección 06-07.

La elección de este curso es GitHub Actions, y conviene explicar los motivos para que sepas cuáles son transferibles a tu caso y cuáles no:

1. Cercanía al repositorio. El pipeline vive en el mismo sitio que el código. El evento que lo dispara (un pull request), la revisión, el resultado y el histórico están en la misma pantalla. Para aprender, esto elimina una barrera enorme: no hay un segundo sistema que configurar ni credenciales cruzadas.
2. Modelo declarativo y legible. Un workflow de GitHub Actions se lee de arriba abajo casi como prosa. Al ser declarativo, describes qué quieres, no cómo orquestarlo. Esto hace que los ejemplos del curso sean fáciles de entender aunque nunca hayas visto la herramienta.
3. Coste cero para empezar. Los repositorios públicos tienen ejecución gratuita, y los privados una cuota mensual generosa. Puedes reproducir todos los ejemplos del curso sin pagar nada.
4. Adopción muy amplia. Es hoy la herramienta más probable con la que te encuentres en un proyecto nuevo, y aparece constantemente en ofertas de empleo.
5. Los conceptos son universales. Todo lo que aprenderás —triggers, jobs, matrices, artefactos, caché, secretos, entornos con aprobación, promoción— existe con otro nombre en todas las demás. La sección siguiente lo demuestra.

Y por honestidad, los motivos por los que podrías elegir otra:

• Tu código no está en GitHub → GitLab CI o CircleCI encajan mejor.
• Necesitas acceder a sistemas internos que no salen de tu red → Jenkins o runners autoalojados.
• Tu organización ya tiene una plataforma establecida → aprende esa; el conocimiento se transfiere igual.

El módulo 6 profundiza en cada herramienta por separado (Jenkins en 06-01, GitLab CI en 06-02, CircleCI en 06-03, Travis CI en 06-04, Docker y Kubernetes en 06-05, GitHub Actions a fondo en 06-06) y en la lección 06-07 veremos los criterios formales para elegir. Además, en ese módulo reexpresaremos el mismo pipeline de Reservalia en cada herramienta, que es la mejor forma de comprobar que lo aprendido se transfiere.

Vamos a verlo ya, en pequeño. El trabajo es deliberadamente trivial: instalar las dependencias y ejecutar los tests de apps/api cuando alguien empuja código.

Importante: no es necesario que entiendas cada línea. Aquí solo queremos que compares las dos columnas y veas que dicen lo mismo. La construcción real del pipeline de Reservalia empieza en la lección 02-02.

Pon las dos al lado y verás que los conceptos son idénticos; solo cambia dónde se escribe cada uno:

Las dos diferencias filosóficas que explican casi todo lo demás:

• GitHub Actions apuesta por acciones reutilizables del Marketplace (setup-node, checkout), que encapsulan trabajo. Escribes menos, pero dependes de terceros.
• GitLab CI apuesta por imágenes Docker como unidad de entorno. Más explícito y con menos magia, pero eliges tú la imagen correcta.

Y lo que no cambia en ninguna herramienta del mundo:

1. Un evento del repositorio dispara la ejecución.
2. Se prepara una máquina limpia con el código.
3. Se instalan dependencias de forma reproducible.
4. Se ejecutan comandos.
5. Si un comando devuelve un código de salida distinto de cero, el pipeline falla.

Ese último punto es especialmente liberador: la unidad universal de éxito o fracaso en CI/CD es el código de salida de un proceso. Todas las herramientas, sin excepción, se apoyan en él.

Error 1: comparar herramientas de categorías distintas. "¿Qué es mejor, Jenkins o Argo CD?" es una pregunta mal planteada: uno ejecuta pipelines y el otro sincroniza clústeres. Antes de comparar, sitúa cada herramienta en su casilla del mapa de la sección 1.

Error 2: elegir por popularidad. Que Kubernetes sea el estándar no significa que tu equipo de tres personas lo necesite. La mejor herramienta es la que tu equipo puede mantener sin dedicarle un tercio de su tiempo. Reservalia elige ECS Fargate por eso mismo.

Error 3: creer que la elección es irreversible. Como acabas de ver, migrar un pipeline entre herramientas es sobre todo un trabajo de traducción de sintaxis. Lo que sí cuesta migrar es lo que está mal hecho: pipelines configurados desde una interfaz web, scripts inmensos e imposibles de leer o secretos incrustados en el YAML. Invierte en que tu pipeline esté bien hecho, no en elegir la herramienta perfecta.

Error 4: configurar el pipeline desde la interfaz gráfica. Es tentador porque es rápido. Seis meses después nadie sabe quién cambió qué, no se puede revertir y recuperar el servidor es imposible. Todo pipeline debe vivir en el repositorio.

Error 5: acumular herramientas sin necesidad. Añadir Argo CD "porque es GitOps" a un proyecto que ni siquiera usa Kubernetes añade complejidad sin beneficio. Cada herramienta nueva es un sistema más que aprender, mantener, actualizar y depurar a las tres de la mañana.

Consejo 1: aprende una a fondo antes que cinco por encima. El conocimiento profundo de una herramienta se transfiere; el conocimiento superficial de cinco, no. Por eso este curso construye todo en GitHub Actions y solo al final, en el módulo 6, traduce.

Consejo 2: usa el criterio "dónde vive mi código". Es el filtro más eficaz. GitHub → GitHub Actions. GitLab → GitLab CI. Servidor Git interno → Jenkins o GitLab autoalojado. Este criterio simple acierta en la gran mayoría de casos.

Consejo 3: fija las versiones de las acciones y plugins que uses. actions/checkout@v4 en lugar de actions/checkout@main. Una acción de terceros es código ajeno ejecutándose con acceso a tu repositorio. Es una superficie de ataque real y le dedicaremos atención en la lección 04-03.

Consejo 4: al leer documentación, tradúcela mentalmente a los conceptos de 01-01. Cuando encuentres un término nuevo, pregúntate: ¿esto es un trigger, un job, una etapa, un runner o un artefacto? Casi siempre es una de esas cinco cosas con otro nombre, y esa traducción convierte la documentación de cualquier herramienta en algo familiar.

Coloca cada herramienta en su categoría del mapa de la sección 1 (servidor de CI/CD, orquestador de contenedores, registro de artefactos, IaC o despliegue GitOps) e indica en una frase qué problema resuelve:

1. Terraform
2. Amazon ECR
3. Flux
4. Amazon ECS Fargate
5. CircleCI
6. Nexus
7. Kubernetes
8. Tekton

Traduce el siguiente workflow de GitHub Actions a .gitlab-ci.yml. Añade después una tabla de equivalencias concepto a concepto.

Para cada equipo, recomienda una combinación de herramientas (servidor de CI/CD + registro + destino de ejecución, y GitOps o IaC si procede) y justifica cada elección en una o dos frases. No hay una única respuesta correcta; se valora la justificación.

1. Reservalia. Tres personas. Código en GitHub. Despliegan a AWS con ECS Fargate. Ninguna experiencia previa en CI/CD. Presupuesto muy ajustado.
2. Banco Meridiano. Equipo de plataforma de 40 personas. El código está en un servidor Git interno que no puede salir de la red corporativa por normativa. Despliegan a un Kubernetes local. Necesitan aprobaciones registradas y auditables por cada despliegue a producción.
3. Ludika. Estudio de videojuegos de 15 personas. Código en GitLab.com. Compilan builds para Windows, macOS y Linux en cada release. Los artefactos pesan varios gigabytes.

Solución al Ejercicio 1

Dos observaciones que conviene haber notado:

• Flux y Tekton están ambos "en Kubernetes" pero no son la misma categoría. Tekton ejecuta pipelines (construye y prueba); Flux sincroniza el estado desplegado. Se usan juntos, no en lugar del otro.
• ECR y Nexus están en la misma categoría aunque uno sea un servicio gestionado de AWS y el otro un producto instalable: la categoría la define la función, no el modelo de distribución.

Solución al Ejercicio 2

Tabla de equivalencias:

Un matiz sutil que merece la pena entender: en GitHub Actions cada run es un shell independiente, por eso hay que repetir working-directory en cada paso —un cd en un paso no afecta al siguiente. En GitLab, todos los comandos de script comparten el mismo shell, así que un solo cd basta. Esta diferencia sorprende a mucha gente al migrar en cualquiera de los dos sentidos.

Solución al Ejercicio 3

1. Reservalia

• Servidor de CI/CD: GitHub Actions. El código ya está en GitHub: sin sistemas adicionales, sin credenciales cruzadas y con cuota gratuita suficiente para un equipo de tres. Coste de arranque prácticamente nulo, que es determinante sin experiencia previa ni presupuesto.
• Registro: Amazon ECR. Está en la misma nube que la ejecución, la autenticación se resuelve con IAM y las descargas dentro de la misma región no generan tráfico saliente facturable.
• Ejecución: ECS Fargate. Ya es su destino. Es la decisión correcta para tres personas: contenedores sin administrar un clúster. Kubernetes aquí sería sobreingeniería y consumiría el tiempo de Nuria.
• IaC: Terraform, a partir del módulo 3, para que staging y prod sean reproducibles y no dependan de lo que Nuria recuerde haber clicado.
• GitOps: no. No usan Kubernetes; Argo CD no aporta nada aquí y sí complejidad.

2. Banco Meridiano

• Servidor de CI/CD: Jenkins autoalojado (o GitLab autogestionado). Es el criterio decisivo: el código no puede salir de la red. Cualquier SaaS queda descartado por normativa, no por preferencia. El tamaño del equipo (40 personas) justifica el coste de administración, que en Reservalia sería prohibitivo.
• Registro: Artifactory o Nexus en la red interna, con función añadida de proxy de dependencias externas: útil cuando la salida a internet está restringida.
• Ejecución: su Kubernetes local, ya existente.
• GitOps: Argo CD, muy recomendable. Aquí encaja perfectamente por dos razones: ya tienen Kubernetes, y el modelo pull elimina la necesidad de que el sistema de CI tenga credenciales de producción, lo cual es un argumento de peso ante un auditor. Además, el repositorio Git de manifiestos se convierte en el registro auditable de qué se desplegó, cuándo y aprobado por quién.
• Aprobaciones: puertas manuales obligatorias antes de producción. Es un caso claro de Entrega Continua y no de Despliegue Continuo, y esa puerta es un requisito regulatorio, no una carencia.

3. Ludika

• Servidor de CI/CD: GitLab CI/CD. El código está en GitLab.com: aplica el criterio "dónde vive mi código". Además, el registro de paquetes y contenedores viene integrado en el mismo producto.
• Registro: GitLab Package Registry, con una salvedad importante: builds de varios gigabytes por plataforma y por release consumen almacenamiento muy rápido. Hay que definir una política de retención desde el primer día (por ejemplo, conservar todas las builds de release y solo las últimas N de desarrollo) o la factura se descontrola.
• Ejecución multiplataforma: runners propios. Aquí hay una restricción que mucha gente descubre tarde: compilar para macOS requiere hardware Apple, por licencia. Habrá que usar runners macOS propios o alojados de un proveedor especializado, y sabiendo que su coste por minuto es sensiblemente mayor.
• Consideración adicional: con artefactos tan pesados, el tiempo y el coste de subida y bajada dominan el pipeline. Merece la pena invertir en caché de dependencias y en compilación incremental antes que en cualquier otra optimización (materia de la lección 04-04).
• GitOps: no aplica. El producto no se despliega en un clúster; se distribuye a usuarios finales.

Esta lección ha ordenado el ruido del ecosistema:

• Las herramientas se organizan en cinco categorías complementarias: servidores de CI/CD, orquestadores de contenedores, registros de artefactos, infraestructura como código y despliegue GitOps. No compiten entre categorías: se combinan.
• Dentro de los servidores de CI/CD, las dos preguntas que más definen la experiencia son SaaS o autoalojado y dónde se define el pipeline. Y hay una respuesta que no admite matices: el pipeline debe vivir en el repositorio, nunca en formularios de una interfaz web.
• Hemos situado GitHub Actions, GitLab CI/CD, Jenkins, CircleCI, Travis CI, Azure DevOps Pipelines, Argo CD y Tekton, cada una con su modelo de ejecución y su terreno natural.
• El curso usará GitHub Actions por su cercanía al repositorio, su modelo declarativo legible y su coste nulo para empezar; el módulo 6 profundiza en cada herramienta y reexpresa el pipeline de Reservalia en varias de ellas.
• Y lo más importante: al comparar el mismo trabajo en GitHub Actions y en GitLab CI hemos comprobado que lo que cambia es la sintaxis, no los conceptos. Trigger, job, etapa, runner, pasos y código de salida están en todas. Lo que aprendas aquí se transfiere.

Ya sabemos qué es CI/CD, por qué merece la pena y con qué se construye. Falta lo más concreto: qué vamos a automatizar exactamente. En la siguiente lección, El Proyecto del Curso: la Aplicación que Vamos a Automatizar, conoceremos Reservalia a fondo: su producto, su equipo, la estructura real del repositorio, los scripts que el pipeline invocará, sus tres entornos y la infraestructura AWS de destino. También veremos la hoja de ruta de qué habremos automatizado al final de cada módulo y qué necesitas instalado para seguir los ejemplos, uses Node.js o no.