Git y Plataformas de Integración Continua

Control de Versiones: Conceptos Fundamentales

Sistema de Control de Versiones (VCS / SCM): herramienta que registra los cambios realizados sobre un conjunto de archivos a lo largo del tiempo, permitiendo recuperar versiones anteriores, comparar cambios y colaborar entre múltiples desarrolladores.

Tipos de sistemas de control de versiones

Tipo	Descripción	Ejemplos	Limitaciones
Local (LVCS)	Base de datos local de parches entre versiones	RCS, SCCS	No permite colaboración
Centralizado (CVCS)	Un servidor central almacena todos los archivos versionados	SVN, CVS, Perforce	Punto único de fallo; requiere conexión
Distribuido (DVCS)	Cada cliente tiene una copia completa del repositorio	Git, Mercurial, Bazaar	Mayor complejidad inicial

Ventajas del control de versiones

📜

Historial completo

Registro de todos los cambios con autor, fecha y mensaje descriptivo.

🔀

Ramificación

Desarrollo paralelo de funcionalidades sin interferir entre equipos.

🔄

Reversibilidad

Capacidad de deshacer cambios y volver a cualquier estado anterior.

👥

Colaboración

Múltiples desarrolladores trabajando simultáneamente sobre el mismo código.

🔍

Trazabilidad

Vinculación de cambios con issues, tickets o requisitos del sistema.

🛡️

Respaldo

El repositorio actúa como copia de seguridad del código fuente.

Git: Arquitectura y Fundamentos

Git es un sistema de control de versiones distribuido, libre y de código abierto. Creado por Linus Torvalds en 2005 para el desarrollo del kernel de Linux. Diseñado con énfasis en velocidad, integridad de datos y soporte para flujos de trabajo distribuidos y no lineales.

Características diferenciales de Git

Instantáneas (snapshots), no diferencias: Git almacena el estado completo del proyecto en cada commit (no solo los cambios/diffs como SVN o CVS).
Casi todas las operaciones son locales: no requiere conexión de red para consultar historial, crear ramas, hacer commits, etc.
Integridad garantizada: cada objeto se identifica por su hash SHA-1 (40 caracteres hexadecimales). Cualquier corrupción es detectable.
Generalmente solo añade datos: es muy difícil que Git pierda datos una vez confirmados.
Ramas ligeras: crear una rama es crear un puntero de 41 bytes, operación casi instantánea.

Los tres estados de Git

Estado	Zona / Área	Descripción	Comando principal
Modified	Working Directory (árbol de trabajo)	Archivo modificado pero no preparado para commit	`git status`
Staged	Staging Area (índice / index)	Archivo marcado para incluirse en el próximo commit	`git add`
Committed	Git Directory (repositorio .git)	Datos almacenados de forma segura en el repositorio local	`git commit`

Objetos internos de Git

Objeto	Descripción	Identificado por
Blob	Contenido de un archivo (sin nombre ni metadatos)	Hash SHA-1 del contenido
Tree	Directorio: lista de blobs y otros trees con sus nombres	Hash SHA-1 del árbol
Commit	Instantánea del proyecto + metadatos (autor, fecha, mensaje, padre)	Hash SHA-1 del commit
Tag	Puntero con nombre a un commit específico (versión)	Nombre + hash SHA-1
Branch	Puntero móvil a un commit (no es un objeto, es una referencia)	Nombre de la rama
HEAD	Puntero especial que indica el commit actual (rama activa)	Referencia simbólica

Repositorio local vs. remoto

Repositorio Local

Copia completa del historial
Operaciones sin red (rápidas)
Working directory, staging area y .git/
Branches locales independientes
Commits, merges, diffs offline

Repositorio Remoto (origin)

Servidor compartido (GitHub, GitLab…)
Referenciado como origin (por convención)
Sincronización con push/pull/fetch
Remote tracking branches (origin/main)
Punto de integración del equipo

Comandos Git Esenciales

Configuración inicial

# Configuración de identidad (global)
git config --global user.name "Nombre Apellido"
git config --global user.email "correo@ejemplo.com"
git config --global core.editor "code --wait"
git config --list                  # Ver configuración actual
  

Tabla de comandos por categoría

Repositorio e historial

