Qué es GitLab y sus ediciones

El problema que resuelve

En cualquier proyecto de software coexisten varias herramientas distintas: un repositorio Git, un sistema de tickets/issues, una pipeline de integración continua, un registro de contenedores Docker, una herramienta de revisión de código… En la práctica, los equipos combinan GitHub + Jenkins + Jira + Docker Hub + Confluence, y pasan tiempo considerable manteniendo las integraciones entre ellas y sincronizando contexto.

GitLab apuesta por una sola aplicación que cubra todo ese ciclo sin integraciones externas. La idea es que el código, los tests, los despliegues, la planificación y la seguridad compartan el mismo modelo de datos, la misma interfaz y las mismas credenciales.

“Single application for the whole DevOps lifecycle” — lema oficial de GitLab.

El resultado práctico: abres una tarea en Issues, creas una rama desde ahí, haces tu Merge Request, la pipeline se lanza automáticamente, y el deploy queda trazado en el mismo hilo. Sin cambiar de pestaña ni de herramienta.


Panorama del ciclo DevOps que cubre GitLab

GitLab divide su funcionalidad en etapas del ciclo DevOps. Esto no es marketing: cada etapa corresponde a una sección real de la interfaz y a una categoría de features:

EtapaQué hace GitLab aquíEquivalente externo típico
PlanIssues, tableros Kanban, milestones, roadmapsJira, Linear, Trello
CreateRepositorios Git, revisión de código (Merge Requests)GitHub, Bitbucket
VerifyCI/CD pipelines (.gitlab-ci.yml), test reportsJenkins, CircleCI, GitHub Actions
PackageContainer Registry, Package Registry (npm, PyPI…)Docker Hub, Artifactory
ReleaseDeploy, feature flags, release notesSpinnaker, LaunchDarkly
ConfigureKubernetes integration, Helm chartsArgoCD, Helm
MonitorMétricas de aplicación, alertas, trazasGrafana, Datadog
SecureSAST, DAST, dependency scanning, secrets detectionSnyk, SonarQube

No tienes que usar todas las etapas; puedes adoptarlas incrementalmente. Muchos equipos empiezan solo con repositorios + CI y añaden el resto cuando escalan.


GitLab.com (SaaS) vs Self-Managed (Autoalojado)

Esta es la diferencia más importante entre GitLab y GitHub para el mercado profesional: GitLab puedes instalarlo tú mismo en tus servidores, y eso es algo que muchas empresas exigen por razones regulatorias o de seguridad.

Conceptos clave

  • SaaS (Software as a Service): GitLab gestiona la infraestructura. Tú solo creas cuenta y usas.
  • Self-managed (autoalojado): instalas GitLab en tu propia máquina, VM o clúster. Tú gestionas actualizaciones, backups, escalado.
DimensiónGitLab.com (SaaS)Self-Managed
InstalaciónNinguna — cuenta gratuitaRequiere servidor + instalación
ActualizacionesAutomáticas, gestionadas por GitLabManuales, responsabilidad tuya
Control de datosLos datos están en servidores de GitLab (EE.UU.)Los datos están en tu infraestructura
Cumplimiento normativoDepende de los acuerdos de GitLabControl total (GDPR, ISO 27001, etc.)
EscaladoAutomáticoDebes dimensionar y mantener
Precio baseFree tier generoso; pago por usuario/mesRequiere infraestructura propia (coste hardware/cloud)
Runners CI/CDRunners compartidos incluidos (minutos limitados en Free)Tú configuras tus propios Runners
Ideal paraProyectos personales, startups, equipos pequeñosEmpresas con datos sensibles, regulación estricta, o escala grande

Analogía de hardware: SaaS es como comprar una PCB ya montada; self-managed es fabricar la placa tú mismo. Tienes más control pero más responsabilidad.

Cuándo elegir cada uno

GitLab.com si:

  • Empiezas a aprender o prototipas.
  • Tu equipo es pequeño y no tienes DevOps dedicado.
  • No hay restricciones regulatorias sobre dónde residen los datos.

Self-managed si:

  • Trabajas con datos confidenciales (salud, finanzas, defensa).
  • La empresa requiere auditoría completa de la cadena de herramientas.
  • Tienes infraestructura propia y quieres integrar GitLab en ella.
  • Necesitas customizar la instancia (LDAP propio, autenticación SSO corporativo, etc.).

Ediciones: CE vs EE

GitLab tiene un modelo open-core: el núcleo es software libre, y las features avanzadas son de pago.

