Objetivo · Web view, as entregas tornaram-se mais rápidas e menores, permitindo que o trabalho seja executado em paralelo pelos membros da equipe. Com diversas alterações sendo

Guia de Entrega ContínuaManual de configuração dos projetos de software da CTINF

Janeiro de 2019


Página 2/30Versão 3.0

Histórico de versões

Número Modificação Data Responsáveis

1.0 Criação do documento 05/12/2018 Matheus Rizzo / Cláudio Araujo / Oduvaldo Vick Neto

2.0 Definições do Sonar 20/12/2018 Cláudio Araujo

3.0 Definições do Jenkins 10/01/2019 Matheus Rizzo

4.0 Criação do Pipeline 06/02/2019 Matheus Rizzo

5.0 Revisão do documento 05/04/2019 Matheus Rizzo / Oduvaldo Vick/ Cláudio Araujo



Sumário

1. Objetivo.................................................................................................................................................................6

2. Integração, Entrega e Implantação Contínua........................................................................................................63. SonarQube.............................................................................................................................................................6

3.1. Visão Geral.....................................................................................................................................................................6

3.2. SonarLint........................................................................................................................................................................ 7

3.3. Procedimento de execução............................................................................................................................................9

4. Jenkins...................................................................................................................................................................94.1. Visão Geral.....................................................................................................................................................................9

4.2. Configurações Gerais....................................................................................................................................................10

4.3. Projetos Novos.............................................................................................................................................................114.3.1. Projetos Web ASPNETCORE....................................................................................................................................................11

4.4. Projetos Legados..........................................................................................................................................................224.4.1. ASP – Active Server Pages.......................................................................................................................................................23

4.5. Observações Importantes.............................................................................................................................................28

4.6. Rollback........................................................................................................................................................................29



Índice de figuras

Figura 1 – SonarQube – Resultado da análise do projeto...........................................................................................7

Figura 2 - SonarLint - Problemas destacados no editor..............................................................................................8Figura 3 - SonarLint - Problemas gerais no painel lista de erros.................................................................................8

Figura 4 - Pipeline - Estrutura básica..........................................................................................................................9Figura 5 - Pipeline de Desenvolvimento...................................................................................................................12

Figura 6 - Pipeline de Homologação.........................................................................................................................17Figura 7 - Pipeline de Produção................................................................................................................................20

Figura 8 - Pipeline de Desenvolvimento - ASP..........................................................................................................23Figura 9 - Pipeline de Homologação - ASP................................................................................................................25

Figura 10 - Pipeline de Produção - ASP.....................................................................................................................27



Índice de tabelas

Nenhuma entrada de índice de ilustrações foi encontrada.



1. Objetivo

O principal objetivo deste documento é complementar o “guia de desenvolvimento de sistemas da CTINF”,

servindo como base para a configuração do processo entrega contínua de software da CTINF.A correta configuração do processo de entrega contínua permitirá que os softwares sejam compilados,

testados, implantados e analisados quanto às métricas de qualidade, de forma automática.Além disso, a entrega contínua permitirá a implantação dos softwares de maneira mais objetiva, em menor

tempo, com menor custo e sem comprometer sua qualidade.

2. Integração, Entrega e Implantação Contínua

Com a evolução das metodologias ágeis de desenvolvimento de softwares, as entregas tornaram-se mais

rápidas e menores, permitindo que o trabalho seja executado em paralelo pelos membros da equipe. Com diversas alterações sendo entregues simultaneamente, tornou-se necessário a utilização de uma ferramenta

automatizada para, dentre outras tarefas, realizar a junção, compilação, testes e implantação do código.A integração contínua é uma prática onde os desenvolvedores integram com frequência suas alterações ao

código principal do software. Depois disso builds e testes são executados, garantindo seu correto funcionamento.A entrega contínua reúne um conjunto de práticas que garantem que um código possa ser publicado no

ambiente de produção. Porém, a implantação neste ambiente, necessita de intervenção manual. O código é, de forma automática, analisado, compilado, testado e publicado em outros ambientes (desenvolvimento e

homologação). A integração contínua faz parte da entrega contínua.A implantação contínua pode ser considerada uma “evolução” da entrega contínua, pois o código é

disponibilizado automaticamente em produção (sem intervenção manual), realizando também as etapas da entrega contínua.

3. SonarQube

3.1. Visão Geral

O SonarQube é uma plataforma de código aberto, desenvolvida pela SonarSource, para inspeção contínua da qualidade do código.

Através do Quality Gate é possível identificar quando um projeto está apto a ser publicado em produção. Utilizando métricas pré-definidas, a ferramenta, por meio da análise estática de código, revisa o código e

apresenta informações como detecção de bugs, code smells (características no código-fonte que possivelmente indica um problema mais profundo) e vulnerabilidades de segurança em mais de 20 linguagens de programação,

além de apresentar relatórios contendo informações sobre cobertura de testes, duplicações de código, padrões de codificação, complexidade de código, comentários, dentre outros.



A CTINF utiliza o perfil Sonar Way C# (default). As regras contidas neste perfil podem ser modificadas à

critério da CTINF.

Figura 1 – SonarQube – Resultado da análise do projeto

A versão do SonarQube utilizada atualmente no Inmetro é a SonarQube versão 6.7.6.* A versão poderá ser atualizada conforme análise prévia da CTINF;

3.2. SonarLint

O SonarLint é uma extensão IDE que ajuda a detectar e corrigir problemas de qualidade enquanto o

desenvolvedor escreve o código. Como um verificador ortográfico, o SonarLint elimina falhas para que possam ser corrigidas antes de validar

o código.Para instalá-lo no Microsoft visual Studio, basta seguir os passos:

Iniciar o Start Visual Studio 2017 Acessar Menu -> Tools -> Extensions and Updates

Opção Online Pesquisar “Sonar”

Selecionar “SonarLint for Visual Studio 2017” Download

Restart no Visual Studio Adicionar a aba do SonarLint no Visual Studio através do Menu -> Exibir -> Lista de Erros