Comando	Descripción	Opciones destacadas
`git init`	Inicializa repositorio Git en el directorio actual	`--bare` (servidor sin working dir)
`git clone <url>`	Clona repositorio remoto en local	`--depth 1` (shallow), `-b <rama>`
`git status`	Muestra el estado del árbol de trabajo e índice	`-s` (formato corto)
`git log`	Muestra historial de commits	`--oneline --graph --all --decorate`
`git diff`	Diferencias entre working dir e índice	`--staged`, `HEAD`, `rama1..rama2`
`git show <hash>`	Muestra info y cambios de un commit	`--stat`
`git blame <file>`	Muestra quién modificó cada línea	`-L 10,20` (rango de líneas)

Staging y commits

Comando	Descripción	Opciones destacadas
`git add <archivo>`	Añade archivo al staging area	`.` (todo), `-p` (interactivo por hunks)
`git commit -m "msg"`	Crea un nuevo commit	`--amend` (modifica último commit), `-a`
`git reset <hash>`	Mueve HEAD al commit indicado	`--soft`, `--mixed` (defecto), `--hard`
`git revert <hash>`	Crea commit que deshace otro (seguro para compartir)	`--no-commit`
`git stash`	Guarda cambios sin confirmar temporalmente	`pop`, `list`, `drop`, `apply`
`git cherry-pick <hash>`	Aplica un commit concreto en la rama actual	`-n` (sin hacer commit)
`git tag <nombre>`	Crea una etiqueta (versión)	`-a` (anotada), `-d` (borrar)

Ramas

Comando	Descripción	Opciones destacadas
`git branch`	Lista ramas locales	`-a` (todas), `-d` (borrar), `-m` (renombrar)
`git checkout <rama>`	Cambia a una rama existente	`-b` (crea y cambia)
`git switch <rama>`	Cambia de rama (comando moderno, Git 2.23+)	`-c` (crea y cambia)
`git merge <rama>`	Integra una rama en la actual	`--no-ff`, `--squash`, `--abort`
`git rebase <rama>`	Reaplica commits sobre otra base	`-i` (interactivo), `--onto`

Repositorio remoto

Comando	Descripción	Opciones destacadas
`git remote add origin <url>`	Añade un repositorio remoto	`-v` (ver remotos), `remove`
`git fetch <remote>`	Descarga cambios del remoto sin integrarlos	`--all`, `--prune`
`git pull`	fetch + merge (o rebase con `--rebase`)	`--rebase`, `--ff-only`
`git push <remote> <rama>`	Sube commits locales al remoto	`-u` (tracking), `--force-with-lease`, `--tags`

Diferencia: merge vs. rebase

Aspecto	git merge	git rebase
Historial	Conserva el historial real (ramificado)	Reescribe el historial (lineal)
Commit extra	Crea un merge commit	No crea commit extra
Conflictos	Se resuelven una vez	Pueden repetirse commit a commit
Uso recomendado	Ramas de larga duración, integración final	Feature branches antes del merge (limpiar historial)
Regla de oro	Seguro en ramas compartidas	Nunca rebase de ramas públicas/compartidas
Resultado	Preserva cuándo y cómo se integró	Parece que el desarrollo fue siempre lineal

reset vs. revert

Comando	Modifica historial	Cuándo usarlo	Riesgo
`git reset --soft`	Sí (mueve HEAD)	Deshacer commits locales, mantener staged	Bajo (local)
`git reset --mixed`	Sí	Deshacer commits locales, mantener cambios	Bajo (local)
`git reset --hard`	Sí	Descartar todo hasta un commit. ¡Irreversible!	Alto
`git revert`	No (añade commit)	Deshacer en ramas compartidas/remotas	Ninguno

Ramas y Flujos de Trabajo (Branching Strategies)

Git Flow (Vincent Driessen, 2010)

Flujo estructurado con ramas de larga duración. Adecuado para proyectos con releases periódicas y programadas.

Rama	Duración	Propósito	Se fusiona en
`main` / `master`	Permanente	Código en producción. Solo commits de release y hotfix	—
`develop`	Permanente	Integración de features. Refleja el estado del próximo release	`main`
`feature/*`	Temporal	Desarrollo de nuevas funcionalidades	`develop`
`release/*`	Temporal	Preparación de release: bugfixes menores, version bump	`develop` y `main`
`hotfix/*`	Temporal	Correcciones urgentes sobre producción	`develop` y `main`

GitHub Flow

Flujo simplificado usado por GitHub. Adecuado para entrega continua (CD) y proyectos web con despliegues frecuentes.

