- Presenta la experiencia de usar GitLab durante mucho tiempo, centrada en la gestión de proyectos personales y la integración de CI/CD
- Al principio, su principal ventaja frente a GitHub era ofrecer repositorios privados gratuitos, y después el flujo de trabajo ya quedó completamente establecido
- La función que más usa es Container Registry, que permite guardar imágenes sin tener que gestionar una cuenta o tokens separados de Docker Hub
- Entre los principales puntos fuertes menciona los pipelines basados en archivos de configuración de GitLab CI, los runners compartidos gratuitos y la abundante documentación
- Sin embargo, señala como desventajas la lentitud de la interfaz web y el exceso de funciones, y concluye que lo más eficiente es usar GitHub y GitLab en paralelo según el propósito
Contexto de uso de GitLab
- Empezó a usar GitLab cuando GitHub cobraba por los repositorios privados y GitLab ofrecía repositorios privados gratuitos
- Eso le permitía gestionar varios proyectos experimentales sin hacerlos públicos
- Después GitHub adoptó una política gratuita, pero para entonces ya tenía montados en GitLab los pipelines de CI, imágenes de Docker y scripts de despliegue, así que dejó de haber necesidad de migrar
Función de Docker Registry
- Todos los proyectos de GitLab incluyen por defecto Container Registry
- El flujo es simple: construir imágenes localmente o en CI, hacer push y luego hacer pull donde sea necesario
- No hace falta gestionar una cuenta o tokens separados de Docker Hub, y tampoco hay que preocuparse por límites de pull
- Para proyectos personales, las funciones son más que suficientes, y el límite de 10 GB en la práctica no representa un problema
- Limpiar etiquetas antiguas y compartir capas ayuda a mantener un uso eficiente del espacio
Entorno de CI/CD
- GitLab CI implementó desde muy temprano el concepto de “CI basada en archivos de configuración”
- Basta con agregar el archivo
.gitlab-ci.yml para que el pipeline se ejecute automáticamente
- La configuración queda versionada, por lo que es posible rastrear el estado de pipelines anteriores
- El pipeline básico se compone de construcción de imagen, push y despliegue opcional
- La etapa de despliegue puede controlarse con un disparador manual
- Los runners compartidos son gratuitos, pero lentos; si hace falta, también es fácil instalar un runner propio en un VPS
- La documentación de CI/CD es muy amplia y, una vez aprendidos los patrones, es posible gestionarlo de forma eficiente reutilizando configuraciones existentes mediante copia
Inconvenientes
- La velocidad de la interfaz web es lenta y hay tiempos de espera al cambiar entre merge requests, pipelines y logs
- Parece haber mejorado algo recientemente, pero sigue siendo más lenta que GitHub
- También existe el problema del exceso de funciones
- Tiene muchas capacidades, como seguimiento de issues, wiki, package registry y security scanning, pero en la práctica solo se usa alrededor del 10 %
- Aun así, existe la ventaja potencial de poder aprovechar funciones ya integradas cuando se necesiten
Costos y flujo de trabajo
- Mantiene alrededor de 12 proyectos personales de forma gratuita, incluyendo tanto proyectos activos como experimentos ya detenidos
- GitLab se usa como espacio de trabajo privado y GitHub como espacio para compartir proyectos públicos
- GitHub es adecuado para colaboración y visibilidad, mientras que GitLab encaja mejor para experimentación y gestión de automatización
- Esta estructura de usar ambas plataformas en paralelo funciona como una forma de mantener el equilibrio y la eficiencia del flujo de trabajo
3 comentarios
Dicen que GitLab tiene un buen CI/CD.
Pero en mi caso, por las limitaciones de la cuenta gratuita, aunque tuviera soporte para coreano igual termino inclinándome por GitHub.
Forgejo y su base, Gitea, me dan una sensación de imitación de GitHub, así que tampoco me llaman la atención.
Nosotros usamos Gitea, y la adoptamos porque, por esa imagen de imitación, la curva de aprendizaje era baja.
Recibimos mucho feedback de que GitLab tiene demasiadas funciones, es difícil y pesado..
Opiniones de Hacker News
El personal de soporte al cliente desapareció y ahora todas las consultas tienen que pasar por el equipo de ventas, mientras que la mayoría de las funciones están atadas al caro plan Ultimate.
Las funciones que no son “AI” llevan años sufriendo los mismos problemas y siguen abandonadas.
Así que ahora, cada vez que llega un correo de ventas, termino jugando a “¿cuándo volveremos a ver la velocidad de desarrollo de antes?”
Entre 2015 y 2020 lo usé con gusto, pero todas las funciones eran toscas y parecía más enfocado en llenar una checklist de funcionalidades que en terminarlas bien.
Quizás era una decisión inevitable para que un equipo pequeño compitiera contra las grandes empresas.
Diez años después sigue igual, y Gitea o Forgejo son mucho más rápidos; además, después del lanzamiento de Go 1.26 deberían mejorar todavía más.
Sobre todo, la búsqueda de issues es tan lenta que no pienso volver a usarlo.
En 2018 migré de Bitbucket y Confluence a GitLab Cloud, y los productos de Atlassian eran muchísimo más lentos y complejos.
GitLab se sentía ligero y rápido, y todavía hoy la mayor parte funciona bien.
Hace poco usé Jira Cloud y me pareció mucho más lento e incómodo.
Es algo realmente sorprendente.
El consumo eléctrico del servidor bajó 10%, y en GitLab había demasiadas funciones innecesarias, así que la UI se sentía sofocante.
Forgejo es simple y permite ocultar funciones por proyecto.
Eso sí, no tiene actualizaciones automáticas, está menos pulido y algunas funciones no trabajan bien.
No sé si era un tema de Jekyll o algo hecho a mano, pero navegarlo daba gusto.
Conserva el CI, el seguimiento de issues y lo que necesito, pero la interfaz carga al instante y no tiene funciones innecesarias.
La sintaxis de GitLab CI me gustaba más, pero la API de Forgejo está menos pulida.
Aun así, como se puede acceder directamente a la base de datos, se resuelve con scripts personalizados.
Levanto un clúster de Kubernetes y conecto Forgejo con Argo para hacer pruebas.
No sé si tiene sentido usar recursos de Codeberg en vez de los de Microsoft.
Por lo visto el CI lo maneja un proyecto llamado Woodpecker, y me da curiosidad cómo se compara con GitLab CI.
GitLab, aunque no llega al nivel de Gerrit, sí soporta MRs apilados y permite seguir viendo comentarios incluso después de un force push.
Creo que la cultura de PRs gigantes al estilo GitHub perjudica tanto la productividad como la cultura de revisión.
Las funciones administrativas, como la configuración de sincronización LDAP, todavía tienen margen de mejora, pero la sintaxis de CI/CD suele ser cómoda.
Lo usé a diario entre 2021 y 2024, al punto de llevar un registro aparte de bugs.
Dejé esa experiencia en un comentario anterior.
El issue tracker simple de GitHub es muchísimo más fácil de usar.
Puede que a los project managers les guste GitLab, pero desde el punto de vista del usuario GitHub se siente mejor.
Ahora uso GitHub y todo es mucho más simple y eficiente.
De verdad odio GitLab.
En el caso de las imágenes Docker, solo hay límite por capa, y la capacidad total puede ser mucho mayor.
Documentación relacionada: Storage Usage Quotas, Container Registry Issue
Me dan ganas de subir un REMUX de Interstellar de 70 GB.
Se repite el patrón de “intentas hacer algo → error → buscas → encuentras un reporte oficial de bug de hace 3 a 8 años”.
Muchas funciones se quedan en un nivel de acabado 80/20, y la vista de MR es tan lenta que desespera.
Dejé comentarios al respecto en un comentario anterior.
Me gusta que se puedan integrar registros de paquetes Maven, NPM y Python dentro del pipeline de CI.
Pero tiene demasiadas funciones y cada pantalla se siente dos veces más lenta.
Después cambiamos a Azure DevOps, pero es lento y sus quality gates son deficientes.
El servidor de builds pasó a ser una VM y, por las limitaciones de IOPS, los builds se volvieron lentos.
Me gustaría volver a GitLab, e incluso estaría dispuesto a contribuir a mejorar el rendimiento.