GitLab — fundamentos, recursos e CI/CD

O que é GitLab?

GitLab — é uma plataforma DevOps completa de código aberto sob licença MIT. Ao contrário do GitHub, que combina vários serviços por meio de integrações, o GitLab fornece uma única ferramenta para todo o ciclo de vida do desenvolvimento: desde gerenciamento de código e revisão de código até CI/CD, monitoramento, segurança e implantação. A plataforma não requer serviços de terceiros para a maioria das tarefas de DevOps.

A história do GitLab começou em 2011 como um projeto interno de desenvolvedores ucranianos. A primeira versão pública foi lançada em setembro de 2011, e em 2015 o GitLab se tornou o primeiro projeto no GitLab.com, lançando hospedagem em nuvem. Em 2017, o GitLab realizou um processo de migração doloroso, mas instrutivo — transferindo toda a infraestrutura do Azure para o Google Cloud, que foi conduzido ao vivo e documentado em uma série de posts.

A arquitetura do GitLab consiste em três componentes principais: GitLab Rails (aplicação web em Ruby on Rails), GitLab Shell (manipulação de operações Git via SSH) e Gitaly (servidor gRPC para acesso a dados Git). O CI/CD é fornecido pelo GitLab Runner — um aplicativo separado instalado em servidores de build que executa jobs em ambientes isolados (Docker, Kubernetes, VirtualBox).

GitLab CI/CD: pipelines e runners

GitLab CI/CD — é um sistema integrado de integração e entrega contínuas que é uma vantagem fundamental da plataforma. Ao contrário do GitHub Actions, o GitLab CI/CD foi incorporado à arquitetura desde o início e não requer configuração separada: cada projeto obtém automaticamente CI/CD após adicionar o arquivo .gitlab-ci.yml à raiz do repositório.

Um pipeline consiste em estágios que são executados sequencial ou paralelamente: build → test → deploy. Cada estágio contém um ou mais jobs que são executados nos runners. Se um job em um estágio falhar, todo o estágio é marcado como falho e os estágios subsequentes não são executados por padrão. Abaixo está um exemplo de pipeline para um projeto móvel:

# .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

O GitLab Runner suporta vários executores: Docker (recomendado), Kubernetes, SSH, VirtualBox e Parallels. A opção mais popular é o executor Docker, que executa cada job em um contêiner separado. Um runner pode ser registrado como específico para um projeto ou como compartilhado (shared) para todo um grupo. O GitLab.com fornece runners compartilhados gratuitos com um limite de 2000 minutos por mês.

Recursos avançados de CI/CD

GitLab CI/CD suporta acionamento manual (when: manual), acionamento atrasado (when: delayed), execução paralela (parallel: 5), matriz (matrix), pipelines dinâmicos (child pipelines) e pipelines multinível (parent-child). Isso permite construir cenários complexos: por exemplo, gerar dinamicamente um pipeline para cada módulo em um monorepositório ou executar builds paralelos para diferentes arquiteturas Android (arm64, x86_64).

GitLab vs GitHub: diferenças principais

GitLab e GitHub — são os dois principais concorrentes no mercado de plataformas Git, mas suas filosofias e arquiteturas diferem fundamentalmente. O GitHub foca na comunidade aberta, em um ecossistema de integrações e em recursos sociais (forks, estrelas). O GitLab foca em um ciclo DevOps abrangente e fornece todas as ferramentas prontas para uso: do planejamento ao monitoramento.

A principal diferença arquitetural: GitLab — é um aplicativo monolítico único que o desenvolvedor instala por completo. Todos os recursos (CI/CD, Container Registry, Security Scanning, Pages) são integrados e funcionam imediatamente após a instalação. O GitHub é uma plataforma com API onde a maioria dos recursos é implementada por meio de integração com serviços de terceiros: Travis CI, CircleCI, Jenkins, SonarQube. A tabela abaixo compara as principais características:

A escolha entre GitLab e GitHub depende das necessidades da equipe. Se a prioridade é implantação rápida com configuração zero e uma comunidade aberta — escolha GitHub. Se você precisa de controle total sobre a infraestrutura, hospedagem autogerenciada e segurança integrada — GitLab é preferível. De acordo com uma pesquisa do Stack Overflow (2024), 90% dos desenvolvedores usam GitHub, 33% usam GitLab (frequentemente ambas as plataformas simultaneamente).

Self-Managed GitLab: instalação no seu próprio servidor

Self-Managed GitLab (anteriormente On-Premises) permite instalar a plataforma em seu próprio servidor e ter controle total sobre dados, infraestrutura e tempo de atividade. Isso é especialmente importante para organizações com requisitos de conformidade: setor financeiro, instituições governamentais, organizações médicas onde os dados não podem ser armazenados em servidores de terceiros.

