GitLab: fundamentos, funcionalidades y CI/CD

¿Qué es GitLab?

GitLab — es una plataforma DevOps completa de código abierto bajo licencia MIT. A diferencia de GitHub, que combina varios servicios a través de integraciones, GitLab proporciona una herramienta única para todo el ciclo de vida del desarrollo: desde la gestión del código y la revisión de código hasta CI/CD, monitoreo, seguridad e implementación. La plataforma no requiere servicios de terceros para la mayoría de las tareas de DevOps.

La historia de GitLab comenzó en 2011 como un proyecto interno de desarrolladores ucranianos. La primera versión pública se lanzó en septiembre de 2011, y en 2015 GitLab se convirtió en el primer proyecto en GitLab.com, lanzando el alojamiento en la nube. En 2017, GitLab realizó un proceso de migración doloroso pero instructivo: trasladó toda su infraestructura de Azure a Google Cloud, que se llevó a cabo en vivo y se documentó en una serie de publicaciones.

La arquitectura de GitLab consta de tres componentes principales: GitLab Rails (aplicación web en Ruby on Rails), GitLab Shell (manejo de operaciones Git a través de SSH) y Gitaly (servidor gRPC para acceder a datos Git). El CI/CD se gestiona mediante GitLab Runner, una aplicación separada que se instala en servidores de compilación y ejecuta trabajos en entornos aislados (Docker, Kubernetes, VirtualBox).

GitLab CI/CD: pipelines y runners

GitLab CI/CD — es un sistema integrado de integración y entrega continua que constituye una ventaja clave de la plataforma. A diferencia de GitHub Actions, GitLab CI/CD se integró en la arquitectura desde el principio y no requiere configuración adicional: cada proyecto obtiene automáticamente CI/CD al añadir el archivo .gitlab-ci.yml en la raíz del repositorio.

Un pipeline consta de etapas que se ejecutan secuencial o paralelamente: build → test → deploy. Cada etapa contiene uno o varios trabajos que se ejecutan en runners. Si un trabajo en una etapa falla, toda la etapa se marca como fallida y las etapas posteriores no se ejecutan por defecto. A continuación se muestra un ejemplo de pipeline para un proyecto móvil:

# .gitlab-ci.yml
stages:
  - build
  - test
  - deploy

build-android:
  stage: build
  image: openjdk:17-jdk
  script:
    - ./gradlew assembleDebug
  artifacts:
    paths:
      - app/build/outputs/

unit-tests:
  stage: test
  script:
    - ./gradlew testDebugUnitTest

deploy-firebase:
  stage: deploy
  script:
    - firebase appdistribution:distribute app.apk

GitLab Runner admite varios ejecutores: Docker (recomendado), Kubernetes, SSH, VirtualBox y Parallels. La opción más popular es el ejecutor Docker, que ejecuta cada trabajo en un contenedor separado. Un runner puede registrarse como específico para un proyecto o como compartido para todo un grupo. GitLab.com proporciona runners compartidos gratuitos con un límite de 2000 minutos al mes.

Funcionalidades avanzadas de CI/CD

GitLab CI/CD admite activación manual (when: manual), activación retardada (when: delayed), ejecución en paralelo (parallel: 5), matrices, pipelines dinámicos (child pipelines) y pipelines multinivel (parent-child). Esto permite construir escenarios complejos: por ejemplo, generar dinámicamente un pipeline para cada módulo en un monorepositorio o ejecutar compilaciones paralelas para diferentes arquitecturas de Android (arm64, x86_64).

GitLab vs GitHub: diferencias clave

GitLab y GitHub — son los dos principales competidores en el mercado de plataformas Git, pero su filosofía y arquitectura difieren fundamentalmente. GitHub se centra en la comunidad abierta, un ecosistema de integraciones y funciones sociales (forks, estrellas). GitLab se enfoca en un ciclo DevOps integral y proporciona todas las herramientas listas para usar: desde la planificación hasta el monitoreo.

La principal diferencia arquitectónica: GitLab — es una aplicación monolítica única que los desarrolladores instalan completa. Todas las funciones (CI/CD, Container Registry, Security Scanning, Pages) están integradas y funcionan inmediatamente después de la instalación. GitHub es una plataforma con API donde la mayoría de las funciones se implementan mediante la integración con servicios de terceros: Travis CI, CircleCI, Jenkins, SonarQube. La siguiente tabla compara las características clave:

La elección entre GitLab y GitHub depende de las necesidades del equipo. Si la prioridad es una implementación rápida con configuración cero y una comunidad abierta, elige GitHub. Si necesitas control total de la infraestructura, alojamiento autogestionado y seguridad integrada, GitLab es preferible. Según una encuesta de Stack Overflow (2024), el 90% de los desarrolladores usa GitHub, el 33% usa GitLab (a menudo ambas plataformas simultáneamente).

Self-Managed GitLab: instalación en tu propio servidor

