GitLab CI

O GitLab CI é a ferramenta de CI (Continuous Integration) e CD (Continuous Deployment) disponibilizada para testar, construir (build) e instalar (deploy) o código desenvolvido.

Devido aos novos desafios de entrega contínua houve a necessidade de se descontinuar o uso do Jenkins como orquestrador de build e adotar o GitLab CI.

Mais informações pode ser acessadas diretamente no site do fabricante.

Configurando o Build no Gitlab CI

Como o GitLab CI vai executar os mesmos passos de build que o Jenkins executava, os seus arquivos de execução são os mesmos, e para organiza-los e começar a utilizar o GitLab CI é necessário criar o do arquivo .gitlab-ci.yml na raiz do projeto.

Arquivo executor do Build: build.ps1

O build desenvolvido pela MSTech para utilização nos sistemas desenvolvidos em C# é baseado na linguagem CAKE. O passo a passo de configuração do build utilizando o CAKE está disponível em no repositório do GitLab, a parte sobre o Jenkins deve ser desconsiderada.

Arquivo executor da análise de Código: sonar.ps1

O arquivo sonar.ps1 deve ser criado na raiz do projeto com o conteúdo abaixo:

$str = GitVersion.exe | out-string
$json = ConvertFrom-Json $str
$version = $json.FullSemVer
write-host ProjectId:$CI_PROJECT_ID
write-host ProjectName: $CI_PROJECT_NAME 
write-host Version: $version 
write-host Commit: $CI_BUILD_REF 
write-host RefName: $CI_BUILD_REF_NAME 
sonar-scanner.bat -D sonar.projectKey=mstech.$CI_PROJECT_NAME -D sonar.projectName=$CI_PROJECT_NAME -D sonar.projectVersion=$version -D sonar.gitlab.commit_sha=$CI_BUILD_REF -D sonar.gitlab.ref_name=$CI_BUILD_REF_NAME -D sonar.gitlab.project_id=$CI_PROJECT_ID -D sonar.gitlab.url=https://gitlab.mstech.com.br -D sonar.analysis.mode=preview -D sonar.issuesReport.console.enable=true

Por precaução, este arquivo não deve ser alterado.

O arquivo sonar.ps1 depende do arquivo sonar.properties, com o seguinte conteúdo:

# Uncomment this line to analyse a project which is not a java project.
# The value of the property must be the key of the language.
sonar.language=cs

# Scanner directories
sonar.sources=src
sonar.sourceEncoding=UTF-8
sonar.exclusions=**/vendor/**/*, **/Assets/libs/**/*, **/bin/**/*, **/obj/**/*, **/*.csproj, **/*.vspscc, **/*.sln, **/*.suo, **/node_modules/**/*, **/bower_components/**/*, **/src/packages/**/*, **/*.config, **/App_Data/**/*, **/src/libraries/**/*, **/src/scripts/**/*

Nesse arquivo deve ser informado qual a pasta onde está o fonte do sistema e quais as pastas devem ser excluídas da análise.

Arquivo de configuração do Build: .gitlab-ci.yml

O arquivo .gitlab-ci.yml abaixo executa as mesmas atividades antes realizadas pelo Jenkins, ou seja:

• Executar o build a cada commit, realizado independente do branch; e
• Executar a análise de código via SonarQube;

stages:
- test
- build

compilar:
  stage: build
  script:
  - echo Executing cake scripts...
  - .\build.ps1

sonar:
  stage: test
  script:
  - echo Executing sonar scripts...
  - .\sonar.ps1

No exemplo, temos dois estágios (test e build) e dois jobs (compilar e sonar). Os estágios são sempre executados na sequência na qual foram declarados, nunca são executados em paralelo. Os jobs, por sua vez, são executados em paralelo desde que estejam dentro do mesmo estágio. No exemplo acima cada job será executado dentro de seu respectivo estágio, portanto, serão executados separadamente.

CI Lint result

O GitLab CI trás uma ferramenta para validar a sintaxe de escrita do arquivo, o CI Lint. O resultado de análise da sintaxe demonstrada acima pode ser visualizada na imagem ao lado.

À partir da inclusão deste arquivo no projeto o mesmo será automaticamente "construído" (build), e o resultado pode ser acompanhado à partir da tela inicial do projeto.

Acompanhar a execução do Build

Quando qualquer alteração é enviada para o servidor do GitLab através de um commit o GitLab CI irá iniciar o build do projeto, tendo como base o identificador do commit que foi realizado. Lembrando que, o status da tela inicial será exibido apenas quando o branch master for alterado, os demais branchs devem ser acompanhados através do menu pipelines. O build quando "enfileirado" será exibido conforme a imagem abaixo:

Tão logo o build inicie o status será alterado conforme a imagem abaixo:

Para verificar o status de cada passo do build basta clicar no ícone do build (no nosso caso no momento está como running) para que a imagem abaixo seja exibida:

Como pode-se observar na imagem acima, temos 3 estágios sendo executados:

• Test;
• Build; e
• External (criado pelo Test, pois irá executar tarefas externas, no nosso caso a devolução da análise do SonarQube para o GitLab).

Ao clicar nos estágios Test e Build é possível verificar o status de cada um deles e a sua execução, conforme o exemplo baixo:

O resultado de todos os builds do projeto pode ser visualizado à partir do menu Pipeline do projeto, conforme imagem abaixo:

Caso qualquer um dos passos falhe na sua execução o build será marcado como failed, conforme o exemplo abaixo é possível verificar que a execução falhou no terceiro passo, no caso o passo external:

Bugs Conhecidos

• Integração do SonarQube com GitLab
  • O plugin que executa a integração entre ambas as ferramentas acima utiliza um comando que está marcado como deprecated, então, é possível que em algum momento o mesmo retorne falha na execução.