Figura 2 - SonarLint - Problemas destacados no editor

Figura 3 - SonarLint - Problemas gerais no painel lista de erros



3.3. Procedimento de execução

O procedimento de validação do código poderá ser realizado de duas formas:

Automática: O Integrador Contínuo (Jenkins) dispara o evento (dentro do pipeline) para executar a verificação das métricas através da ferramenta de análise de código (Sonar) com base nas métricas

pré-definidas (perfil). Manual: Analisada através da inspeção de código feita pela CTINF.

Os resultados dessas análises estão vinculados as Metas de Qualidade definidas pela CTINF.

4. Jenkins

4.1. Visão Geral

O Jenkins é um servidor de automação independente e de código aberto que disponibiliza centenas de plugins que automatizam tarefas relacionadas à integração, entrega e implantação contínua.

Ele pode ser instalado por meio de pacotes nativos do sistema, Docker ou até mesmo executado de forma independente, necessitando apenas de uma máquina com Java Runtime Environment (JRE) instalado.

A versão do Jenkins utilizada atualmente no Inmetro é a LTS 2.150.1

Para maiores informações sobre esta ferramenta, acesse: https://jenkins.io/

Dentre as formas que a ferramenta Jenkins nos permite implementar o processo de entrega contínua, no Inmetro, utilizamos o modelo de pipeline declarativo (declarative pipeline).

Figura 4 - Pipeline - Estrutura básica

https://jenkins.io/



O JenkinsFile (pipeline ou Jenkins pipeline) é um arquivo texto, em forma de script, que automatiza o

processo de implantação de softwares, tornando-o repetitivo e confiável. Para cada projeto, a CTINF deverá criar três jenkinsFiles, sendo um para cada ambiente, seguindo o seguinte

padrão de nomenclatura: JenkinsFile_DESENVOLVIMENTO.txt

JenkinsFile_HOMOLOGACAO.txt JenkinsFile_PRODUCAO.txt

Estes arquivos deverão estar versionados na ferramenta de controle de versão do Inmetro, dentro da pasta

JenkinsFiles/Nome_do_projeto, localizada no endereço: https://desinmetro:18080/svn/inmetro/Jenkins/JenkinsFiles/

Deve-se criar um pipeline por ambiente (desenvolvimento, homologação e produção) no Jenkins, apontando

para o arquivo JenkinsFile correspondente na ferramenta de controle de versão. Estes pipelines devem apresentar a seguinte sintaxe:

Desenvolvimento: nome_do_projeto_DSV Homologação: nome_do_projeto_HML

Produção: nome_do_projeto_PRD

A estratégia de check-out do jenkinsFile deve ser “do not touch working copy it is updated by another script”

Na criação e/ou preenchimento do JenkinsFile, alguns pontos deverão ser observados, como: Colocar barras duplas “\\” nos caminhos

O arquivo é case sensitive, ou seja, letras maiúsculas são diferentes de letras minúsculas.

Não existe um JenkinsFile 100% implementado para qualquer projeto. Apesar da necessidade de seguir alguns padrões para os projetos do Inmetro, existem especificidades que precisam ser tratadas caso a caso.

Portanto, nos tópicos seguintes, serão apresentados os modelos de jenkinsFiles a serem utilizados nos projetos do Inmetro e como modificá-los e/ou configurá-los.

4.2. Configurações Gerais

Para a grande maioria dos projetos, algumas configurações serão necessárias: Gerar uma chave única para o projeto - Esta chave identificará o projeto no Sonar. Para evitar

duplicidade, ela pode ser gerada utilizando um algoritmo MD5 e tendo como semente o nome do projeto (não aplicável quando o projeto não for analisado pelo Sonar).

Criar três variáveis de ambiente no Jenkins contendo os e-mails dos interessados do projeto, por ambiente. Estas variáveis devem seguir o padrão email_projeto_ambiente (todas as letras em

minúsculo) e conterá o e-mail dos envolvidos no projeto separados por ponto-e-vírgula. Ex:

https://desinmetro:18080/svn/inmetro/Jenkins/JenkinsFiles/Projeto



o Ex: “[email protected]; [email protected]; [email protected]”

Solicitar à SEINF:

o Criação dos servidores web de desenvolvimento, homologação, produção e testes (quando

necessário)o Acesso às pastas onde o sistema será implantado

o Criação dos usuários e senhas, para acesso às pastas, nas credentials do Jenkins.