Self-Managed GitLab (anteriormente On-Premises) permite instalar la plataforma en tu propio servidor y tener control total sobre los datos, la infraestructura y el tiempo de actividad. Esto es especialmente importante para organizaciones con requisitos de cumplimiento normativo: sector financiero, instituciones gubernamentales, organizaciones médicas donde los datos no pueden almacenarse en servidores de terceros.

La instalación de GitLab es compatible con Ubuntu, Debian, CentOS y mediante Docker. El paquete oficial Omnibus incluye todos los componentes: servidor web (NGINX), base de datos (PostgreSQL), caché (Redis), gestor Git (Gitaly) y procesos en segundo plano. Requisitos mínimos: 4 GB de RAM y 2 CPU para equipos de hasta 100 personas. Para instalaciones grandes con alta carga, se recomienda separar los componentes en servidores distintos.

# Instalando GitLab CE en Ubuntu mediante Omnibus
curl -LO https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh
sudo bash script.deb.sh

# Instalando el paquete
sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ce

# Viendo el estado
sudo gitlab-ctl status
sudo gitlab-ctl tail

Self-Managed GitLab no tiene límites de minutos de CI/CD: todos los runners pertenecen a la organización y su potencia está limitada solo por tu propio hardware. También están disponibles la Geo-replicación para regiones, registros de auditoría, bloqueo por IP e integración con proveedores LDAP/SAML corporativos. GitLab publica actualizaciones cada mes (el día 22) con nuevas funciones y correcciones de seguridad.

Herramientas de seguridad integradas de GitLab

La seguridad en GitLab está integrada a nivel de plataforma e incluye varios escáneres que funcionan en cada etapa del pipeline. SAST (Static Application Security Testing) analiza el código fuente en busca de vulnerabilidades sin ejecutar la aplicación, compatible con más de 15 lenguajes, incluidos Java, Kotlin, Swift, Python y JavaScript. DAST (Dynamic Application Security Testing) prueba aplicaciones web en ejecución para encontrar vulnerabilidades desde dentro.

Herramientas adicionales: Container Scanning verifica imágenes Docker en busca de vulnerabilidades en las capas base; Dependency Scanning analiza las dependencias del proyecto y advierte sobre CVE conocidas; Secret Detection encuentra claves API, contraseñas y tokens comprometidos accidentalmente; Fuzz Testing realiza pruebas automatizadas con datos malformados para encontrar errores no evidentes. Todos los resultados de escaneo se muestran en un Security Dashboard unificado.

GitLab también proporciona Compliance: herramientas para cumplir con los requisitos regulatorios. El Compliance Dashboard muestra el estado de cumplimiento de todos los proyectos, Audit Events registra cada acción del administrador y desarrollador, y Compliance Frameworks permite aplicar políticas de configuración de forma obligatoria para grupos específicos de proyectos. Esto convierte a GitLab en una opción popular en entornos empresariales con estrictos requisitos de seguridad.

Container Registry y Dependency Proxy

GitLab Container Registry — es un registro Docker integrado con CI/CD. Tras compilar una imagen Docker en un pipeline, se puede publicar inmediatamente en el Registry utilizando las variables de entorno CI_REGISTRY y CI_REGISTRY_USER. El Registry admite caché pull-through, etiquetado, políticas de limpieza y escaneo de vulnerabilidades directamente en el registro.

Dependency Proxy — es un mecanismo de caché para contenedores e imágenes de registros externos (Docker Hub, Quay, GCR). Cuando un pipeline solicita una imagen como ubuntu:latest, GitLab primero verifica su caché: si la imagen ya está descargada, no se vuelve a descargar. Esto reduce la carga en los registros externos, acelera los pipelines y protege contra los límites de tasa de Docker Hub.

Para desarrolladores móviles, GitLab proporciona GitLab Pages para alojar documentación e informes de pruebas. Después de ejecutar pruebas, los artefactos (informes HTML, capturas de pantalla, registros) se pueden publicar como Pages y compartir un enlace con el equipo de QA. Esto es más conveniente que subir informes a almacenamiento en la nube, ya que todo reside dentro del mismo proyecto de GitLab.

API de GitLab y Webhooks

La API de GitLab (REST y GraphQL) proporciona acceso a todos los recursos de la plataforma: proyectos, usuarios, pipelines, Merge Requests, registro. La API se utiliza para automatización: crear un proyecto a partir de una plantilla, asignar un revisor, obtener el estado del pipeline. Webhooks permiten enviar notificaciones HTTP a sistemas externos ante eventos: push, merge, creación de Issue. Los Webhooks se integran con Mattermost, Slack, Telegram y sistemas de monitoreo internos.

GitLab Pages para documentación móvil

GitLab Pages publica automáticamente sitios web estáticos desde un repositorio. Para proyectos móviles, Pages es útil para alojar documentación de API, informes de cobertura de pruebas y resultados de análisis lint. La publicación ocurre automáticamente después de un pipeline exitoso: basta con añadir un paso de deploy con publicación en Pages. El resultado está disponible en https://namespace.gitlab.io/project-name.