A instalação do GitLab é suportada no Ubuntu, Debian, CentOS e via Docker. O pacote oficial Omnibus inclui todos os componentes: servidor web (NGINX), banco de dados (PostgreSQL), cache (Redis), manipulador Git (Gitaly) e processos em segundo plano. Requisitos mínimos: 4 GB de RAM e 2 CPU para equipes de até 100 pessoas. Para instalações grandes com alta carga, é recomendado separar os componentes em servidores distintos.

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

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

# Visualizando o status
sudo gitlab-ctl status
sudo gitlab-ctl tail

O Self-Managed GitLab não tem limites de minutos de CI/CD — todos os runners pertencem à organização e sua potência é limitada apenas pelo seu próprio hardware. Também estão disponíveis Geo-replicação para regiões, logs de auditoria, bloqueio por IP e integração com provedores corporativos LDAP/SAML. O GitLab lança atualizações todo mês (no dia 22) com novos recursos e correções de segurança.

Ferramentas de segurança integradas do GitLab

A segurança no GitLab é integrada ao nível da plataforma e inclui vários scanners que funcionam em cada etapa do pipeline. SAST (Static Application Security Testing) analisa o código-fonte em busca de vulnerabilidades sem executar o aplicativo, suportando mais de 15 linguagens, incluindo Java, Kotlin, Swift, Python e JavaScript. DAST (Dynamic Application Security Testing) testa aplicações web em execução em busca de vulnerabilidades internamente.

Ferramentas adicionais: Container Scanning verifica imagens Docker em busca de vulnerabilidades nas camadas base; Dependency Scanning analisa as dependências do projeto e alerta sobre CVEs conhecidas; Secret Detection encontra chaves de API, senhas e tokens comprometidos acidentalmente; Fuzz Testing realiza testes automatizados com dados malformados para encontrar bugs não óbvios. Todos os resultados de varredura são exibidos em um Painel de Segurança unificado.

O GitLab também fornece Compliance — ferramentas para atender requisitos regulatórios. O Compliance Dashboard mostra o status de conformidade de todos os projetos, o Audit Events registra cada ação do administrador e desenvolvedor, e os Compliance Frameworks permitem aplicar políticas de configuração obrigatoriamente para grupos específicos de projetos. Isso torna o GitLab uma escolha popular em ambientes empresariais com requisitos rigorosos de segurança.

Container Registry e Dependency Proxy

GitLab Container Registry — é um registro Docker integrado ao CI/CD. Após construir uma imagem Docker em um pipeline, ela pode ser imediatamente publicada no Registry usando as variáveis de ambiente CI_REGISTRY e CI_REGISTRY_USER. O Registry suporta cache pull-through, marcação, políticas de limpeza e varredura de vulnerabilidades diretamente no registro.

Dependency Proxy — é um mecanismo de cache para contêineres e imagens de registros externos (Docker Hub, Quay, GCR). Quando um pipeline solicita uma imagem como ubuntu:latest, o GitLab primeiro verifica seu cache — se a imagem já foi baixada, ela não é baixada novamente. Isso reduz a carga em registros externos, acelera os pipelines e protege contra os limites de taxa do Docker Hub.

Para desenvolvedores móveis, o GitLab fornece GitLab Pages para hospedar documentação e relatórios de teste. Após executar os testes, os artefatos (relatórios HTML, capturas de tela, logs) podem ser publicados como Pages e um link pode ser compartilhado com a equipe de QA. Isso é mais conveniente do que enviar relatórios para armazenamento em nuvem, pois tudo reside dentro do mesmo projeto GitLab.

API do GitLab e Webhooks

A API do GitLab (REST e GraphQL) fornece acesso a todos os recursos da plataforma: projetos, usuários, pipelines, Merge Requests, registro. A API é usada para automação: criar um projeto a partir de um modelo, atribuir um revisor, obter o status do pipeline. Webhooks permitem enviar notificações HTTP para sistemas externos em eventos: push, merge, criação de Issue. Os Webhooks integram-se com Mattermost, Slack, Telegram e sistemas de monitoramento internos.

GitLab Pages para documentação móvel

GitLab Pages publica automaticamente sites estáticos a partir de um repositório. Para projetos móveis, o Pages é útil para hospedar documentação de API, relatórios de cobertura de teste e resultados de análise lint. A publicação ocorre automaticamente após um pipeline bem-sucedido — basta adicionar uma etapa de deploy com publicação no Pages. O resultado está disponível em https://namespace.gitlab.io/project-name.