Crear rama desde `main`

Nombre descriptivo: feature/login-oauth, fix/header-bug.

Hacer commits

Commits pequeños y frecuentes con mensajes descriptivos.

Abrir Pull Request (PR)

Solicitud de revisión del código. Inicia la discusión y la revisión por pares.

Revisión y CI

Los pipelines CI ejecutan pruebas automáticamente. Los revisores aprueban o piden cambios.

Merge a `main`

Una vez aprobado, se fusiona. main siempre está en estado desplegable.

Desplegar

El merge a main desencadena el despliegue automático a producción.

GitLab Flow

Extensión de GitHub Flow que añade ramas de entorno: main → pre-production → production. Permite promocionar el código entre entornos de forma controlada.

Trunk-Based Development (TBD)

Todos los desarrolladores integran sus cambios directamente en main (trunk) varias veces al día. Las ramas de features duran horas, no días. Requiere Feature Flags para código incompleto. Base de la integración continua real.

Flujo	Ramas principales	Complejidad	Ideal para
Git Flow	main, develop, feature, release, hotfix	Alta	Releases programadas, versionado semántico
GitHub Flow	main + feature branches	Baja	Despliegue continuo, SaaS
GitLab Flow	main + ramas de entorno	Media	Múltiples entornos (staging, prod)
Trunk-Based Dev	main (trunk)	Baja (proceso)	Equipos maduros, CI/CD real

Convenciones de commits: Conventional Commits

Formato estándar: <tipo>[ámbito opcional]: <descripción>
Permite generar CHANGELOGs automáticos y calcular versiones semánticas.

Tipo	Significado	Ejemplo
`feat`	Nueva funcionalidad	`feat(auth): add OAuth2 login`
`fix`	Corrección de bug	`fix(api): handle null response`
`docs`	Cambios en documentación	`docs: update README`
`style`	Formato, sin cambio funcional	`style: apply prettier`
`refactor`	Refactorización sin fix ni feat	`refactor(db): simplify query builder`
`test`	Añade o corrige tests	`test: add unit tests for parser`
`chore`	Mantenimiento, build, CI	`chore: upgrade dependencies`
`BREAKING CHANGE`	Cambio incompatible (sube major)	`feat!: remove deprecated API`

Plataformas de Alojamiento Git

Plataforma	Propietario	Tipo	CI/CD integrado	Precio base	Destacado
GitHub	Microsoft	SaaS / On-premise (GHE)	GitHub Actions	Gratis (plan Free)	Mayor comunidad OSS, Copilot, Marketplace
GitLab	GitLab Inc.	SaaS / Self-hosted	GitLab CI/CD (integrado)	Gratis (plan Free)	DevSecOps completo en una sola plataforma
Bitbucket	Atlassian	SaaS / Server	Bitbucket Pipelines	Gratis (≤5 usuarios)	Integración nativa con Jira y Confluence
Azure DevOps	Microsoft	SaaS / On-premise	Azure Pipelines	Gratis (limitado)	Ecosistema Microsoft, Boards, Artifacts
Gitea	Comunidad	Self-hosted	Gitea Actions	Gratuito (OSS)	Ligero, ideal para despliegue propio
Forgejo	Comunidad	Self-hosted	Sí	Gratuito (OSS)	Fork de Gitea, gobernanza comunitaria

Funcionalidades clave comunes

Funcionalidad	GitHub	GitLab	Bitbucket	Azure DevOps
Pull / Merge Requests	✔	✔	✔	✔
CI/CD nativo	✔	✔	✔	✔
Registry de contenedores	✔	✔	✗	✔
Gestión de proyectos / Issues	✔	✔	~	✔ (Boards)
Wiki / Docs	✔	✔	✔	✔
Self-hosted gratuito	✔ (GHE pago)	✔ (CE)	Pago (Server)	On-prem pago
Escaneo de seguridad (SAST)	✔ (limitado free)	✔ (Ultimate)	✗	✔ (con plugins)
Pages (hosting estático)	✔	✔	✗	✗

Integración y Entrega Continua (CI/CD)

CI (Continuous Integration): práctica de integrar cambios de código en un repositorio compartido frecuentemente (varias veces al día), verificando cada integración mediante una build automatizada y pruebas automáticas. Concepto popularizado por Martin Fowler y Kent Beck.

