GitLab self-hosted num time pequeno: do deploy manual à pipeline

TL;DR - O deploy era um processo manual que podia levar dias entre agendar e terminar. Montei a pipeline de CI/CD no nosso GitLab self-hosted com Docker, e hoje um merge na branch principal é uma release. Rodar o próprio GitLab funciona bem para um time pequeno se você tratar ele como produção: backup junto com o arquivo de secrets, runners longe do servidor e upgrade com data marcada.

Quando entrei, levar uma mudança pra produção significava alguém buildar na mão, copiar para um servidor e torcer pra nada estar diferente da última vez. Uma release podia levar dias entre “está pronto” e “está no ar”. Correção pequena esperava pela grande.

A empresa já rodava GitLab na própria infraestrutura, com um time pequeno usando. Migrar para SaaS não era prioridade, então construí em cima do que tinha.

A pipeline

Todo serviço tem a mesma pipeline: build, teste, build da imagem Docker, push para o registry, deploy no ECS. A imagem buildada uma vez é a mesma que vai para staging e depois para produção. Nada é buildado de novo entre ambientes.

flowchart LR
  MR[Merge request] --> Build[Build e testes]
  Build --> Image[Imagem Docker]
  Image --> Registry[(Registry)]
  Registry --> Staging[Deploy staging]
  Staging --> Prod[Deploy produção]

Versionamento e changelog fazem parte da release, não são algo que alguém lembra de fazer depois. Toda release tem uma versão e uma lista do que mudou, que o suporte lê antes de falar com o cliente.

O que rodar o próprio GitLab exige

• Runners separados do servidor do GitLab. Um build pesado nunca pode deixar a interface web ou um git push lentos.
• Disco. O registry e os artefatos dos jobs crescem bem mais rápido que os repositórios. Configure expire_in nos artefatos e uma política de limpeza no registry, senão o disco vira alerta toda semana.
• Backup com o arquivo de secrets. O backup do GitLab não inclui o gitlab.rb nem o gitlab-secrets.json. Sem o arquivo de secrets, um restore perde as variáveis de CI e as configurações de autenticação em dois fatores. Faça backup deles à parte e teste o restore numa instância descartável.
• Upgrade com data marcada. O GitLab tem paradas obrigatórias de upgrade e não dá pra pular. Upgrade pequeno todo mês assusta bem menos que um salto grande por ano.

O que mudou

Release deixou de ser evento. Uma correção sai no mesmo dia do merge, e rollback é fazer deploy da imagem anterior. Isso fez mais pela confiança do time do que qualquer documento de processo.