Quem me conhece sabe o quão fã do Gitlab eu sou.
Separei algumas funcionalidades que me fazem gostar tanto da ferramenta.
Existem outros pontos, mas aqui estão os principais.
Espero que gostem.

Histórico

O Gitlab foi criado em 2011 para ser uma ferramenta de versionamento a nível do GitHub, mas que pudesse rodar localmente na infraestrutura da empresa, ou em nuvem de graça para repositórios privados.

A empresa cresceu muito desde sua criação e transformou o produto numa completa plataforma para times de desenvolvimento de software, gerência de projetos e orquestração de releases.

Foram pioneiros em diversas iniciativas, como por exemplo, ter a CI na mesma solução de versionamento.

Marcam presença em alguns quadrantes da Gartner, como:

• Enterprise Agile Planning Tools - 2020 Visionary
• Application Security Testing - 2020 Niche
• Application Release Orchestration - 2019 Challenger
• Voice of the Customer - 2020 Leader

Repositórios - SCM

As telas de Merge Request foram elaboradas para unir todas as informações necessárias para fazer uma boa revisão de código e de funcionalidades.

Multiplos aprovadores podem se fazer necessários em algumas situações, ou arquivos específicos precisam de aprovações de pessoas específicas para serem alterados… Tudo isso é possível configurar.

Separação de repositórios em subgrupos para melhor organização e liberação de acessos.

WEB IDE para alterações rápidas sem a necessidade de baixar o código. Muito bom para corrigir algum teste que falou na CI, ou mudar algo solicitado na revisão de código, por exemplo.

CI/CD

Gitlab foi eleito em 2019 pelo devops.com o melhor provedor de solução Devops do mercado.

É possível ver mais sobre todo o fluxo de desenvolvimento e implantação aqui.

Seu código e a CI sempre juntos

Aqui é um exemplo de commit que teve a pipeline executada:

Esse é um relatório de testes unitários coletados na pipeline anterior:

Ambientes

Além da CI integrada no mesmo lugar do repositório. Os ambientes em que sua
aplicação será disponibilizada também tem seu lugar no Gitlab.

A seguir, um merge request que já foi aceito e suas alterações já se entram em
staging e também em produção:

Dashboard de ambientes

Serve para visualizar os ambientes de diferentes projetos para uma visão do
todo sobre a pipeline de cada ambiente.
Em um único lugar, você pode ver o progresso e mudanças de desenvolvimento,
staging até produção, assim como ambientes customizados.

Rollback

Uma vez que o ambiente tiver sido implantado, uma entrada é criada na tela de
ambiente e é possível fazer re-deploy de qualquer versão desejada
instantaneamente:

Review app

É uma forma automatizada de levantar e derrubar ambientes dinamicamente para
realizar validação de funcionalidades para testes manuais ou automatizados.

Permite que o time de QA, designers ou PMs consigam acessar a aplicação antes
do seu código ter sido aceito e sem a necessidade de negociar o uso do ambiente
com outros times e pessoas.

Entrega o poder de realizar deploys sempre que uma modificação for submetida.

Para ganhar esse poder numa pipeline existente, precisa-se usar algumas chaves
na configuração de environment.

image: deployment:image

restrictions:review: &restrictions_review
  when: manual
  except: [master]
  only: [branches]

deploy:review:
  <<: *restrictions_review
  environment:
    name: review/$CI_COMMIT_REF_NAME
    url: http://$CI_ENVIRONMENT_SLUG-backoffice-app.k8s.domain
    on_stop: stop_app:review
    auto_stop_in: 1 days
  script:
    -  # Command to create environment

stop_app:review:
  <<: *restrictions_review
  environment:
    name: review/$CI_COMMIT_REF_NAME
    action: stop
  script:
    -  # Command to destroy environment

Com a alteração acima, é possível visualizar e interagir com os ambientes que
as alterações do merge afetou ou pode afetar.

Temos um botão para visualizar o app e outro para desativar o ambiente.

Visual reviews

Aliado ao review app, existe a funcionalidade de visual reviews que serve
exclusivamente para front-end web. Ela permite que comentários sejam feitos
diretamente na aplicação e que aparecerão no merge request.

É possível visualizar um balão do lado direito, que é um JS do gitlab que foi
injetado no momento de build.

Ao clicar nesse balão, o usuário pode fazer seu comentário normalmente:

O comentário aparecerá no merge request com as seguintes informações:

Kubernetes

Com a integração ligada, podemos usufruir de:

• Review Apps
• Executar pipelines
• Implantar applications
• Detectar e monitorar Kubernetes
• Usar Web terminals
• Explorar Logs
• Executar workloads serverless com Knative[^2]
• Usar Deploy Boards[^1]
• Usar Canary Deployments[^1]

[^1]: Somente na versão silver
[^2]: Alpha

Web terminal

Se o deploy da aplicação for feito através da integração com o Kubernetes, será
possível abrir uma sessão de terminal via interface WEB.
Essa é uma ótima maneira de realizar debug e empoderar o time.
Também é possível configurar níveis de acesso ao terminal.

Pode-se acessar o terminal de duas formas:

• Na tela de listagem de ambientes:
  
• Na tela do ambiente desejado:
  

Ao abrir, ele se parecerá com esse terminal e você está executando os comandos
no container da sua aplicação no ambiente desejado.

Canary deploy

Canary deploy é uma estratégia de implantação contínua que consiste em fazer
publicações incrementais.

Se algum problema acontecer com sua nova versão, somente a porcentagem de
usuários que você definiou será afetada. Assim, a mudança pode ser corrigida
ou revertida rapidamente.

If there is a problem with the new version of the application, only a small
percentage of users are affected and the change can either be fixed or quickly
reverted.

Explorador de logs

Para que o desenvolvedor não precise sair da interface do Gitlab, ele traz uma
forma simples para visualizar os logs das aplicações gerenciadas nos clusters
Kubernetes integrados. A interface de exploração de logs entrega filtros para
facilitar seu uso:

Deploy board

Oferece uma visão consolidade da saúde de cadas ambiente da CI que está sendo
executado com a integração do kubernetes.

Todos podem visualizar o progresso e status de um ‘rollout’, POD por POD.

Runners privados e públicos

O Gitlab possui dois tipos de runners em nuvem: públicos e privados.

Públicos

• Gerenciados pelo GitLab
• Extremamente lentos
• Possuem cota mensal
• Pode-se comprar mais horas
• Ideal para passos da build que podem demorar mais
• Bom para projetos pequenos
• Não conseguem acessar uma infraestrutura privada (precisa de VPN ou afins)

Privados

• São executados em nossa infraestrutura
• Podem ser e implantados num Kubernetes
• Não tem nenhum custo adicional de licença ou limite
• A performance depende da máquina provisionada
• Pode acessar a infraestrutura privada.
• A comunicação é sempre de fora pra dentro

Agradecimentos

Tive duas pessoas que me ajudaram na construção desse artigo e deixo meu agradecimento à ambos.

• Adriano Azevedo
• Paulo Patto