GitLab CI - Histórico de revisão

Daniel.alves em 16h08min de 16 de fevereiro de 2017

2017-02-16T16:08:47Z

Daniel.alves: /* Acompanhar a execução do Build */

2017-02-16T15:25:45Z

‎Acompanhar a execução do Build

Daniel.alves: /* Acompanhar a execução do Build */

2017-02-16T15:24:57Z

‎Acompanhar a execução do Build

Daniel.alves em 19h01min de 15 de fevereiro de 2017

2017-02-15T19:01:49Z

Daniel.alves em 17h02min de 15 de fevereiro de 2017

2017-02-15T17:02:54Z

Daniel.alves: /* Arquivo executor da análise de Código: sonar.ps1 */

2017-02-15T15:04:17Z

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

Daniel.alves em 19h29min de 13 de fevereiro de 2017

2017-02-13T19:29:50Z

Daniel.alves: Criou página com 'O GitLab CI é a ferramenta de CI (''Continuous Integration'') e CD (''Continuous Deployment'') disponibilizada para testar, construir (''build'') e instalar (''deploy'') o c...'

2017-02-08T21:53:33Z

Criou página com 'O GitLab CI é a ferramenta de CI (''Continuous Integration'') e CD (''Continuous Deployment'') disponibilizada para testar, construir (''build'') e instalar (''deploy'') o c...'

Página nova

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 [http://docs.gitlab.com/ee/ci 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 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;

<syntaxhighlight lang="yml">
stages:
- test
- build

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

sonar:
stage: test
script:
- echo Executing sonar scripts...
- .\sonar.ps1
</syntaxhighlight>

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.

[[Arquivo:CiLintValidate.PNG|thumb|100px|CI Lint result]]
O GitLab CI trás uma ferramenta para validar a sintaxe de escrita do arquivo, o [https://gitlab.mstech.com.br/ci/lint CI Lint]. O resultado de análise da sintaxe demonstrada acima pode ser visualizada na imagem ao lado.

===Arquivo executor do Build: build.ps1===
O ''build'' desenvolvido pela MSTech para utilização nos sistemas desenvolvidos em C# é baseado na linguagem [http://cakebuild.net/docs/tutorials/getting-started CAKE].

← Edição anterior		Edição das 16h08min de 16 de fevereiro de 2017
Linha 98:		Linha 98:

	[[Arquivo:GitLabCI-failed.PNG\|400px]]		[[Arquivo:GitLabCI-failed.PNG\|400px]]
		+
		+	===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.

@@ Linha 73: / Linha 73: @@
 ===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:
+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:
 [[Arquivo:GitLabCI-pending.PNG|800px]]

@@ Linha 74: / Linha 74: @@
 ===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:
-[[Arquivo:GitLabCI-pending.PNG|400px]]
 Tão logo o ''build'' inicie o ''status'' será alterado conforme a imagem abaixo:
-[[Arquivo:GitLabCI-running.PNG|400px]]
 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:

← Edição anterior		Edição das 19h01min de 15 de fevereiro de 2017
Linha 94:		Linha 94:

	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'':		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'':
		+
	[[Arquivo:GitLabCI-failed.PNG\|400px]]		[[Arquivo:GitLabCI-failed.PNG\|400px]]

← Edição anterior		Edição das 17h02min de 15 de fevereiro de 2017
Linha 71:		Linha 71:

	À 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.		À 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:
		+	[[Arquivo:GitLabCI-pending.PNG\|400px]]
		+
		+	Tão logo o ''build'' inicie o ''status'' será alterado conforme a imagem abaixo:
		+	[[Arquivo:GitLabCI-running.PNG\|400px]]
		+
		+	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:
		+	[[Arquivo:GitLabCI-status.PNG\|400px]]
		+
		+	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:
		+	[[Arquivo:GitLabCI-passed-sonar.PNG\|400px]]
		+
		+	O resultado de todos os ''builds'' do projeto pode ser visualizado à partir do menu ''Pipeline'' do projeto, conforme imagem abaixo:
		+	[[Arquivo:GitLabCI-todos-builds.PNG\|400px]]
		+
		+	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'':
		+	[[Arquivo:GitLabCI-failed.PNG\|400px]]

@@ Linha 18: / Linha 18: @@
 $json = ConvertFrom-Json $str
 $version = $json.FullSemVer
 write-host ProjectId:$CI_PROJECT_ID
 write-host ProjectName: $CI_PROJECT_NAME
@@ Linha 24: / Linha 23: @@
 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
-sonar-scanner.bat -D sonar.projectKey=mstech.$CI_PROJECT_NAME -D sonar.projectName=$CI_PROJECT_NAME -D sonar.projectVersion=$version -D sonar.analysis.mode=preview -D sonar.issuesReport.console.enable=true -D sonar.gitlab.url=https://gitlab.mstech.com.br -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
-−
-write-host Sonar executado com sucesso no projeto $CI_PROJECT_NAME versao $version
 </syntaxhighlight>
-Este arquivo não deve ser alterado.
+Por precaução, este arquivo não deve ser alterado.
 O arquivo sonar.ps1 depende do arquivo sonar.properties, com o seguinte conteúdo:

@@ Linha 9: / Linha 9: @@
 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 de configuração do Build: ''.gitlab-ci.yml''===
@@ Linha 38: / Linha 74: @@
 O GitLab CI trás uma ferramenta para validar a sintaxe de escrita do arquivo, o [https://gitlab.mstech.com.br/ci/lint CI Lint]. O resultado de análise da sintaxe demonstrada acima pode ser visualizada na imagem ao lado.
-===Arquivo executor do Build: build.ps1===
+À 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.
-O ''build'' desenvolvido pela MSTech para utilização nos sistemas desenvolvidos em C# é baseado na linguagem [http://cakebuild.net/docs/tutorials/getting-started CAKE].