CD — Continuous Delivery: extensión de CI donde el software siempre está en un estado potencialmente entregable a producción. La decisión de desplegar es manual.

CD — Continuous Deployment: cada cambio que pasa las pruebas automáticas se despliega automáticamente a producción sin intervención humana.

Pipeline CI/CD típico

📝

Commit

→

🔨

Build

→

🧪

Unit Tests

→

🔗

Integration Tests

→

🔍

Code Analysis

→

📦

Package / Artifact

→

🚀

Deploy Staging

→

✅

Deploy Prod

Etapas del pipeline en detalle

Etapa	Descripción	Herramientas comunes	Falla si…
Source / Trigger	Evento que dispara el pipeline (push, PR, schedule)	Git, webhooks	—
Build	Compilación del código fuente	Maven, Gradle, npm, Make, Docker	Error de compilación
Unit Test	Pruebas de unidades aisladas	JUnit, Jest, pytest, NUnit	Test fallido
Code Quality	Análisis estático, cobertura, estilo	SonarQube, ESLint, Checkstyle	Umbral de calidad no superado
Security Scan	Análisis de vulnerabilidades (SAST/DAST/SCA)	Snyk, Trivy, OWASP ZAP, Bandit	Vulnerabilidad crítica detectada
Integration Test	Pruebas de integración entre componentes	Testcontainers, Postman/Newman	Test de integración fallido
Package / Artifact	Empaquetado del artefacto (JAR, Docker image, ZIP)	Docker, Helm, npm pack	Error de empaquetado
Publish	Publicación en registry o repositorio de artefactos	Docker Hub, Nexus, Artifactory, GHCR	Error de autenticación / red
Deploy Staging	Despliegue en entorno de pre-producción	Kubernetes, Ansible, Terraform	Fallo en el despliegue
E2E / Acceptance Test	Pruebas extremo a extremo en staging	Selenium, Cypress, Playwright	Flujo de usuario roto
Deploy Production	Despliegue en producción (manual o automático)	ArgoCD, Spinnaker, Flux	Gate de aprobación rechazado

Estrategias de despliegue

Estrategia	Descripción	Riesgo	Rollback
Recreate	Para la versión antigua, despliega la nueva	Alto (downtime)	Lento
Rolling Update	Reemplaza instancias gradualmente	Medio	Medio
Blue-Green	Dos entornos idénticos; se redirige el tráfico de golpe	Bajo	Inmediato
Canary Release	Pequeño % de usuarios recibe la nueva versión primero	Muy bajo	Inmediato
A/B Testing	Grupos de usuarios reciben versiones distintas	Bajo	Configurable
Feature Flags	La nueva funcionalidad se activa/desactiva por configuración	Muy bajo	Instantáneo
Shadow Deploy	El tráfico real se duplica a la nueva versión (sin afectar usuarios)	Ninguno	N/A

GitHub Actions

Plataforma de CI/CD integrada en GitHub, basada en workflows definidos en archivos YAML dentro del directorio .github/workflows/. Lanzada en versión GA en noviembre de 2019.

Componentes de GitHub Actions

Componente	Descripción
Workflow	Proceso automatizado configurable. Definido en YAML. Se dispara por eventos.
Event	Actividad que desencadena el workflow: `push`, `pull_request`, `schedule`, `workflow_dispatch`, etc.
Job	Conjunto de steps que se ejecutan en el mismo runner. Los jobs se ejecutan en paralelo por defecto.
Step	Tarea individual dentro de un job. Puede ser un comando shell o una Action.
Action	Aplicación reutilizable que realiza una tarea compleja. Publicadas en GitHub Marketplace.
Runner	Servidor que ejecuta los jobs. GitHub-hosted (Ubuntu, Windows, macOS) o self-hosted.
Secrets	Variables cifradas para tokens, contraseñas y claves API.
Environment	Conjunto de reglas de protección y secretos asociados a un entorno (staging, production).
Artifact	Archivos generados durante el workflow que se pueden descargar o compartir entre jobs.
Cache	Reutilización de dependencias entre ejecuciones para reducir tiempo de build.

Ejemplo de workflow CI

# .github/workflows/ci.yml
name: CI Pipeline

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm test -- --coverage

      - name: Build
        run: npm run build

      - name: Upload artifact
        uses: actions/upload-artifact@v4
        with:
          name: dist
          path: ./dist
  

Runners GitHub-hosted