Solicitar ao(s) DBA(`s):

o Criação dos bancos de dados de desenvolvimento, homologação, produção e testes (não

aplicável o banco de testes quando o projeto não possuir testes codificados).o Criação dos usuários e senhas, caso não existam, com permissão para executar scripts DML,

DDL, DQL, DTL e DCL. E adicionar esses usuários nas credentials do Jenkins (não aplicável

quando o projeto não for executar scripts de migration).

4.3. Projetos Novos

São considerados projetos novos todos os projetos criados a partir da criação deste documento.

4.3.1.Projetos Web ASPNETCORE

mailto:[email protected]





4.3.1.1. Desenvolvimento

Figura 5 - Pipeline de Desenvolvimento

VCS Checkout – O projeto é copiado da ferramenta de controle de versão para o workspace do

projeto no Jenkins. Nuget Restore – Os pacotes nugets são restaurados. As fontes de dados dos pacotes nugets devem

ser informadas como parâmetro, utilizando a sintaxe -source “endereço do repositório”.o -source "https://api.nuget.org/v3/index.json" – repositório nuget na internet

o -source "%PACKAGES%" – variável de ambiente que aponta para a pasta do repositório na

intranet do Inmetro.

Iniciar Análise do Sonar – Informa à ferramenta Sonar, que ela deve monitorar o projeto que será compilado e testado. Os seguintes parâmetros devem ser configurados:

o sonar.cs.opencover.reportsPaths – Informa o local e nome do arquivo xml onde estará o

resultado da cobertura dos testes.o sonar.coverage.exclusions – Informa quais pastas/extensões/arquivos devem ser ignorados

na cobertura dos testes.

o sonar.exclusions – Informa quais pastas/extensões/arquivos devem ser ignorados na análise

das métricas de qualidade de software pelo Sonar. Build e Package – Compila o projeto e cria o pacote que será implantado nos ambientes. Os

seguintes parâmetros devem ser configurados:



o CreatePackageOnPublish – Informa que além de compilar o código, deve-se gerar o pacote

que irá ser implantado nos ambientes.

o ContinueOnError – Informa que a compilação deve continuar ou não ao apresentar erros.

o DeployOnBuild – Informa que o projeto web precisa ser “empacotado” como parte do build

o Configuration – Informa se o projeto deve ser compilado como debug ou release.

Executar Testes unitários – Executam-se os testes unitários do projeto. Executar Testes de Integração – Executam-se os testes de integração do projeto. Para correta

execução deste teste, a ferramenta Jenkins, utilizando o powershell, altera a string de conexão “Default” contida no arquivo de configuração deste projeto (appsettings.json). Para maior

segurança, o usuário e a senha estarão configurados nas credentials do Jenkins. Para ambos os testes (unitários e integração), os seguintes parâmetros devem ser configurados:

o mergeWith – Informa o caminho do arquivo json gerado por testes anteriores para realizar o

merge.o collectCoverage – Informa se a cobertura dos testes deve ser analisada pelo Sonar.

o coverletOutputFormat – Informa qual formato o relatório dos testes será gerado. Deve-se

optar pelo formato json se o teste não for o último teste a ser executado, para

posteriormente ser possível realizar o merge dos resultados de todos os testes. Caso contrário, deve-se optar pelo formato opencover para conseguir importar os resultados

gerados por outros testes anteriores no formato json, e enviá-los ao Sonar.o coverletOutput – Informa o caminho e o nome do arquivo que será gerado com os

resultados da cobertura dos testes.

Desligar Análise do Sonar – Informa a ferramenta Sonar, que ela deve encerrar o monitoramento do projeto e gerar os resultados da análise.

Executar Testes de Interface – Executam-se os testes de interface (tela). Para correta execução deste teste, a ferramenta Jenkins, utilizando o powershell, altera os seguintes itens contidos no

arquivo de configuração deste projeto (appsettings.json).o string de conexão “Default”. Para maior segurança, o usuário e a senha estarão

configurados nas credentials do Jenkins.

o BaseUrl – Contém o valor da URL do servidor web de testes que o teste deve acessar para

iniciar a execução. Deploy em Desenvolvimento – O pacote gerado no passo “Build & Package” é copiado para o

servidor de desenvolvimento. Atualizar Banco de Dados de Desenvolvimento – Executam-se os scripts no banco de dados de

desenvolvimento, utilizando o framework de migrations, implementado no desenvolvimento do software. É importante informar o parâmetro –tag Desenv para que os scripts exclusivos deste

ambiente sejam executados. Para maiores informações do restante dos parâmetros acesse: https://fluentmigrator.github.io/articles/runners/dotnet-fm.html

https://fluentmigrator.github.io/articles/runners/dotnet-fm.html



Arquivar os artefatos – Os artefatos gerados após o sucesso de uma publicação, como por exemplo,

os arquivos que são colocados no servidor web, são arquivados nas pastas do workspace do Jenkins. Além disso, a dll que contém o código das migrações de banco de dados também é arquivada. Este

passo se faz necessário para posteriormente, ao publicar o software em homologação, seja possível escolher qual build será publicado. Não é necessário armazenar os artefatos que apresentaram

erros. Para isso, informar o parâmetro “onlyIfSuccessful:true”. Enviar e-mail final processo – Ao finalizar o processo de publicação em desenvolvimento, um e-mail

será enviado, aos envolvidos no projeto, informando que a publicação foi finalizada com sucesso. Os destinatários serão configurados conforme descrito no item configurações gerais.

Enviar E-mail Falha – Em caso de erros em qualquer passo do fluxo, um e-mail informando que o software não foi publicado é enviado aos envolvidos no projeto. Neste e-mail, é anexado o log

contendo os erros. Os destinatários serão configurados conforme descrito no item configurações gerais.

É importante ressaltar que na ocorrência de erros em qualquer passo do processo acarretará o

cancelamento do restante do fluxo, não executando os passos seguintes.

4.3.1.2. Configurações Desenvolvimento

Para facilitar a utilização e configuração do JenkinsFile de desenvolvimento, foram criadas variáveis no início

do arquivo que devem ser configuradas conforme descrito a seguir: grupoEmail -> Deve ser preenchida seguindo o padrão “email_projeto_desenv” que apontará para

uma variável de ambiente do Jenkins, conforme descrito anteriormente.o Ex: “grupoEmail = email_EntregaContinua_desenv”

solutionPath -> Deve ser preenchida com o caminho para o arquivo da solução (.sln) do projeto que

ficará dentro do workspace do Jenkins. Não é necessário colocar o caminho físico completo. Basta preencher a partir do workspace.

o Ex: “EntregaContinua\\EntregaContinua.sln”

svnProjectPath -> Deve ser preenchida com o endereço http do repositório onde encontra-se a solução.

o Ex: “https://RCVSPRO01S:18080/svn/inmetro/Jenkins”

svnBrowserPath -> Deve ser preenchida com o endereço http de visualização do repositório no browser.

o Ex: “https://RCVSPRO01S:18080/viewvc/inmetro/Jenkins”

branch -> Deve ser preenchida com o nome da branch que contém o código fonte da solução a ser implantada. No caso no Inmetro, o código que será publicado deve estar na branch "trunk".

o Ex: “trunk”



sonarProjectName -> Deve ser preenchida com o nome do projeto que será criado na ferramenta de

análise de qualidade de código, Sonar. o Ex: “EntregaContinua”

sonarProjectKey -> Deve ser preenchida com a chave única que identifica o projeto no sonar, gerada

conforme descrito anteriormente. o Ex: “0917d43b2a22427c0b1fc87ce973e022”

unitTestProjectPath -> Deve ser preenchida com o caminho do arquivo do projeto de testes

unitários (.csproj), que ficará dentro do workspace do Jenkins. Não é necessário colocar o caminho físico completo. Basta preencher a partir do workspace.

o Ex: "EntregaContinua\\EntregaContinua.UnitTest.MSTest\\EntregaContinua.UnitTest.MSTest.csproj"

integrationTestProjectPath -> Deve ser preenchida com o caminho do arquivo do projeto de testes de integração (.csproj), que ficará dentro do workspace do Jenkins. Não é necessário colocar o

caminho físico completo. Basta preencher a partir do workspace.o Ex: "EntregaContinua\\EntregaContinua.IntegrationTest.NUnit\\EntregaContinua.IntegrationTest.NUnit.csproj"

integrationTestConfigPath -> Deve ser preenchida com o caminho do arquivo de configuração do

projeto de testes de integração (appsettings.json).Este arquivo deve conter uma seção “ConnectionStrings” e uma conexão com valor chave “Default”.

Isto é necessário pois o pipeline irá substituir o valor deste campo para o ambiente correto.o Ex: “EntregaContinua\\EntregaContinua.IntegrationTest.NUnit\\appsettings.json”

interfaceTestProjectPath -> Deve ser preenchida com o caminho do arquivo do projeto de testes de

interface (.csproj), que ficará dentro do workspace do Jenkins. Não é necessário colocar o caminho físico completo. Basta preencher a partir do workspace.

o Ex: "EntregaContinua\\EntregaContinua.IntegrationTest.NUnit\\EntregaContinua.InterfaceTest.csproj"

interfaceTestConfigPath -> Deve ser preenchida com o caminho do arquivo de configuração do projeto de testes de interface (appsettings.json).

Este arquivo deve conter uma seção “ConnectionStrings” e uma conexão com valor chave “Default”. Isto é necessário pois o pipeline irá substituir o valor deste campo para o ambiente correto.

o Ex: ”EntregaContinua\\EntregaContinua.InterfaceTest\\appsettings.json”

migrationsDllProjectPath -> Deve ser preenchida com o caminho da DLL do projeto que implementa o framework de migrations.

o Ex: "EntregaContinua\\EntregaContinua.NH.Migrations\\bin\\Release\\netcoreapp2.2\\

EntregaContinua.NH.Migrations.dll"

desenvDatabaseType -> Deve ser preenchida com a versão do banco de dados do ambiente de

desenvolvimento, conforme descrito em https://fluentmigrator.github.io/articles/multi-db-support.html

o Ex: “SQLServer2008”

https://fluentmigrator.github.io/articles/multi-db-support.html




testDatabaseType -> Deve ser preenchida com a versão do banco de dados do ambiente de testes,

conforme descrito em https://fluentmigrator.github.io/articles/multi-db-support.htmlo Ex: “SQLServer2008”

desenvIISProjectFolder -> Deve ser preenchida com o caminho da pasta criada no servidor web de

desenvolvimento, para realizar o deploy da aplicação.o Ex: “\\\\rappdes01s\\Sistemas\\EntregaContinua”

testIISProjectFolder -> Deve ser preenchida com o nome da pasta criada no servidor web de teste,

para realizar o deploy da aplicação.o Ex: “\\\\rappdes01s\\Sistemas\\EntregaContinua-t”

testeApplicationURL -> Deve ser preenchida com o endereço http do ambiente de testes, para

realizar o teste de interface.o Ex: “http://entregacontinua-t.inmetro.gov.br/”

solutionPublishPath -> Deve ser preenchida com o caminho da pasta do workspace do Jenkins que

conterá os arquivos do pacote a ser implantado no servidor web. o Ex: “EntregaContinua\\EntregaContinua.Web\\obj\\Release\\netcoreapp2.2\\PubTmp\\

Out”

testConnectionString -> Deve ser preenchida com o valor da string de conexão do servidor de testes. É importante ressaltar que essa string não deve conter usuário e senha. Estes valores serão obtidos

durante a execução do pipeline e estarão previamente configurados na área de credentials do Jenkins.

o Ex: “Server=TestDatabaseServer; DATABASE=EntregaContinuaIntegracao;”

desenvConnectionString -> Deve ser preenchida com o valor da string de conexão do servidor de desenvolvimento. É importante ressaltar que essa string não deve conter usuário e senha. Estes

valores serão obtidos durante a execução do pipeline e estarão previamente configurados na área de credentials do Jenkins.

o Ex: “Server=DesenvDatabaseServer; DATABASE=EntregaContinuaDesenvolvimento;”




4.3.1.3. Homologação

Figura 6 - Pipeline de Homologação

Informar Número do Deploy – É apresentada uma lista contendo os últimos deploys que ocorreram com sucesso em desenvolvimento, para que seja selecionado o que deve ser colocado em

homologação. Copiar artefatos de Desenvolvimento – Os artefatos gerados no deploy selecionado no primeiro

passo são copiados de desenvolvimento para o workspace do Jenkins de homologação. Gerar e Enviar Script BD para Aprovação – São gerados os scripts que serão executados no banco de

dados de homologação (utilizando o framework de migrations), entretanto, este script não é executado. Ele é enviado, por e-mail, aos participantes do grupo do AD, referentes aos “DBA`s” para

análise e aprovação. O arquivo é criado no formato “numero_do_build.sql”. Para gerar este script, precisamos informar os seguintes parâmetros:

o --preview – Informa que não se deve executar o script, mas sim, gerar um arquivo de

preview.o --output – Informa o local que o arquivo do script será gerado.

o --processor – Informa qual a versão e tipo do banco de dados



o --tag Homolog – Informa que além de gerar o preview das versões normais dos scripts, deve-

se gerar também os passos que possuam a tag Homolog.

o --connection – Informa a string de conexão com o banco de dados de homologação,

contendo usuário e a senha configurados nas credentials do Jenkins.o --assembly – Informa o caminho do arquivo .dll gerado pelo projeto de migrations.

DBA – Aprovar Mudanças – Aguarda a aprovação, pelos DBA`s, dos scripts enviados por e-mail no

passo anterior. Caso esse passo seja abortado, o deploy em homologação é cancelado e um e-mail é enviado aos envolvidos no projeto. Neste passo, somente quem faz parte do grupo do AD informado

no pipeline pode concluir a tarefa. Deploy em Homologação – São copiados os artefatos do workspace de homologação (gerados no

deploy em desenvolvimento) e colados no servidor web do ambiente de homologação. Atualizar Banco de dados de homologação – O script enviado aos DBAs, e posteriormente

aprovado, nos passos anteriores, é executado na base de dados de homologação. É importante informar o parâmetro –tag Homolog para que os scripts exclusivos deste ambiente sejam

executados. Para maiores informações dos restantes dos parâmetros acesse: https://fluentmigrator.github.io/articles/runners/dotnet-fm.html.

Arquivar Artefatos – Os artefatos publicados no servidor web de homologação, assim como o arquivo .dll do projeto de migrations, são arquivados nas pastas do workspace do Jenkins de

homologação. Este passo se faz necessário para posteriormente, ao publicar o software em produção, seja possível escolher qual build será publicado. Não é necessário armazenar os artefatos

que apresentaram erros. Para isso, informar o parâmetro “onlyIfSuccessful:true”. Enviar e-mail Final Processo – Ao finalizar o processo de publicação em homologação, um e-mail é

enviado, aos envolvidos no projeto, informando que a publicação foi finalizada com sucesso. Enviar E-mail Falha – Em caso de erros em qualquer passo do fluxo, um e-mail informando que o

software não foi publicado é enviado aos envolvidos no projeto. Neste e-mail, é anexado o log contendo os erros. Os destinatários serão configurados conforme descrito no item configurações

gerais. Enviar E-mail Reprovação – Em qualquer passo que necessite de aprovação, caso o responsável

reprove a tarefa, um e-mail é enviado aos envolvidos no projeto, informando que a tarefa foi reprovada. Os destinatários serão configurados conforme descrito no item configurações gerais.

4.3.1.4. Configurações Homologação

Nas configurações do pipeline de homologação, na aba general, a opção “este projeto é parametrizado”

deve ser marcada e configurada da seguinte forma: Tipo: Run Parameter

Name: desvBuildNumber Project: nome do pipeline de desenvolvimento referente ao projeto.




Filter: Marcar a opção somente builds que tiveram sucesso.

Para facilitar a utilização e configuração do JenkinsFile de homologação, foram criadas variáveis no início do

arquivo que devem ser configuradas conforme descrito a seguir: grupoEmail -> Deve ser preenchida seguindo o padrão “email_projeto_homolog” que apontará para

uma variável de ambiente do Jenkins, conforme descrito anteriormente. Ex:o Ex: “grupoEmail = email_EntregaContinua_homolog”

homologIISProjectFolder -> Deve ser preenchida com o caminho da pasta criada no servidor web de

homologação, para realizar o deploy da aplicação.o Ex: “\\\\servidor\\Sistemas\\EntregaContinua”

projectName -> Deve ser preenchida com o nome do projeto

o Ex: “EntregaContinua”

jenkinsDesenvPipelineName -> Deve ser preenchida com o nome do pipeline de desenvolvimento configurado no Jenkins, pois será o local onde o pipeline irá obter os artefatos para publicação.

o Ex: “EntregaContinua_DSV”

homologConnectionString -> Deve ser preenchida com o valor da string de conexão do servidor de homologação. É importante ressaltar que essa string não deve conter usuário e senha. Estes valores

serão obtidos durante a execução do pipeline e estarão previamente configurados na área de credentials do Jenkins.

o Ex: “Server=HomologDatabaseServer; DATABASE=EntregaContinuaHomologacao;”

homologDatabaseType -> Deve ser preenchida com a versão do banco de dados do ambiente de homologação, conforme descrito em https://fluentmigrator.github.io/articles/multi-db-support.html





solutionPublishPath -> Deve ser preenchida com o caminho workspace do Jenkins que contém os arquivos que serão publicados no servidor web de homologação.




4.3.1.5. Produção

Figura 7 - Pipeline de Produção

Informar Número do Deploy – É apresentada uma lista contendo os últimos deploys, que ocorreram

com sucesso no ambiente de homologação, para que seja selecionado o que deve ser colocado em produção.

Copiar artefatos de Homologação – Os artefatos gerados no deploy selecionado no primeiro passo são copiados de homologação para o workspace do Jenkins de produção.

Gerar e Enviar Script BD para Aprovação – São gerados os scripts que serão executados no banco de dados de produção (utilizando o framework de migrations), entretanto, este script não é executado.

Ele é enviado, por e-mail, aos participantes do grupo do AD, referentes aos “DBA`s” para análise e aprovação. O arquivo é criado no formato “numero_do_build.sql”. Para gerar este script, precisamos

informar os seguintes parâmetros:o --preview – Informa que não se deve executar o script, mas sim, gerar um arquivo de

preview.

o --output – Informa o local que o arquivo do script será gerado.

o --processor – Informa qual a versão e tipo do banco de dados



o --tag Prod – Informa que além de gerar o preview das versões normais dos scripts, deve-se

gerar também os passos que possuam a tag Prod.

o --connection – Informa a string de conexão com o banco de dados de produção, contendo

usuário e a senha configurados nas credentials do Jenkins.o --assembly – Informa o caminho do arquivo .dll gerado pelo projeto de migrations.

DBA – Aprovar Mudanças – Aguarda a aprovação, pelos DBA`s, dos scripts enviados por e-mail no passo anterior. Caso esse passo seja abortado, o deploy em produção é cancelado e um e-mail é

enviado aos envolvidos no projeto. Neste passo, somente quem faz parte do grupo do AD informado no pipeline pode concluir a tarefa.

Deploy em Produção – São copiados os artefatos do workspace de produção (gerados no deploy em homologação) e colados no servidor web do ambiente de produção.

Atualizar Banco de dados de produção – O script enviado aos DBAs, e posteriormente aprovado, nos passos anteriores, é executado na base de dados de homologação. É importante informar o

parâmetro –tag Prod para que os scripts exclusivos deste ambiente sejam executados. Para maiores informações dos restantes dos parâmetros acesse:

https://fluentmigrator.github.io/articles/runners/dotnet-fm.html. Arquivar Artefatos – Os artefatos publicados no servidor web de produção, assim como o arquivo

.dll do projeto de migrations, são arquivados nas pastas do workspace do Jenkins de produção. Este passo se faz necessário para posteriormente, ao publicar outras versões do software em produção,

seja possível realizar o rollback para uma versão estável. É importante ressaltar que serão armazenados somente os últimos 5 deploys. Não é necessário armazenar os artefatos que

apresentaram erros. Para isso, informar o parâmetro “onlyIfSuccessful:true”. Enviar e-mail Final Processo – Ao finalizar o processo de publicação em produção, um e-mail é



gerais. Enviar E-mail Reprovação – Em qualquer passo que necessite de aprovação, caso o responsável

reprove a tarefa, um e-mail é enviado aos envolvidos no projeto, informando que a tarefa foireprovada. Os destinatários serão configurados conforme descrito no item configurações gerais.

4.3.1.6. Configurações Produção

Nas configurações do pipeline de produção, na aba general, a opção “este projeto é parametrizado” deve ser marcada e configurada da seguinte forma:




Tipo: Run Parameter

Name: homologBuildNumber Project: nome do pipeline de homologação referente ao projeto.

Filter: Marcar a opção somente builds que tiveram sucesso.

Para facilitar a utilização e configuração do JenkinsFile de produção, foram criadas variáveis no início do arquivo que devem ser configuradas conforme descrito a seguir:

grupoEmail -> Deve ser preenchida seguindo o padrão “email_projeto_prod” que apontará para

uma variável de ambiente do Jenkins, conforme descrito anteriormente. Ex:o Ex: “grupoEmail = email_EntregaContinua_prod”

prodIISProjectFolder -> Deve ser preenchida com o caminho da pasta criada no servidor web de

produção, para realizar o deploy da aplicação.o Ex: “\\\\servidorProducao\\Sistemas\\EntregaContinua”

projectName -> Deve ser preenchida com o nome do projeto

o Ex: “EntregaContinua”

jenkinsHomologPipelineName -> Deve ser preenchida com o nome do pipeline de homologação configurado no Jenkins, pois será o local onde o pipeline irá obter os artefatos para publicação.

o Ex: “EntregaContinua_HML”

prodConnectionString -> Deve ser preenchida com o valor da string de conexão do servidor de produção. É importante ressaltar que essa string não deve conter usuário e senha. Estes valores

serão obtidos durante a execução do pipeline e estarão previamente configurados na área de credentials do Jenkins.

o Ex: “Server=ProdDatabaseServer; DATABASE=EntregaContinuaProducao;”

prodDatabaseType -> Deve ser preenchida com a versão do banco de dados do ambiente de produção, conforme descrito em https://fluentmigrator.github.io/articles/multi-db-support.html





solutionPublishPath -> Deve ser preenchida com o caminho workspace do Jenkins que contém os arquivos que serão publicados no servidor web de produção.

4.4. Projetos Legados

Este tópico apresenta as configurações e observações sobre a entrega continua de sistemas legados




4.4.1. ASP – Active Server Pages

Para projetos ASP cujas configurações são realizadas no arquivo global.asa, este deve ser triplicado, no

mesmo diretório, criando-se um arquivo para cada ambiente com suas respectivas configurações e um default: global.asa

global.asa_desenvolvimento global.asa_homologacao

global.asa_producao

4.4.1.1. Desenvolvimento

Figura 8 - Pipeline de Desenvolvimento - ASP

VCS Checkout – O projeto é copiado da ferramenta de controle de versão para o workspace do projeto no Jenkins.

Deploy em Desenvolvimento – Para correta configuração dos diversos ambientes, a ferramenta Jenkins, irá renomear o arquivo referente ao ambiente que ele será implantando:

o Global.asa_desenvolvimento -> renomeado para global.asa no ambiente de

desenvolvimento Arquivar os artefatos – Os artefatos gerados após o sucesso de uma publicação, são arquivados nas

pastas do workspace do Jenkins. Este passo se faz necessário para posteriormente, ao publicar o software em homologação, seja possível escolher qual build será publicado. Não é necessário

armazenar os artefatos que apresentaram erros. Para isso, informar o parâmetro “onlyIfSuccessful:true”.



Enviar e-mail final processo – Ao finalizar o processo de publicação em desenvolvimento, um e-mail

será enviado, aos envolvidos no projeto, informando que a publicação foi finalizada com sucesso. Os destinatários serão configurados conforme descrito no item configurações gerais.

Enviar E-mail Falha – Em caso de erros em qualquer passo do fluxo, um e-mail informando que o


gerais.

É importante ressaltar que na ocorrência de erros em qualquer passo do processo acarretará o cancelamento do restante do fluxo, não executando os passos seguintes.

4.4.1.2. Configurações Desenvolvimento

Para facilitar a utilização e configuração do JenkinsFile de desenvolvimento, foram criadas variáveis no início

do arquivo que devem ser configuradas conforme descrito a seguir: grupoEmail -> Deve ser preenchida seguindo o padrão “email_projeto_desenv” que apontará para

uma variável de ambiente do Jenkins, conforme descrito anteriormente.Ex: “grupoEmail = email_Cadorg_desenv”

svnProjectPath -> Deve ser preenchida com o endereço http do repositório onde encontra-se a solução.

o Ex: “https://RCVSPRO01S:18080/svn/inmetro/cadorg”

svnBrowserPath -> Deve ser preenchida com o endereço http de visualização do repositório no browser.

o Ex: “https://RCVSPRO01S:18080/viewvc/inmetro/cadorg”

branch -> Deve ser preenchida com o nome da branch que contém o código fonte da solução a ser implantada. No caso no Inmetro, o código que será publicado deve estar na branch "trunk".

o Ex: “trunk”

projectName -> Deve ser preenchida com o nome do projeto. o Ex: “Cadorg”

desenvIISProjectFolder -> Deve ser preenchida com o caminho da pasta criada no servidor web de

desenvolvimento, para realizar o deploy da aplicação.o Ex: \\\\rdes02s\\Sistemas\\SisAcre\\Principal\\Cadastro_Organismo”


conterá os arquivos do pacote a ser implantado no servidor web. o Ex: “aspClassico\\Cadastro_Organismo”

configPath -> Deve ser preenchida com o diretório do arquivo de configuração.

o Ex: “aspClassico\\Cadastro_Organismo”



configName -> Deve ser preenchida com o nome do arquivo de configuração.

o Ex: “global.asa”

4.4.1.3. Homologação

Figura 9 - Pipeline de Homologação - ASP

Informar Número do Deploy – É apresentada uma lista contendo os últimos deploys que ocorreram com sucesso em desenvolvimento, para que seja selecionado o que deve ser colocado em

homologação. Copiar artefatos de Desenvolvimento – Os artefatos gerados no deploy selecionado no primeiro

passo são copiados de desenvolvimento para o workspace do Jenkins de homologação. Deploy em Homologação – São copiados os artefatos do workspace de homologação (gerados no

deploy em desenvolvimento) e colados no servidor web do ambiente de homologação. Arquivar Artefatos – Os artefatos gerados após o sucesso de uma publicação, são arquivados nas

pastas do workspace do Jenkins. Este passo se faz necessário para posteriormente, ao publicar o software em produção, seja possível escolher qual build será publicado. Não é necessário armazenar

os artefatos que apresentaram erros. Para isso, informar o parâmetro “onlyIfSuccessful:true”. Enviar e-mail Final Processo – Ao finalizar o processo de publicação em homologação, um e-mail é



gerais.



4.4.1.4. Configurações Homologação

Nas configurações do pipeline de homologação, na aba general, a opção “este projeto é parametrizado” deve ser marcada e configurada da seguinte forma:

Tipo: Run Parameter Name: desvBuildNumber

Project: nome do pipeline de desenvolvimento referente ao projeto. Filter: Marcar a opção somente builds que tiveram sucesso.

Para facilitar a utilização e configuração do JenkinsFile de homologação, foram criadas variáveis no início do

arquivo que devem ser configuradas conforme descrito a seguir:

grupoEmail -> Deve ser preenchida seguindo o padrão “email_projeto_homolog” que apontará para uma variável de ambiente do Jenkins, conforme descrito anteriormente. Ex:

o Ex: “grupoEmail = email_Cadorg_homolog”

homologIISProjectFolder -> Deve ser preenchida com o caminho da pasta criada no servidor web de homologação, para realizar o deploy da aplicação.

o Ex: “\\\\rapphom02s\\Sistemas\\SisAcre\\Principal\\Cadastro_Organismo”

projectName -> Deve ser preenchida com o nome do projeto o Ex: “Cadorg”

jenkinsDesenvPipelineName -> Deve ser preenchida com o nome do pipeline de desenvolvimento

configurado no Jenkins, pois será o local onde o pipeline irá obter os artefatos para publicação.o Ex: “Cadorg_DSV”


contém os arquivos que serão publicados no servidor web de homologação. configPath -> Deve ser preenchida com o diretório do arquivo de configuração.


configName -> Deve ser preenchida com o nome do arquivo de configuração. o Ex: “global.asa”



4.4.1.5. Produção

Figura 10 - Pipeline de Produção - ASP

Informar Número do Deploy – É apresentada uma lista contendo os últimos deploys, que ocorreram

com sucesso no ambiente de homologação, para que seja selecionado o que deve ser colocado em produção.

Copiar artefatos de Homologação – Os artefatos gerados no deploy selecionado no primeiro passo são copiados de homologação para o workspace do Jenkins de produção.

Deploy em Produção – São copiados os artefatos do workspace de produção (gerados no deploy em homologação) e colados no servidor web do ambiente de produção.

Arquivar Artefatos – Os artefatos publicados no servidor web de produção são arquivados nas pastas do workspace do Jenkins de produção. Este passo se faz necessário para posteriormente, ao

publicar outras versões do software em produção, seja possível realizar o rollback para uma versão estável. É importante ressaltar que serão armazenados somente os últimos 5 deploys. Não é

necessário armazenar os artefatos que apresentaram erros. Para isso, informar o parâmetro “onlyIfSuccessful:true”.

Enviar e-mail Final Processo – Ao finalizar o processo de publicação em produção, um e-mail é enviado, aos envolvidos no projeto, informando que a publicação foi finalizada com sucesso.

Enviar E-mail Falha – Em caso de erros em qualquer passo do fluxo, um e-mail informando que o software não foi publicado é enviado aos envolvidos no projeto. Neste e-mail, é anexado o log

contendo os erros. Os destinatários serão configurados conforme descrito no item configurações gerais.



4.4.1.6. Configurações Produção

Nas configurações do pipeline de produção, na aba general, a opção “este projeto é parametrizado” deve ser marcada e configurada da seguinte forma:

Tipo: Run Parameter Name: homologBuildNumber

Project: nome do pipeline de homologação referente ao projeto. Filter: Marcar a opção somente builds que tiveram sucesso.

Para facilitar a utilização e configuração do JenkinsFile de produção, foram criadas variáveis no início do

arquivo que devem ser configuradas conforme descrito a seguir:

grupoEmail -> Deve ser preenchida seguindo o padrão “email_projeto_prod” que apontará para uma variável de ambiente do Jenkins, conforme descrito anteriormente. Ex:

o Ex: “grupoEmail = email_Cadorg_prod”

prodIISProjectFolder -> Deve ser preenchida com o caminho da pasta criada no servidor web de produção, para realizar o deploy da aplicação.

o Ex: “\\\\servidorProducao\\Sistemas\\SisAcre\\Principal\\Cadastro_Organismo”

projectName -> Deve ser preenchida com o nome do projeto o Ex: “Cadorg”

jenkinsHomologPipelineName -> Deve ser preenchida com o nome do pipeline de homologação

configurado no Jenkins, pois será o local onde o pipeline irá obter os artefatos para publicação.o Ex: “Cadorg_HML”


contém os arquivos que serão publicados no servidor web de produção. configPath -> Deve ser preenchida com o diretório do arquivo de configuração.


configName -> Deve ser preenchida com o nome do arquivo de configuração. o Ex: “global.asa”

4.5. Observações Importantes

Para que não ocorram problemas na publicação nos servidores web, toda vez que os artefatos forem copiados, é necessário realizar os seguintes passos:

Remover todas as conexões do usuário com a pasta de rede do servidor web usando o comando

o net use CAMINHO USUARIO /delete



Conectar à pasta de rede do servidor web. Para maior segurança, o usuário e a senha estarão

configurados nas credentials do Jenkins.o net use CAMINHO /u: USUARIO SENHA

Criar o arquivo app_offline.htm para desligar o ApplicationPool e poder copiar os arquivos sem

ocorrência de erros por arquivos sendo usados (passo necessário apenas em soluções .NET). Aguardar 15 segundos para garantir que o ApplicationPool estará desligado (passo necessário apenas

em soluções .NET). Copiar os arquivos utilizando o comando robocopy e garantir que todos os arquivos anteriores serão

apagados. Dessa forma, o ApplicationPool não encontrará o arquivo app_offline.htm e iniciará novamente.

Remover novamente as conexões do usuário com a pasta remota, utilizando o comando:o net use CAMINHO USUARIO /delete

4.6. Rollback

Caso o fluxo automatizado da entrega contínua apresente problemas no momento do deploy, dependendo do passo que o erro ocorreu, algumas medidas deverão ser executadas, de forma manual, a fim de restaurar o

estado anterior do ambiente.É importante ressaltar que após realizado um deploy de uma versão de software (Build do Jenkins), nenhuma

versão antiga pode ser executada via ferramenta Jenkins. Isso pode gerar problemas na base de dados, visto que o framework de migrations terá executado mudanças em base de dados que não foram realizadas em versões

anteriores. Mesmo em projetos que não utilizam o framework de migrations decidiu-se por manter essa restrição para que exista uma padronização de procedimento e configuração da ferramenta Jenkins.

Para realizar o rollback de forma manual, é importante observar em qual passo do fluxo o erro ocorreu.Para erros que ocorreram em passos anteriores aos que alteram banco de dados ou arquivos do servidor

web (“deploy” ou “atualizar banco de dados”), não há necessidade de restaurar nada no ambiente.Para os outros passos, deve-se seguir os seguintes procedimentos:

Deploy (em desenvolvimento, homologação ou produção) – Neste passo, os arquivos localizados no servidor web, podem ter sido apagados e/ou modificados. Portanto, basta copiar os arquivos

contidos na última publicação realizada com sucesso no determinado ambiente.o Deve-se acessar a ferramenta Jenkins e verificar qual o número do último build publicado

com sucesso no ambiente.

o Após essa verificação, deve-se acessar a pasta do workspace do Jenkins referente ao projeto

e acessar as subpastas -> builds -> “número observado no passo anterior” -> archive -> “demais subpastas até encontrar o conteúdo a ser publicado no servidor web”.

o Copiar o conteúdo da pasta supracitada e colar no servidor desejado.



É importante ressaltar que o ambiente deve ser rigorosamente observado. Caso contrário, builds de

desenvolvimento, por exemplo, poderiam ser publicados por engano em produção.

Atualizar Banco de Dados – Caso o erro ocorra nesse passo, além de executar o passo anterior (rollback do deploy) deve-se observar:

o Caso o DBA tenha realizado o backup da base, é aconselhável restaurá-lo. Dessa forma,

existe a garantia que nada será perdido.o Caso exista a possibilidade de algum usuário ter utilizado a aplicação entre o tempo que a

aplicação foi publicada e o momento do rollback, é interessante que não se realize rollback,

mas sim, que seja realizada uma correção do software, gerando uma nova versão e um novo deploy.

o Caso contrário deve-se consultar na base de dados a tabela de controle de versão

(versionInfo), criada pelo framework de migrations, para verificar qual versão estava implementada no banco de dados antes dessa execução. Caso alguma mudança tenha

ocorrido, o framework de migrations deve ser executado manualmente, via linha de comando, utilizando a opção down --target e informando para qual versão o banco deve ser

restaurado. dotnet-fm migrate --processor "tipoBancoDeDados" --tag AMBIENTE --connection

"connectionString" --assembly "migrationsDLL" down --target VERSAO, onde: tipoBancoDeDados - é a versão do banco de dados, conforme descrito em

https://fluentmigrator.github.io/articles/multi-db-support.htmlo Ex: “SQLServer2008”

AMBIENTE – é a tag do ambiente que será feito o rollback. Desenv, Teste,

Homolog ou Prod connectionString – é a string de conexão contendo usuário e senha com

permissão para executar o rollback. migrationsDll – é a dll do projeto de migrations contida na versão que

apresentou erros ao ser executada. VERSAO – é o número da versão inferior à que se deseja realizar o rollback.

(o rollback não remove a versão informada).


Documents

Objetivo · Web view, as entregas tornaram-se mais rápidas e menores, permitindo que o trabalho seja executado em paralelo pelos membros da equipe. Com diversas alterações sendo