Community Edition (CE)

  • Licencia: MIT — puedes usar, modificar y redistribuir libremente.
  • Incluye: repositorios Git, Merge Requests, Issues básicos, CI/CD completo, Container Registry, Pages.
  • Es muy capaz. Para la mayoría de proyectos personales y muchas empresas medianas, CE es suficiente.
  • Código fuente en gitlab.com/gitlab-org/gitlab-foss.

Enterprise Edition (EE)

  • Licencia propietaria, con tiers Premium y Ultimate.
  • Incluye todo lo de CE más features avanzadas según tier.
  • El código también es público (puedes leerlo), pero no puedes redistribuirlo sin licencia.
FeatureCE (Free)EE PremiumEE Ultimate
Repositorios Git ilimitados[OK][OK][OK]
CI/CD pipelines[OK][OK][OK]
Container Registry[OK][OK][OK]
GitLab Pages[OK][OK][OK]
Issues y tableros básicos[OK][OK][OK]
Merge Requests con aprobacionesBásicoAvanzado (reglas por rama)[OK]
Protected branches por rolBásicoPor grupo[OK]
Subgrupos anidados1 nivelIlimitados[OK]
Auditoría de eventosLimitadaCompleta[OK]
Epics y roadmaps (planificación)[NO][OK][OK]
SAST / Dependency ScanningBásico[OK][OK]
DAST, Fuzzing[NO]Limitado[OK]
Compliance management[NO][NO][OK]
Value stream analytics[NO][OK][OK]

Los precios (2024 aprox.) son ~99/usuario/mes para Ultimate en SaaS. Self-managed tiene precios similares por usuario.

La trampa del “free tier en GitLab.com”

GitLab.com Free usa la EE (código Enterprise) pero con la mayoría de features avanzadas desactivadas por licencia. No es lo mismo que instalar CE self-managed. En la práctica, GitLab.com Free es funcional para proyectos personales y académicos, pero en equipos comerciales pronto chocas con los límites de aprobaciones o de seguridad.


GitLab vs GitHub: diferencias estratégicas

DimensiónGitLabGitHub
Self-hostingPrimera clase, muy completoGitHub Enterprise (caro, complejo)
CI/CD nativo.gitlab-ci.yml integrado desde 2012GitHub Actions (llegó en 2018)
Open source del núcleoCE bajo MITNo (propietario de Microsoft)
Modelo de negocioOpen-core + SaaSSaaS + Enterprise (Microsoft)
EcosistemaMás fuerte en DevOps enterpriseMayor comunidad OSS
Interfaz de planificaciónMás completa (epics, roadmaps)Básica en Free

No hay un ganador universal. GitHub domina en open source y comunidad; GitLab domina en entornos enterprise con self-hosting y DevOps integrado.


Errores comunes al empezar

  • Confundir GitLab.com con “GitLab”: GitLab es el software, GitLab.com es una instancia SaaS. Cuando una empresa dice “tenemos GitLab”, suele referirse a una instancia self-managed propia.
  • Pensar que CE es una versión recortada inutilizable: CE tiene CI/CD completo, Runners, Registry, etc. Solo faltan features enterprise de aprobaciones complejas, seguridad avanzada y planificación estratégica.
  • Instalar EE pensando que es gratis: EE instalado sin licencia funciona como CE; no activa features de pago automáticamente.
  • Mezclar conceptos SaaS/self-managed: los minutos de CI, los Runners compartidos y los límites de almacenamiento son cosas de GitLab.com; en self-managed tú pones los Runners y el almacenamiento.

Aplícalo a tus proyectos

app web (FastAPI + React + Docker):

  • Puedes usar GitLab.com Free y ya tienes CI/CD real: linting, tests, build de imágenes Docker, todo en .gitlab-ci.yml.
  • Si en el futuro la app maneja datos de salud de usuarios reales, self-managed en un VPS propio daría control total sobre dónde residen los datos — relevante dado tu contexto EDS/POTS y privacidad médica.

proyecto embebido (PlatformIO / firmware):

  • GitLab CI puede correr builds de firmware (PlatformIO CLI en Docker) y archivar los .bin como artefactos descargables — sin Jenkins ni nada externo.

Bóveda Obsidian:

  • Un repositorio GitLab con CI puede hacer lint de Markdown, verificar links rotos, o publicar un subset como GitLab Pages si algún día quieres una versión web de tus notas.

Conexiones