- Apresenta a experiência de uso de longo prazo do GitLab com foco em gerenciamento de projetos pessoais e integração de CI/CD
- No início, o principal diferencial em relação ao GitHub era a oferta de repositórios privados gratuitos, e depois disso o fluxo de trabalho acabou se consolidando por completo
- O recurso Container Registry é o mais utilizado, permitindo armazenar imagens sem precisar gerenciar conta ou token separados no Docker Hub
- Os principais pontos fortes citados são os pipelines do GitLab CI baseados em arquivo de configuração, os runners compartilhados gratuitos e a documentação abrangente
- Por outro lado, a lentidão da interface web e o excesso de funcionalidades são apontados como desvantagens, e usar GitHub e GitLab em paralelo conforme o objetivo é a forma mais eficiente
Contexto de uso do GitLab
- O uso começou na época em que o GitHub cobrava por repositórios privados, enquanto o GitLab oferecia repositórios privados gratuitos
- Isso permitia gerenciar vários projetos experimentais sem torná-los públicos
- Depois, o GitHub adotou uma política gratuita, mas como pipelines de CI, imagens Docker e scripts de deploy já estavam estruturados em torno do GitLab, deixou de haver motivo para migrar
Recurso de Docker Registry
- Todo projeto no GitLab já inclui por padrão o Container Registry
- O fluxo é simples: criar a imagem localmente ou no CI, fazer push e depois fazer pull onde for necessário
- Não é preciso gerenciar conta ou token separados no Docker Hub, nem se preocupar com limites de pull
- Para projetos pessoais, os recursos são mais que suficientes, e o limite de 10 GB na prática não chega a ser um problema
- A limpeza de tags antigas e o compartilhamento de camadas ajudam a manter o uso de espaço eficiente
Ambiente de CI/CD
- O GitLab CI implementou desde cedo o conceito de “CI baseado em arquivo de configuração”
- Basta adicionar o arquivo
.gitlab-ci.yml para que o pipeline seja executado automaticamente
- Como a configuração fica versionada, é possível rastrear o estado de pipelines anteriores
- O pipeline padrão é composto por build da imagem, push e deploy opcional
- A etapa de deploy pode ser controlada por gatilho manual
- Os runners compartilhados são gratuitos, mas lentos; quando necessário, é fácil instalar um runner próprio em uma VPS
- A documentação de CI/CD é muito extensa e, depois que se aprende o padrão, fica eficiente gerenciar tudo por meio de cópia e reutilização de configurações existentes
Pontos incômodos
- A interface web é lenta, com tempo de espera ao alternar entre merge requests, pipelines e logs
- Parece ter melhorado um pouco recentemente, mas ainda é mais lenta que a do GitHub
- Existe também o problema de excesso de funcionalidades
- Há vários recursos, como issue tracking, wiki, package registry e security scanning, mas o uso real fica em torno de apenas 10%
- Ainda assim, existe a vantagem potencial de já ter funções embutidas disponíveis quando necessário
Custos e fluxo de trabalho
- Cerca de 12 projetos pessoais estão sendo mantidos gratuitamente, incluindo desde projetos ativos até experimentos interrompidos
- O GitLab é tratado como espaço de trabalho privado, e o GitHub como espaço para compartilhar projetos públicos
- O GitHub é mais adequado para colaboração e visibilidade, enquanto o GitLab se encaixa melhor em experimentação e automação
- Essa estrutura paralela entre as duas plataformas funciona como uma forma de manter equilíbrio e eficiência no fluxo de trabalho
3 comentários
Dizem que o GitLab é bem avaliado pela qualidade do CI/CD.
Mas, no meu caso, por causa das limitações da conta gratuita, mesmo que houvesse suporte ao coreano eu acabo recorrendo ao GitHub.
Quanto ao Forgejo e ao Gitea, que é sua base, eles passam uma sensação de imitação do GitHub, então não me atraem muito.
Nós usamos o Gitea, e o adotamos porque, por causa daquela imagem parecida, a curva de aprendizado era menor.
Havia muito feedback de que o GitLab é difícil e pesado por ter funções demais..
Comentários no Hacker News
Os atendentes de suporte ao cliente desapareceram e toda solicitação precisa passar pela equipe de vendas, enquanto a maioria dos recursos ficou presa ao caro plano Ultimate
Os recursos que não são “AI” continuam com os mesmos problemas há anos e seguem largados
Então agora, toda vez que chega um e-mail de vendas, eu acabo jogando o jogo de “quando será que vou voltar a ver a velocidade de desenvolvimento de antes?”
Entre 2015 e 2020 eu usei com prazer, mas todos os recursos eram toscos e o foco parecia estar mais em preencher checklist de funcionalidades do que em terminar bem as coisas
Talvez tenha sido uma escolha inevitável para um time pequeno competir com grandes empresas
Dez anos depois continua assim, e Gitea ou Forgejo são muito mais rápidos; depois do lançamento do Go 1.26 deve ficar ainda melhor
Principalmente a busca de issues é lenta demais, a ponto de eu não querer usar de novo
Em 2018 migrei de Bitbucket e Confluence para o GitLab Cloud, e os produtos da Atlassian eram muito mais lentos e complicados
O GitLab pareceu leve e rápido, e até hoje a maior parte funciona bem
Recentemente usei o Jira Cloud e achei muito mais lento e incômodo
É um comportamento realmente surpreendente
O consumo de energia do servidor caiu 10%, e o GitLab tinha recursos desnecessários demais, deixando a UI sufocante
O Forgejo é simples e permite esconder recursos por projeto
Só que não tem atualização automática, o acabamento é inferior e alguns recursos não funcionam direito
Não sei se era um tema do Jekyll ou algo feito do zero, mas navegar já era agradável por si só
Mantive o CI, rastreamento de issues e o que eu precisava, mas a interface carrega instantaneamente e não tem recursos inúteis
Eu gostava mais da sintaxe do GitLab CI, mas a API do Forgejo é menos refinada
Ainda assim, dá para resolver com scripts customizados porque é possível acessar o DB diretamente
Eu subo um cluster Kubernetes, conecto Forgejo e Argo e faço os testes
Não sei se faz sentido usar recursos do Codeberg em vez dos da Microsoft
Pelo visto o CI fica a cargo de um projeto chamado Woodpecker, e tenho curiosidade de comparar com o GitLab CI
O GitLab, embora não chegue ao nível do Gerrit, suporta MR em pilha e permite ver comentários mesmo depois de force push
Acho que a cultura do GitHub centrada em grandes PRs prejudica a produtividade e a cultura de revisão
Funções administrativas, como configurar sincronização LDAP, ainda têm espaço para melhorar, mas a sintaxe de CI/CD costuma ser conveniente
Usei diariamente entre 2021 e 2024 e cheguei a manter um diário de bugs à parte
Deixei essa experiência em um comentário anterior
O rastreador de issues simples do GitHub é muito mais fácil de usar
Gerentes de projeto podem gostar do GitLab, mas do ponto de vista do usuário o GitHub parece melhor
Agora uso GitHub e tudo é muito mais simples e eficiente
Eu realmente odeio o GitLab
No caso de imagens Docker, existe apenas limite por camada, e o tamanho total pode ser bem maior
Documentação relacionada: Storage Usage Quotas, Container Registry Issue
Tenho vontade de subir um REMUX de Interstellar com 70 GB
O padrão “tentar fazer algo → erro → pesquisar → encontrar bug report oficial de 3 a 8 anos atrás” se repete o tempo todo
Muitos recursos ficam presos num nível de acabamento 80/20, e a visualização de MR é tão lenta que dá sofrimento
Deixei algo sobre isso em um comentário anterior
Gosto do fato de poder integrar registries de pacotes Maven, NPM e Python no pipeline de CI
Mas ele tem funcionalidades demais, e toda tela parece duas vezes mais lenta
Mais tarde mudamos para Azure DevOps, que é lento e tem quality gates ruins
O servidor de build virou VM e, por causa do limite de IOPS, os builds ficaram lentos
Quero voltar para o GitLab e até teria disposição para contribuir com melhorias de desempenho