Runner	OS	CPU	RAM	Almacenamiento
`ubuntu-latest`	Ubuntu 22.04	2 vCPU	7 GB	14 GB SSD
`windows-latest`	Windows Server 2022	2 vCPU	7 GB	14 GB SSD
`macos-latest`	macOS 13 Ventura	3 vCPU	14 GB	14 GB SSD

GitLab CI/CD

CI/CD completamente integrado en GitLab, configurado mediante el archivo .gitlab-ci.yml en la raíz del repositorio. Uno de los sistemas CI/CD más completos del mercado, parte de la plataforma DevSecOps de GitLab.

Conceptos clave de GitLab CI/CD

Concepto	Descripción
Pipeline	Proceso completo de CI/CD. Formado por stages y jobs.
Stage	Fase del pipeline (build, test, deploy). Los jobs del mismo stage se ejecutan en paralelo.
Job	Unidad de trabajo ejecutada por un Runner. Define el script y condiciones de ejecución.
Runner	Agente que ejecuta los jobs. Tipos: shared, group, specific. Puede ser Docker, Shell, Kubernetes executor.
Artifact	Archivos generados por un job y accesibles en jobs posteriores o descargables.
Cache	Archivos reutilizados entre pipelines (p.ej. `node_modules`).
Environments	Representación de un entorno (staging, production) con historial de despliegues.
Variables CI/CD	Variables predefinidas (`CI_COMMIT_SHA`, `CI_PROJECT_NAME`…) y personalizadas.
Rules / only / except	Condiciones para controlar cuándo se ejecuta un job.
include	Reutilización de configuraciones CI desde ficheros externos o plantillas.
Trigger	Disparar pipelines de otros proyectos (pipelines multi-proyecto).
DAG (needs:)	Grafo acíclico dirigido: un job puede iniciar cuando sus dependencias directas terminan, sin esperar todo el stage.

Ejemplo de .gitlab-ci.yml

stages:
  - build
  - test
  - deploy

variables:
  DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA

build-image:
  stage: build
  image: docker:24
  script:
    - docker build -t $DOCKER_IMAGE .
    - docker push $DOCKER_IMAGE

unit-tests:
  stage: test
  image: python:3.11
  script:
    - pip install -r requirements.txt
    - pytest --junitxml=report.xml
  artifacts:
    reports:
      junit: report.xml

deploy-staging:
  stage: deploy
  environment: staging
  rules:
    - if: $CI_COMMIT_BRANCH == "develop"
  script:
    - kubectl set image deployment/app app=$DOCKER_IMAGE
  

Tipos de pipelines en GitLab

Tipo	Descripción
Branch pipeline	Se ejecuta en cada push a una rama
Merge Request pipeline	Se ejecuta en el contexto del MR, sobre la rama fusionada
Tag pipeline	Disparado al crear un tag (release)
Scheduled pipeline	Ejecución periódica (cron)
Multi-project pipeline	Un pipeline dispara pipelines en otros proyectos
Parent-child pipeline	Pipeline que genera subpipelines dinámicamente

Jenkins

Servidor de automatización de código abierto basado en Java. El más antiguo y extendido de los sistemas CI/CD. Creado originalmente como Hudson en 2004 (Sun Microsystems); renombrado a Jenkins en 2011 tras el fork comunitario.

Conceptos fundamentales de Jenkins

Concepto	Descripción
Job / Project	Unidad de trabajo: Freestyle project, Pipeline, Multibranch Pipeline, etc.
Build	Ejecución de un job. Tiene número, estado (success, failure, unstable) y log.
Pipeline	Definición de CI/CD como código mediante `Jenkinsfile` (DSL Groovy).
Jenkinsfile	Archivo en el repositorio que define el pipeline. Puede ser Declarativo o Scripted.
Node / Agent	Máquina donde se ejecutan los builds. El master coordina; los agents ejecutan.
Executor	Slot de ejecución en un node. Un node puede tener múltiples executors.
Workspace	Directorio temporal en el agent donde se ejecuta el build.
Plugin	Jenkins tiene más de 1800 plugins. Extienden casi cualquier funcionalidad.
Trigger	SCM polling, webhook, cron, upstream job, manual.
Shared Library	Código Groovy reutilizable entre múltiples Jenkinsfiles.

Ejemplo de Jenkinsfile declarativo

