Gitlab v.9.1.2 Features

Recentemente tivemos um grande trabalho na atualização e virtualização de nosso servidor Gitlab. Pois, estavamos na versão 7.10.0 (última versão da release 7.x.x), e atualizamos para a versão 9.1.2. Mediante este cenário, quais a features mais significativas que tivemos de lá pra cá?

Gitlab LFS

O Large File Storage (LFS) substitui arquivos grandes como amostras de áudio, vídeos, conjuntos de dados e gráficos ao armazenar o conteúdo do arquivo em um servidor remoto ou local. Com este recurso podemos versionar grandes arquivos em formatos binários gerando mais espaço nos repositórios de código, melhorando significamente a velocidade de clonagem, fork, e fetching dos repositórios git.

Durante o processo de clonagem, ou busca de um determinado repositório, com o Git LFS os arquivos grandes de audio, video, executáveis e binários em geral não serão automaticamente clonados junto. Ao invés, estes arquivos serão baixados somente durante o git checkout e ocasionalmente. Isto ajuda a reduzir impactos com arquivos grandes aos repositórios.

Git LFS faz isso através da substituição de arquivos grandes em seu repositório por arquivos pequenos que apontam para tais, como um link simbólico por exemplo. Durante o uso normal, você nunca precisará se preocupar com estes arquivos de ponteiro, ou link simbólicos, pois eles são tratados automaticamente pelo Git LFS como mostra a imagem a seguir:

Quando for necessário dar um git push ao Gitlab, qualquer arquivo grande que for referenciado ao LFS pelo commit, será automaticamente transferido do seu cache local LFS, para o repositório LFS remoto ligado ao repositório Git.

Além disso, este recurso mantém a mesma estrutura de fluxo dos repositórios (dando um destino novo aos binários), e com as mesmas regras de permissão e acesso. Ainda não compreendeu o funcionamento do Git LFS? A comunidade GIT-SCM disponibilizou um vídeo muito bacana que explica bem o seu funcionamento (clique na imagem a baixo):

Git Large File Storage - How to Work with Big Files

Compreendendo seu funcionamento, agora é a hora de aprender como usar este recurso. A comunidade Gitlab, Git-SCM, entre tantas outras disponibilizaram materiais ensinando a usar o Git LFS. A seguir alguns materiais produzidos pela comunidade sobre o uso do Git LFS:

  1. Using Gitlab LFS
  2. Git SCM Tutorial

Obs: O git LFS já está habilitado em nosso servidor Gitlab.


Integração contínua

Nessa versão do Gitlab, já é possível fazer integração contínua. Mas que diabos é isso?

"Integração Contínua é uma pratica de desenvolvimento de software onde os membros de um time integram seu trabalho frequentemente, geralmente cada pessoa integra pelo menos diariamente – podendo haver multiplas integrações por dia. Cada integração é verificada por uma build automatizada (incluindo testes) para detectar erros de integração o mais rápido possível. Muitos times acham que essa abordagem leva a uma significante redução nos problemas de integração e permite que um time desenvolva software coeso mais rapidamente". - Martin Fowler.

É possível configurar o Gitlab para gerar uma build de nosso serviço e levantar na máquina local ou remota, da aplicação. Por exemplo, toda vez que um desenvolvedor fizer um push ou commit em uma determinada aplicação, será gerado uma imagem que será disponibilizada no Docker Registry que é um repositório docker local.

Em outras palavras, esta imagem é uma aplicação virtual isolada que sobe exatamente o serviço em questão e com todos os requisitos, e dependências que configurar-mos no arquivo YAML responsável pelo provisionamento do serviço. Oi? O que você quis dizer com tudo isso?

Dito de maneira bruta, tudo é feito a partir do gitlab. Desde o versionamento de código e binários (com o LFS), até a criação de uma máquina virtual para testar se a aplicação está Ok, para então subir em produção. Na verdade, mais do que isso, além dos testes automatizados, é possível também a partir do Gitlab, efetuar o deploy automatico da aplicação. Maneiro né?

Como que faz para habilitar a funcionalidade de integração contínua no Gitlab?

Para tal, é necessário criar no repositório, um arquivo chamado .gitlab-ci.yml. Pós ter criado este arquivo, irá aparecer uma opção chamada Set up CI que é onde vamos definir todas as regras quando o desenvolvedor fizer um push, ou qualquer outro trigger que tem como objetivo disparar esta funcionalidade de CI (Integração Contínua). Este processo é conhecido como PIPELINE.

O responsável dentro do Gitlab por fazer estes builds toda vez que a gente faz um push, é o Gitlab Runner. O Runner é uma alternativa do Gitlab ao famoso Jenkins. Este é um exemplo de entrega de software Ágil. Tudo é feito a partir do Gitlab. Aqui nós deixamos a aplicação pronta para o deploy.

Mas como fazemos o deploy?

Se a proposta de integração contínua é automatizar as coisas, por que não automatizar também o deploy? Assim, teremos um ambiente muito próximo ao de produção para poder testar as funcionalidades e encontrar bugs enquanto isso. E nada melhor do que resolver isso antes do projeto entrar em produção, certo?

O gitlab agora conta com uma solução chamada Auto Deploy que também segue o mesmo conceito Docker. Para quem não lembra como funciona o Docker, deixo aqui o link dos dois artigos de introdução à Docker que escrevi:

  1. Docker um novo conceito de virtualização - Parte 1
  2. Docker um novo conceito de virtualização - Parte 2

Obs: Como este artigo tem a proposta de somente descrever as principais releases desta nova versão do Gitlab, em outra oportunidade darei mais detalhes sobre a integração contínua. E com certeza iremos estudar maneiras para implementar este sistema ao nosso fluxo de trabalho.


Snippets

Alguém aqui já usou o recurso Gist do Github? Semelhante à proposta do Gist, os Snippets no gitlab são espaços para escrever textos (anotações), ou pequenas faixas de código. Este é um bom lugar para colocar código ou texto que é usado semi-regularmente dentro do projeto, mas não pertence no controle de origem.

Por exemplo, um arquivo de configuração específico que é usado pela equipe que só é válido para as pessoas que trabalham no projeto. Como os script's de deploy que vocês usam, sabe?


Discussions in Merge Requests and Issues

Nesta versão é possível abrir comentários em merge requests na linha de comentários principal sem se referir a qualquer linha específica de código.

O mesmo é possível nas Issues:


Application Monitoring UX Improvements

Agora é possível monitorar um número de pequenas alterações que foram feitas para uma determinada aplicação e seu fluxo de trabalho tornando mais fácil de acompanhar sua evolução. O mesmo vale para uso de memória e processamento da aplicação que rodam em ambientes virtuais através das Pipelines criadas.


Existem outras features. No entanto, as mais significativas giram em torno do conceito Pipeline com a integração contínua e auto deploy. Em outra oportunidade irei escrever em detalhes como fazer os testes automatizados usando o conceito Pipeline, o deploy e todas as funcionalidades pertinentes a esta feature em específico. Até um próximo post, e espero que tenham gostado da abordagem dada a este material.


Referência: