Continuous Integration com Gitlab CI

Na Synchro utilizamos Gitlab como repositório de código, além de algumas outras features como issues, milestones, code review, e wiki. Particularmente sou muito fã do Gitlab! É muito bem construído e é uma excelente alternativa ao Github.

Mas hoje vou falar específicamente do Gitlab CI, que provê suporte a continuous integration, continous deployment e continous delivery. Não vou entrar muito no detalhe de cada um desses conceitos pois a ideia deste post é ser algo prático.

Portanto, vamos nos ater a como colocar continuous integration para rodar hoje.

A ideia básica do CI é que para um determinado commit ser integrado no repositório de código central, devemos garantir que ele não quebre a compilação nem os testes automatizados. É claro que há muito mais, inclusive livros inteiros sobre o assunto.

Então, para cada commit, o Gitlab CI irá rodar um pipeline de integração que passa por alguns estágios. Estes estágios podem ser diferentes para cada projeto, porém basicamente, irão compilar e executar os testes automatizados. Além disso, após compilado e testado com sucesso, podemos construir uma imagem docker e realizar o deploy deste container em um ambiente de aceite ou produção, por exemplo. Mas aí já estamos entrando em continous deployment e delivery.

Dessa forma, se algum commit quebrar a base de código, teremos esse feedback imediato e podemos corrigir o problema.

A implementação de um bom fluxo de CI passa por um bom uso do git. Ou seja, realizando commits coerentes, utilizando features branches e merge requests, por exemplo. Também existe uma biblioteca inteira sobre esse assunto. Mas como eu disse anteriormente, vou deixar a teoria para depois.

Mão na massa!

Runners

A primeira coisa que devemos fazer é configurar um Runner. Um Runner, é um ambiente, uma EC2 ou seu laptop, responsável por executar os passos (scripts) descritos pelos jobs do pipeline de integração. Portanto, é a máquina que de fato irá executar o trabalho de integração.

Existem várias formas de instalar um Runner, você pode escolher usa preferida aqui.

Eu usei o pacote oficial para CentOS (na verdade uso Fedora, mas funciona também).

Adicione o repositório do gitlab.

curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash

E depois é só rodar um yum

sudo yum install gitlab-ci-multi-runner

Feito! Agora você precisa registrar seu Runner junto ao seu Gitlab.

sudo gitlab-ci-multi-runner register

Ao registrar, você deve informar a url do seu Gitlab e o token específico do seu projeto. Você pode obter esse token, a partir da pagina inicial do seu projeto no Gitlab, em Settings -> Runners ou acessando diretamente <seu-projeto>/runners.

Ainda durante o processo de registro do runner, você será perguntado quanto ao tipo seu runner. Pode ser shell, docker, docker-ssh, ssh. Vamos de Docker.

Pronto! Agora o Gitlab já conhece seu Runner e ele está pronto para executar alguns jobs!

.gitlab-ci.yml

Além de ter um Runner para rodar os jobs da integração continua, precisamos dizer o que o runner deve fazer durante a integração. Para tanto devemos especificar o passo a passo a ser executado em um arquivo específico.

Este arquivo é o .gitlab-ci.yml. Ele fica na raiz do seu projeto. Quando houver um push para o repositório central, o Gitlab CI irá executar o pipeline de integração conforme descrito neste arquivo.

Temos que definir basicamente duas coisas para ter um CI mínimo: Jobs e Stages.

Um job possui um nome e define, obrigatóriamente, uma cláusula script que determina o que deve ser feito. Por exemplo, um job para compilar um projeto Gradle, poderia ser definido da seguinte forma:

compile:  
   script:    
    - gradle assemble

A definição de stages determina a ordem que os jobs devem ser executados. Dessa forma, poderíamos definir um pipeline da seguinte forma:

stages:
   - clean 
   - compile
   - test

Juntando tudo, temos o seguinte .gitlab-ci.yml

stages:
  - clean 
  - compile 
  - test
clean:
  script:
   - gradle clean
compile
  script:
    - gradle assemble
test:
  type: test
  script:
    - gradle test

Aqui você encontra a documentação completa sobre o .gitlab-ci.yml

Quando registramos nosso Runner, escolhemos Docker. Portanto, precisamos também especificar qual imagem Docker queremos para rodar nossos jobs. Como estamos falando de um projeto gradle, temos que escolher uma imagem que tenha JDK e Gradle instalados.

Por sorte existe uma imagem Docker perfeita para isso: image: frekele/gradle:2.4-jdk7u80. Adicionando isso, temos:

image: frekele/gradle:2.4-jdk7u80
stages:
  - clean 
  - compile 
  - test
clean:
  script:
   - gradle clean
compile
  script:
    - gradle assemble
test:
  type: test
  script:
    - gradle test

Prontinho! Isso é tudo que você precisa para ter todas as maravilhas que o GilabCI pode te proporcionar.

É isso ai! Configure GitlabCI no seu projeto e conte como foi nos comentários. Qualquer dúvida, deixe um comentário também.

Nos próximos posts vamos entrar em continous delivery e continous deployment, e vou falar um pouco mais sobre conceitos e teoria também.

Valeuuuu!!!!