pipeline {
  agent { docker { image 'maven:3.9-openjdk-17' } }

  environment {
    MAVEN_OPTS = '-Xmx512m'
  }

  stages {
    stage('Checkout') {
      steps { checkout scm }
    }
    stage('Build') {
      steps { sh 'mvn clean package -DskipTests' }
    }
    stage('Test') {
      steps { sh 'mvn test' }
      post {
        always { junit 'target/surefire-reports/*.xml' }
      }
    }
    stage('Deploy') {
      when { branch 'main' }
      steps {
        withCredentials([usernamePassword(...)]) {
          sh './deploy.sh'
        }
      }
    }
  }
  post {
    failure { mail to: 'team@ejemplo.com', subject: 'Build failed' }
  }
}
  

Jenkins vs Jenkinsfile declarativo vs scripted

Aspecto	Pipeline Declarativo	Pipeline Scripted
Sintaxis	Estructura fija con bloques predefinidos	Groovy completo, máxima flexibilidad
Curva de aprendizaje	Baja	Alta (requiere conocer Groovy)
Validación previa	Sí (linting en interfaz)	No
Manejo de errores	`post` section	try/catch/finally
Recomendado	Sí (uso general)	Solo cuando se necesita lógica compleja

Comparativa de Plataformas CI/CD

Característica	GitHub Actions	GitLab CI/CD	Jenkins	Azure Pipelines	CircleCI
Tipo	SaaS (integrado)	SaaS / Self-hosted	Self-hosted	SaaS / On-prem	SaaS
Config. como código	✔ YAML	✔ YAML	✔ Groovy DSL	✔ YAML	✔ YAML
Integración con Git	GitHub nativo	GitLab nativo	Plugin (cualquier SCM)	Azure Repos / GitHub	GitHub, GitLab, Bitbucket
Runners / Agentes	GitHub-hosted + self-hosted	Shared + self-hosted	Master + agents	Microsoft-hosted + self-hosted	Cloud + self-hosted
Paralelización	Jobs en paralelo	Jobs en paralelo + DAG	Parallel steps	Jobs en paralelo	Parallelism nativo
Marketplace / Plugins	GitHub Marketplace (Actions)	Templates / CI Components	>1800 plugins	Azure DevOps Extensions	Orbs
Docker nativo	✔	✔ (Docker executor)	✔ (plugin)	✔	✔
Kubernetes nativo	✔ (actions)	✔ (K8s executor)	✔ (plugin)	✔ (AKS)	✔ (orb)
Coste (open source)	Gratis (2000 min/mes)	Gratis (400 min/mes)	Gratuito (infra propia)	Gratis (1800 min/mes)	Gratis (6000 créditos/mes)
Curva de aprendizaje	Baja	Media	Alta	Media	Baja-Media
Mantenimiento	Ninguno (SaaS)	Bajo (SaaS) / Medio (self)	Alto (propio)	Ninguno (SaaS)	Ninguno (SaaS)
Mejor para	Proyectos GitHub, OSS	DevSecOps completo	Empresas con infra propia	Ecosistema Microsoft	Proyectos con alta paralelización

Otras herramientas de CI/CD relevantes

Herramienta	Tipo	Destacado
Travis CI	SaaS	Pionero del CI basado en YAML para GitHub OSS
Bitbucket Pipelines	SaaS (Atlassian)	Integración nativa con Jira; config. en `bitbucket-pipelines.yml`
TeamCity	SaaS / On-prem (JetBrains)	UI muy completa; integración IDE; configuración Kotlin DSL
Drone CI	SaaS / Self-hosted	100% container-native; pipelines como contenedores Docker
Tekton	Kubernetes-native	Primitivas CI/CD para Kubernetes (CRDs); base de OpenShift Pipelines
ArgoCD	GitOps (Kubernetes)	CD declarativo; sincroniza cluster K8s con estado en Git
Flux CD	GitOps (Kubernetes)	Operador GitOps para Kubernetes; parte de CNCF
Spinnaker	Self-hosted (Netflix)	CD multi-cloud; pipelines complejos con aprobaciones manuales

DevOps y el Pipeline Completo

DevOps es una cultura, filosofía y conjunto de prácticas que combinan el desarrollo de software (Dev) y las operaciones de TI (Ops) con el objetivo de acortar el ciclo de vida del desarrollo y entregar software con alta calidad de forma continua.

El bucle infinito de DevOps

Fase	Actividades	Herramientas típicas
Plan	Gestión de requisitos, backlog, roadmap, sprints	Jira, Azure Boards, GitHub Issues, Linear
Code	Desarrollo, revisión de código, pair programming	VS Code, IntelliJ, Git, GitHub/GitLab
Build	Compilación, empaquetado, análisis estático	Maven, Gradle, npm, Docker, SonarQube
Test	Pruebas unitarias, integración, e2e, rendimiento	JUnit, pytest, Cypress, k6, JMeter
Release	Versionado, changelogs, aprobaciones	Semantic-release, GitLab Releases, GitHub Releases
Deploy	Despliegue en entornos, estrategias de release	ArgoCD, Spinnaker, Helm, Terraform, Ansible
Operate	Gestión de infraestructura, escalado, IaC	Kubernetes, Terraform, AWS/Azure/GCP, Ansible
Monitor	Observabilidad: logs, métricas, trazas, alertas	Prometheus, Grafana, ELK Stack, Datadog, Jaeger

Métricas DORA (DevOps Research & Assessment)

Las 4 métricas clave para medir el rendimiento de un equipo DevOps:

Métrica	Descripción	Elite performers
Deployment Frequency	¿Con qué frecuencia se despliega a producción?	Múltiples veces al día
Lead Time for Changes	Tiempo desde commit hasta producción	Menos de 1 hora
Change Failure Rate	% de despliegues que causan incidentes en prod	0–5 %
Time to Restore Service	Tiempo de recuperación ante un fallo en prod	Menos de 1 hora

Infrastructure as Code (IaC)

Herramienta	Tipo	Lenguaje	Uso principal
Terraform	Declarativo	HCL	Provisioning multi-cloud (AWS, Azure, GCP)
Ansible	Imperativo (playbooks)	YAML	Configuración de servidores, sin agente
Puppet	Declarativo	DSL propio	Gestión de configuración a escala
Chef	Imperativo	Ruby DSL	Gestión de configuración, entornos complejos
Pulumi	Declarativo / Imperativo	Python, JS, Go…	IaC con lenguajes de programación reales
Helm	Declarativo	YAML + Go templates	Gestión de aplicaciones en Kubernetes

Seguridad en CI/CD: DevSecOps

DevSecOps: integración de la seguridad (Shift Left) en todas las fases del pipeline CI/CD, en lugar de tratarla como una fase final separada.

Tipos de análisis de seguridad en el pipeline

Tipo	Sigla	Descripción	Herramientas
Static Application Security Testing	SAST	Analiza el código fuente sin ejecutarlo	SonarQube, Semgrep, Bandit, SpotBugs
Dynamic Application Security Testing	DAST	Prueba la aplicación en ejecución buscando vulnerabilidades	OWASP ZAP, Burp Suite, Nikto
Software Composition Analysis	SCA	Analiza dependencias y librerías externas en busca de CVEs	Snyk, OWASP Dependency-Check, Trivy
Container Image Scanning	—	Escanea imágenes Docker en busca de vulnerabilidades	Trivy, Clair, Grype, Docker Scout
Infrastructure as Code Scanning	IaC Scan	Analiza ficheros Terraform, Helm, K8s manifests	Checkov, tfsec, Terrascan
Secret Detection	—	Detecta credenciales, tokens y claves expuestos en el código	GitLeaks, TruffleHog, detect-secrets

Buenas prácticas de seguridad en CI/CD

Principio de mínimo privilegio: los runners y pipelines solo tienen los permisos estrictamente necesarios.
Gestión de secretos: nunca almacenar credenciales en el código. Usar Vault, AWS Secrets Manager o las variables de entorno cifradas de la plataforma CI/CD.
Firma de artefactos: firmar imágenes Docker y paquetes para garantizar su integridad (Cosign, Sigstore).
SBOM (Software Bill of Materials): inventario de todos los componentes de software incluidos en el artefacto (estándar SPDX o CycloneDX).
Revisión obligatoria de código (Code Review): al menos un aprobador antes de fusionar a ramas protegidas.
Branch protection rules: proteger main/develop contra pushes directos, requerir PR y CI verde.
Auditoría de accesos: registrar quién ejecuta qué pipeline y cuándo.

⚠️ Supply Chain Security: los ataques a la cadena de suministro de software (como el ataque a SolarWinds o el incident de xz-utils) hacen crítico verificar la integridad de las dependencias y acciones de terceros usadas en los pipelines CI/CD.