Mudanças entre as edições de "GitLab CI"

Edição das 15h04min de 15 de fevereiro de 2017

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.