Jenkins - The Definitive Guide-Páginas-8

Machine Translated by Google
Figura 9.16. Configurar o plugin Task Scanner é simples
O botão Avançado dá acesso a algumas opções mais sofisticadas. Provavelmente os mais úteis são os
limites de Saúde, que permitem definir o número máximo de problemas tolerados antes que a construção
não possa mais ser considerada “ensolarada” e o número mínimo de problemas necessários para o status
de “tempo tempestuoso”.
O plugin gera um gráfico que mostra tendências de tags por prioridade (veja Figura 9.17, “O gráfico de tendências de tarefas
abertas”). Se você clicar no relatório Tarefas Abertas, também poderá ver um detalhamento das tarefas por módulo, pacote ou
arquivo do Maven, ou até mesmo listar as tarefas abertas.
Figura 9.17. O gráfico de tendência de tarefas abertas
250
www.dbooks.org
9.8. Integrando com Sonar

Sonar4 é uma ferramenta que centraliza uma série de métricas de qualidade de código em um único site (consulte a
Figura 9.18, “Relatórios de qualidade de código pelo Sonar”). Ele usa vários plug-ins Maven (Checkstyle, PMD,
FindBugs, Cobertura ou Clover e outros) para analisar projetos Maven e gerar um conjunto abrangente de relatórios
de métricas de qualidade de código. O Sonar informa sobre cobertura de código, conformidade de regras e
documentação, mas também sobre métricas de mais alto nível, como complexidade, capacidade de manutenção e
até dívida técnica. Você pode usar plug-ins para estender seus recursos e adicionar suporte para outras linguagens
(como suporte para CodeNarc para código-fonte Groovy). As regras utilizadas pelas diversas ferramentas são
gerenciadas e configuradas centralmente no site do Sonar, e os projetos Maven em análise não requerem nenhuma
configuração específica. Isso torna o Sonar uma ótima opção para trabalhar em projetos Maven onde você tem controle limitado sobre os
Figura 9.18. Relatórios de qualidade de código do Sonar
Em um dos usos mais comuns do Sonar, o Sonar executa automaticamente um conjunto de plug-ins relacionados à qualidade
do código Maven em seu projeto Maven e armazena os resultados em um banco de dados relacional. O servidor Sonar, que
você executa separadamente, analisa e exibe os resultados conforme mostrado na Figura 9.18, “Relatórios de qualidade de
código pelo Sonar”.
Jenkins integra-se bem com Sonar. O plug-in Jenkins Sonar permite definir instâncias do Sonar para todos os seus projetos e,
em seguida, ativar o Sonar em compilações específicas. Você pode executar seu servidor Sonar em um local diferente
4
http://www.sonarsource.org
251
machine para sua instância do Jenkins ou na mesma. A única restrição é que a instância Jenkins deve ter
acesso JDBC ao banco de dados Sonar, pois injeta métricas de qualidade de código diretamente no banco
de dados, sem passar pelo site do Sonar (consulte a Figura 9.19, “Jenkins e Sonar”).
Jenkins Banco de dados de sonar
Figura 9.19. Jenkins e Sonar
O Sonar também possui um bootstrap Ant (com um bootstrap Gradle em desenvolvimento no momento em que este artigo foi escrito) para não-
Usuários experientes.
Você instala o plugin da maneira usual, através do Plugin Manager. Depois de instalado, você configura o
plugin Jenkins Sonar na tela Configurar Sistema, na seção Sonar. Isso envolve definir suas instâncias do
Sonar – você pode configurar quantas instâncias do Sonar precisar. A configuração padrão pressupõe que
você esteja executando uma instância local do Sonar com o banco de dados incorporado padrão. Isso é útil
para fins de teste, mas não é muito escalonável. Para um ambiente de produção, você normalmente executará
o Sonar em um banco de dados real, como MySQL ou Postgres, e precisará configurar a conexão JDBC com
o banco de dados de produção do Sonar no Jenkins. Você faz isso clicando no botão Avançado e preenchendo
os campos apropriados (veja a Figura 9.20, “Configurando o Sonar no Jenkins”).
252
www.dbooks.org
Figura 9.20. Configurando Sonar no Jenkins
A outra coisa que você precisa configurar é quando a construção do Sonar será iniciada em um trabalho de construção habilitado para Sonar.
Normalmente, você configura o Sonar para ser executado com um dos trabalhos de construção de longa duração do Jenkins, como a
construção de métricas de qualidade de código. Não é muito útil executar a compilação do Sonar mais de uma vez por dia, pois o Sonar
armazena métricas em fatias de 24 horas. A configuração padrão iniciará um build do Sonar em um trabalho de build habilitado para Sonar
sempre que o trabalho for acionado por um build agendado periodicamente ou por um build manual.
Para ativar o Sonar em seu trabalho de construção com as opções de configuração de todo o sistema, basta marcar a opção Sonar nas
Ações Pós-compilação (veja Figura 9.21, “Configurando o Sonar em um trabalho de construção”). O Sonar será executado sempre que sua
compilação for iniciada por um dos mecanismos de gatilho definidos acima.
253
Figura 9.21. Configurando o Sonar em um trabalho de build
Normalmente, você configura o Sonar para funcionar regularmente, por exemplo, todas as noites ou uma vez por semana. Portanto,
você pode ativar o Sonar em seu trabalho normal de construção de teste de unidade/integração, simplesmente adicionando um
agendamento (consulte a Figura 9.22, “Agendando compilações do Sonar”). Isso evita detalhes de configuração duplicados entre
trabalhos. Ou, se você já tiver um trabalho de build agendado que seja executado com uma frequência apropriada (como um build de
métricas de qualidade de código dedicado), poderá ativar o Sonar nesse trabalho de build.
Figura 9.22. Agendamento de compilações do Sonar
Se você clicar no botão Avançado, poderá especificar outras opções mais sofisticadas, como executar a compilação do Sonar em
uma ramificação separada, passar opções de linha de comando adicionais ao Maven (como memória extra) ou substituir a configuração
padrão do gatilho.
Por padrão, o Sonar será executado mesmo se a compilação normal falhar. Geralmente é isso que você deseja, pois o Sonar deve
registrar falhas de construção e teste, bem como resultados bem-sucedidos. No entanto, se necessário, você também pode desativar
esta opção nas opções avançadas.
254
www.dbooks.org
9.9. Conclusão
A qualidade do código é uma parte importante do processo de construção, e Jenkins fornece excelente suporte para uma ampla variedade
de ferramentas relacionadas à qualidade de código que existem. Como resultado, Jenkins deve ser uma parte fundamental da sua estratégia
de qualidade de código.
255
www.dbooks.org
Capítulo 10. Construções Avançadas

10.1. Introdução
Neste capítulo, veremos algumas configurações de trabalho de construção mais avançadas. Discutiremos compilações
parametrizadas, que permitem que Jenkins solicite ao usuário parâmetros adicionais que serão passados para o trabalho de
construção, e trabalhos de construção multiconfiguração, que permitem executar um único trabalho de construção através de um
grande número de variações. Veremos como executar trabalhos de construção em paralelo e aguardaremos o resultado de um ou
mais trabalhos de construção antes de continuar. E veremos como implementar estratégias de promoção de construção e construir
pipelines para que o Jenkins possa ser usado não apenas como um servidor de construção, mas também como um servidor de implantação.
10.2. Jobs de compilação parametrizados
Construções parametrizadas são um conceito poderoso que permite adicionar outra dimensão aos seus trabalhos de construção.
O plug-in Parameterized Build permite configurar parâmetros para seu trabalho de construção, que podem ser inseridos pelo
usuário quando o trabalho de construção é acionado ou (como veremos mais tarde) de outro trabalho de construção.
Por exemplo, você pode ter um trabalho de construção de implantação, onde deseja escolher o ambiente de destino em uma lista
suspensa ao iniciar o trabalho de construção. Ou você pode especificar a versão do aplicativo que deseja implantar. Ou, ao
executar um trabalho de construção envolvendo testes da web, você pode querer especificar o navegador no qual executar seus
testes Selenium ou WebDriver. Você pode até fazer upload de um arquivo para ser usado pelo trabalho de construção.
Observe que é função do script de construção analisar e processar os valores dos parâmetros corretamente – Jenkins simplesmente
fornece uma interface de usuário para os usuários inserirem valores para os parâmetros e passar esses parâmetros para o script
de construção.
10.2.1. Criando um trabalho de construção parametrizado
Você instala o plugin Parameterized Build normalmente, através da tela Plugin Manager. Depois de fazer isso, configurar um
trabalho de construção parametrizado será simples. Basta marcar a opção “Esta compilação está parametrizada” e clicar em
Adicionar Parâmetro para adicionar um novo parâmetro de trabalho de construção (veja Figura 10.1, “Criando um trabalho de
construção parametrizado”). Você pode adicionar parâmetros a qualquer tipo de construção e adicionar quantos parâmetros desejar
para um determinado trabalho de construção.
Figura 10.1. Criando um job de build parametrizado
Para adicionar um parâmetro ao seu trabalho de construção, basta escolher o tipo de parâmetro na lista suspensa. Isso permitirá que você
configure os detalhes do seu parâmetro (veja Figura 10.2, “Adicionando um parâmetro ao trabalho de construção”).
Você pode escolher entre vários tipos de parâmetros diferentes, como Strings, Booleanos e listas suspensas.
Dependendo do tipo escolhido, você terá que inserir valores de configuração ligeiramente diferentes, mas o processo básico é idêntico.
Todos os tipos de parâmetros, com exceção do parâmetro Arquivo, possuem um nome e uma descrição e, na maioria das vezes, um valor
padrão.
Na Figura 10.3, “Adicionando um parâmetro ao trabalho de construção”, por exemplo, estamos adicionando um parâmetro chamado versão
a um trabalho de construção de implantação. O valor padrão (RELEASE) será exibido inicialmente quando o Jenkins solicitar esse parâmetro
ao usuário, portanto, se o usuário não alterar nada, esse valor será usado.
Figura 10.2. Adicionando um parâmetro ao trabalho de construção
Quando o usuário inicia um trabalho de construção parametrizado (trabalhos de construção parametrizados muitas vezes são iniciados
manualmente), Jenkins irá propor uma página onde o usuário pode inserir valores para cada um dos parâmetros do trabalho de construção
(veja Figura 10.3, “Adicionando um parâmetro ao trabalho de construção ”).
258
www.dbooks.org
Figura 10.3. Adicionando um parâmetro ao trabalho de construção
10.2.2. Adaptando suas compilações para funcionar com scripts de compilação

parametrizados
Depois de adicionar um parâmetro, você precisa configurar seus scripts de construção para usá-lo. Escolher bem o nome do parâmetro é
importante aqui, pois esse também é o nome da variável que o Jenkins passará como variável de ambiente ao executar o trabalho de
construção. Para ilustrar isso, considere a configuração básica do trabalho de construção na Figura 10.4, “Demonstrando um parâmetro de
construção”, onde estamos simplesmente repetindo o parâmetro de construção de volta para o console. Observe que, para tornar as
variáveis de ambiente mais portáveis entre sistemas operacionais, é uma boa prática colocá-las todas em letras maiúsculas.
Figura 10.4. Demonstrando um parâmetro de construção
Quando executamos isso, obtemos uma saída do console com as seguintes linhas:
Iniciado pelo usuário anônimo Com

base no mestre [espaço de
trabalho] $ /bin/sh -xe /var/folders/y+/y+a+wZ-jG6WKHEm9KwnSvE+++TI/-Tmp-/ jenkins5862957776458050998.sh +
echo Versão=1.2.3
Versão=1.2.3
Notificando projetos upstream sobre a conclusão do trabalho
Concluído: SUCESSO
Você também pode usar essas variáveis de ambiente em seus scripts de construção. Por exemplo, em uma construção Ant ou Maven, você
pode usar a propriedade especial env para acessar as variáveis de ambiente atuais:
<target name="printversion">
<property ambiente="env" /> <echo
mensagem="${env.VERSION}"/> </target>
259
Outra opção é passar o parâmetro para o script de construção como um valor de propriedade. A seguir está um
exemplo mais complexo de um arquivo Maven POM. Neste exemplo, o Maven está configurado para implantar um
arquivo WAR específico. Fornecemos a versão do arquivo WAR a ser implantada na propriedade target.version ,
que é utilizada na declaração de dependência, conforme mostrado abaixo:
...
<dependencies>
<dependency>
<groupId>com.wakaleo.gameoflife</groupId>
<artifactId>gameoflife-web</artifactId> <type>war</
type> <version>$
{target.version}</version>
</dependency> </
dependencies>
<properties>
<target.version>RELEASE</target.version>
...
</propriedades>
Quando invocamos o Maven, passamos o parâmetro como uma das propriedades de construção (veja Figura 10.5,
“Adicionando um parâmetro a um trabalho de construção do Maven”). Podemos então usar uma ferramenta como
Cargo para fazer a implantação real – o Maven baixará a versão solicitada do arquivo WAR do Enterprise Repository
Manager local e a implantará em um servidor de aplicativos.
Figura 10.5. Adicionando um parâmetro a um trabalho de construção do Maven
Resumindo, é assim que você pode integrar parâmetros de trabalho de construção em sua construção. Além dos
antigos parâmetros String, no entanto, existem alguns tipos de parâmetros mais sofisticados, que veremos nos
parágrafos seguintes (veja a Figura 10.6, “Muitos tipos diferentes de parâmetros estão disponíveis”).
260
www.dbooks.org
Figura 10.6. Muitos tipos diferentes de parâmetros estão disponíveis
10.2.3. Tipos de parâmetros mais avançados

Os parâmetros de senha são, como seria de esperar, muito semelhantes aos parâmetros de String, exceto pelo fato de serem exibidos
como um campo de senha.
Há muitos casos em que você deseja apresentar um conjunto limitado de opções de parâmetros. Em uma compilação de implantação,
talvez você queira permitir que o usuário escolha um dentre vários servidores de destino. Ou você pode apresentar uma lista de
navegadores suportados para um conjunto de testes de aceitação. Os parâmetros de escolha permitem definir um conjunto de valores que
serão exibidos como uma lista suspensa (veja Figura 10.7, “Configurando um parâmetro de escolha”).
Você precisa fornecer uma lista de valores possíveis, um por linha, começando com o valor padrão.
Figura 10.7. Configurando um parâmetro Choice
Parâmetros booleanos são, como seria de esperar, parâmetros que assumem um valor verdadeiro ou falso. Eles são apresentados como
caixas de seleção.
Dois tipos de parâmetros mais exóticos, que se comportam de maneira um pouco diferente dos outros, são parâmetros de execução e
parâmetros de arquivo.
Os parâmetros de execução permitem selecionar uma execução (ou construção) específica de um determinado trabalho de construção
(consulte a Figura 10.8, “Configurando um parâmetro de execução”). O usuário escolhe em uma lista de números de execução de build. A
URL da execução de build correspondente é armazenada no parâmetro especificado.
261
Figura 10.8. Configurando um parâmetro Run
A URL (que será semelhante a http://jenkins.myorg.com/job/game-of-life/197/) pode ser usada para obter informações ou
artefatos dessa execução de compilação. Por exemplo, você poderia obter o arquivo JAR ou WAR arquivado em uma
construção anterior e executar testes adicionais com esse binário específico em uma tarefa de construção separada.
Por exemplo, para acessar o arquivo WAR de uma compilação anterior em um projeto Maven multimódulo, a URL seria mais
ou menos assim:
http://buildserver/job/game-of-life/197/artifact/gameoflife-web/target/
gameoflife.war
Assim, utilizando o parâmetro configurado na Figura 10.8, “Configurando um parâmetro Run”, você poderia acessar este
arquivo WAR utilizando a seguinte expressão:
${RELEASE_BUILD}gameoflife-web/target/gameoflife.war
Os parâmetros de arquivo permitem que você carregue um arquivo no espaço de trabalho do trabalho de construção, para que
ele possa ser usado pelo script de construção (consulte a Figura 10.9, “Configurando um parâmetro de arquivo”). Jenkins
armazenará o arquivo no local especificado na área de trabalho do projeto, onde você poderá acessá-lo em seus scripts de
construção. Você pode usar a variável WORKSPACE para se referir ao diretório atual do espaço de trabalho do Jenkins, para
poder manipular o arquivo carregado na Figura 10.9, “Configurando um parâmetro de arquivo” usando a expressão $
{WORKSPACE}/deploy/app.war.
Figura 10.9. Configurando um parâmetro de arquivo
10.2.4. Construindo a partir de uma tag Subversion
O gatilho parametrizado tem suporte especial para Subversion, permitindo que você construa em uma tag específica do
Subversion. Isso é útil se você deseja executar uma versão de lançamento usando uma tag gerada por uma versão anterior
262
www.dbooks.org
trabalho. Por exemplo, um trabalho de compilação upstream pode marcar uma revisão específica. Alternativamente, você pode usar o
processo de lançamento padrão do Maven (consulte a Seção 10.7.1, “Gerenciando versões do Maven com o plug-in M2Release”) para
gerar uma nova versão. Neste caso, uma tag com o número da versão do Maven será gerada automaticamente no Subversion.
Essa abordagem é útil para projetos que precisam ser reconstruídos parcial ou totalmente antes de serem implantados em uma
determinada plataforma. Por exemplo, pode ser necessário executar a construção Ant ou Maven usando propriedades ou perfis
diferentes para plataformas diferentes, para que os arquivos de configuração específicos da plataforma possam ser integrados nos
arquivos WAR ou EAR implementados.
Você pode configurar uma compilação do Jenkins para ser executada em uma tag selecionada usando o tipo de parâmetro “List
Subversion Tag” (veja Figura 10.10, “Adicionando um parâmetro para compilar a partir de uma tag do Subversion”). Você só precisa
fornecer a URL do repositório Subversion apontando para o diretório tags do seu projeto.
Figura 10.10. Adicionando um parâmetro para construir a partir de uma tag Subversion
Ao executar esta compilação, Jenkins proporá uma lista de tags para você escolher (veja a Figura 10.11, “Construindo a partir de uma
tag Subversion”).
Figura 10.11. Construindo a partir de uma tag Subversion
10.2.5. Construindo a partir de uma tag Git
Construir a partir de uma tag Git não é tão simples quanto fazê-lo a partir de uma tag Subversion, embora você ainda possa usar um
parâmetro para indicar qual tag usar. Na verdade, devido à própria natureza do Git, quando Jenkins obtém uma cópia do código-fonte
do Git, ele clona o repositório Git, incluindo todas as tags. Depois de ter a versão mais recente do repositório em seu servidor Jenkins,
você poderá prosseguir para fazer o checkout de uma versão marcada usando git checkout <tagname>.
263
Para configurar isso no Jenkins, primeiro você precisa adicionar um parâmetro String ao seu trabalho de construção (chamado RELEASE
neste exemplo – consulte a Figura 10.12, “Configurando um parâmetro para uma tag Git”). Ao contrário do suporte ao Subversion, não
há como listar as tags Git disponíveis em uma lista suspensa, então os usuários precisarão saber o nome da tag que desejam lançar.
Figura 10.12. Configurando um parâmetro para uma tag Git
Depois de adicionar este parâmetro, você precisa fazer check-out da tag correspondente assim que o repositório for clonado localmente.
Portanto, se você tiver uma compilação de estilo livre, a primeira etapa de compilação seria uma chamada de linha de comando para o
Git para verificar a tag referenciada pelo parâmetro RELEASE (consulte a Figura 10.13, “Construindo a partir de uma tag do Git”). É
claro que uma maneira mais portátil de fazer isso seria escrever um script Ant ou Groovy simples para fazer a mesma coisa de uma
forma mais neutra em termos de sistema operacional.
Figura 10.13. Construindo a partir de uma tag Git
10.2.6. Iniciando um trabalho de compilação parametrizado remotamente
Você também pode iniciar um trabalho de construção parametrizado remotamente, invocando a URL do trabalho de construção. A forma
típica de um URL de trabalho de construção parametrizado é ilustrada aqui:
264
www.dbooks.org
http://jenkins.acme.org/job/myjob/buildWithParameters?PARAMETER=Value
Portanto, no exemplo mostrado acima, você poderia acionar uma compilação como esta:
http://jenkins.acme.org/job/parameterized-build/buildWithParameters?VERSION=1.2.3
Ao usar uma URL para iniciar um trabalho de construção dessa forma, lembre-se de que os nomes dos parâmetros diferenciam
maiúsculas de minúsculas e que os valores precisam ter escape (assim como qualquer outro parâmetro HTTP). E se você estiver
usando um parâmetro Run, precisará fornecer o nome do trabalho de construção e o número da execução (por exemplo, game-of-
life#197) e não apenas o número da execução.
10.2.7. Histórico de trabalho de construção parametrizado
Por fim, é indispensável saber quais parâmetros foram utilizados para executar uma determinada compilação parametrizada.
Por exemplo, em um trabalho de criação de implantação automatizada, é útil saber exatamente qual versão foi realmente implantada.
Felizmente, o Jenkins armazena esses valores no histórico de construção (veja a Figura 10.14, “Jenkins armazena quais valores de
parâmetros foram usados para cada construção”), então você sempre pode voltar e dar uma olhada.
Figura 10.14. Jenkins armazena quais valores de parâmetros foram usados para cada construção
10.3. Gatilhos parametrizados

Quando você aciona outro trabalho de construção de dentro de um trabalho de construção parametrizado, geralmente é útil poder
passar os parâmetros do trabalho de construção atual para o novo. Suponha, por exemplo, que você tenha um aplicativo que precisa
ser testado em vários bancos de dados diferentes. Como vimos, você poderia fazer isso configurando um trabalho de construção
parametrizado que aceita o banco de dados de destino como parâmetro. Você pode querer iniciar uma série de compilações, todas as
quais precisarão deste parâmetro.
Se você tentar fazer isso usando a opção convencional “Construir outros projetos” na seção Ações pós-construção, não funcionará. Na
verdade, você não pode acionar uma compilação parametrizada dessa maneira.
No entanto, você pode fazer isso usando o plugin Jenkins Parameterized Trigger. Este plug-in permite que você configure seus
trabalhos de construção para acionar compilações parametrizadas e para passar parâmetros arbitrários para essas compilações.
265
Depois de instalar este plugin, você encontrará a opção “Acionando compilações parametrizadas em outros projetos” na página de
configuração do seu trabalho de construção (veja Figura 10.16, “Adicionando um gatilho parametrizado a um trabalho de construção”). Isso
permite iniciar outro trabalho de construção de diversas maneiras. Em particular, permite iniciar um trabalho de construção subsequente,
passando os parâmetros atuais para este novo trabalho de construção, o que é impossível de fazer com uma construção acionada normal.
A melhor maneira de ver como isso funciona é através de um exemplo.
Na Figura 10.15, “Jenkins armazena quais valores de parâmetros foram usados para cada construção”, temos um trabalho de construção
inicial. Este trabalho de construção utiliza um único parâmetro, DATABASE, que especifica o banco de dados a ser usado para os testes.
Como vimos, o usuário será solicitado a inserir esse valor sempre que a compilação for iniciada.
Figura 10.15. Jenkins armazena quais valores de parâmetros foram usados para cada construção
Agora, suponha que queiramos acionar um segundo trabalho de construção para executar testes de integração mais abrangentes assim
que o primeiro trabalho de construção for concluído. No entanto, precisamos dele para executar os testes no mesmo banco de dados.
Podemos fazer isso configurando um gatilho parametrizado para iniciar este segundo trabalho de construção (veja Figura 10.16,
“Adicionando um gatilho parametrizado a um trabalho de construção”).
Figura 10.16. Adicionando um gatilho parametrizado a um trabalho de build
266
www.dbooks.org
Nesse caso, estamos simplesmente passando pelos parâmetros de construção atuais. Este segundo trabalho de construção será iniciado
automaticamente após o primeiro, com o valor do parâmetro DATABASE fornecido pelo usuário.
Você também pode ajustar a política de acionamento informando ao Jenkins quando a compilação deve ser acionada.
Normalmente, você só acionaria uma compilação downstream depois que sua compilação fosse concluída com êxito, mas com o plug-in Parameterized
Trigger você também pode configurar compilações para serem acionadas mesmo se a compilação for instável, somente quando a compilação falhar ou
solicitar que ela seja acionada não não importa qual seja o resultado da primeira construção. Você pode até configurar vários gatilhos para o mesmo
trabalho de construção.
Naturalmente, o trabalho de construção que você aciona deve ser um trabalho de construção parametrizado (conforme ilustrado na Figura 10.17, “O
trabalho de construção que você aciona também deve ser um trabalho de construção parametrizado”) e você deve passar por todos os parâmetros
necessários.
Figura 10.17. O trabalho de construção que você aciona também deve ser um trabalho de construção parametrizado
Na verdade, esse recurso tem aplicações muito mais amplas do que simplesmente passar pelos parâmetros de construção atuais. Você também pode
acionar um trabalho de build parametrizado com um conjunto arbitrário de parâmetros ou usar uma combinação de parâmetros que foram passados
para o build atual e seus próprios parâmetros adicionais. Ou, se você tiver muitos parâmetros, poderá carregá-los de um arquivo de propriedades. Na
Figura 10.18, “Passando um parâmetro predefinido para um trabalho de construção parametrizado”, estamos passando os parâmetros de construção
atuais (a variável DATABASE neste caso) e um parâmetro adicional chamado TARGET_PLATFORM.
267
Figura 10.18. Passando um parâmetro predefinido para um trabalho de construção parametrizado
10.4. Trabalhos de compilação multiconfiguração
Os trabalhos de construção multiconfiguração são um recurso extremamente poderoso do Jenkins. Um trabalho de construção
multiconfiguração pode ser pensado como um trabalho de construção parametrizado que pode ser executado automaticamente com
todas as combinações possíveis de parâmetros que pode aceitar. Eles são particularmente úteis para testes, onde você pode testar
seu aplicativo usando um único trabalho de construção, mas sob uma ampla variedade de condições (navegadores, bancos de dados
e assim por diante).
10.4.1. Configurando uma compilação multiconfiguração
Para criar um novo trabalho de construção multiconfiguração, basta escolher esta opção na página Novo Trabalho (veja Figura 10.19,
“Criando um trabalho de construção multiconfiguração”).
268
www.dbooks.org
Figura 10.19. Criando um trabalho de build multiconfiguração
Um trabalho de construção multiconfiguração é como qualquer outro trabalho de construção, mas com um elemento adicional
muito importante: a Matriz de Configuração (veja Figura 10.20, “Adicionando um eixo a uma construção multiconfiguração”).
É aqui que você define as diferentes configurações que serão usadas para executar suas compilações.
Figura 10.20. Adicionando um eixo a uma construção multiconfiguração
Você pode definir diferentes eixos de opções de configuração, incluindo executar o trabalho de construção em escravos diferentes
ou em JDKs diferentes, ou fornecer suas próprias propriedades personalizadas para a construção. Por exemplo, nos trabalhos de
construção discutidos anteriormente, podemos querer testar nosso aplicativo em diferentes bancos de dados e diferentes sistemas
operacionais. Poderíamos definir um eixo definindo máquinas escravas com diferentes sistemas operacionais nos quais queríamos
que nossa construção fosse executada, e outro eixo definindo todos os valores possíveis do banco de dados. Jenkins executará
então o trabalho de construção para cada banco de dados possível e cada sistema operacional possível.
Vejamos os tipos de eixo que você pode definir.
10.4.2. Configurando um eixo escravo
A primeira opção é configurar sua compilação para rodar simultaneamente em diferentes máquinas escravas (veja Capítulo 11,
Construções Distribuídas). Agora, é claro, a ideia de ter um conjunto de máquinas escravas geralmente é que você possa executar
seu trabalho de construção em qualquer uma delas. Mas há casos em que faz sentido ser um pouco mais exigente. Por exemplo,
você pode querer que seus testes sejam executados no Windows, Mac OS X e Linux. Nesse caso,
269
você cria um novo eixo para seus nós escravos, conforme mostrado na Figura 10.21, “Definindo um eixo de nós escravos”.
Você pode escolher os nós que deseja usar de duas maneiras: por rótulo ou por nó individual. O uso de rótulos permite
identificar categorias de nós de build (por exemplo, máquinas Windows), sem vincular o build a nenhuma máquina. Esta é
uma opção mais flexível e facilita a expansão da sua capacidade de construção conforme necessário. Às vezes, porém,
você pode realmente querer executar uma compilação em uma máquina específica. Neste caso, você pode usar a opção
“Nós individuais” e escolher a máquina nesta lista.
Figura 10.21. Definindo um eixo de nós escravos
Se precisar de mais flexibilidade, você também pode usar uma Expressão de Rótulo, que permite definir quais nós escravos
devem ser usados para construções em um eixo específico usando expressões booleanas e operadores lógicos para
combinar rótulos. Por exemplo, suponha que você tenha definido rótulos para máquinas escravas com base no sistema
operacional (“windows”, “linux”) e bancos de dados instalados (“oracle”, “mysql”, “db2”). Para definir um eixo executando
testes apenas em máquinas Windows instaladas com MySQL, você poderia usar uma expressão como windows && mysql.
Discutiremos o trabalho com nós escravos e construções distribuídas com mais detalhes no Capítulo 11, Construções
Distribuídas.
10.4.3. Configurando um eixo JDK
Se você estiver implantando seu aplicativo em uma ampla base de clientes onde tenha controle limitado sobre o ambiente
de destino, talvez seja necessário testar seu aplicativo usando diferentes versões de Java. Em casos como este, é útil
poder configurar um eixo JDK em uma construção multiconfiguração. Quando você adiciona um eixo JDK, o Jenkins
proporá automaticamente a lista de versões do JDK que ele conhece (veja Figura 10.22, “Definindo um eixo de versões do
JDK”). Se você precisar usar JDKs adicionais, basta adicioná-los à página de configuração do Jenkins.
Figura 10.22. Definindo um eixo de versões do JDK
270
www.dbooks.org
10.4.4. Eixo personalizado
O terceiro tipo de eixo permite definir diferentes maneiras de executar seu trabalho de construção, com base em variáveis
arbitrárias definidas por você. Por exemplo, você pode fornecer uma lista de bancos de dados que você precisa testar ou uma
lista de navegadores para usar em seus testes da web. Eles são como parâmetros para um trabalho de construção parametrizado,
exceto que você fornece a lista completa de valores possíveis e, em vez de solicitar que você insira um valor, o Jenkins executará
a construção com todos os valores fornecidos (Figura 10.23, “Definindo um eixo definido pelo usuário”).
Figura 10.23. Definindo um eixo definido pelo usuário
10.4.5. Executando uma compilação multiconfiguração
Depois de configurar os eixos, você poderá executar sua construção multiconfiguração como qualquer outra. No entanto, Jenkins
tratará cada combinação de variáveis como um trabalho de construção separado. Jenkins exibe os resultados agregados em
uma tabela, onde todas as combinações são mostradas (veja Figura 10.24, “Resultados da construção multiconfiguração”). Se
você clicar em qualquer uma das bolas, Jenkins o levará aos resultados detalhados daquela construção específica.
271
Figura 10.24. Resultados de compilação multiconfiguração
Por padrão, o Jenkins executará os trabalhos de construção em paralelo. No entanto, existem alguns casos em que isso não é
uma boa ideia. Por exemplo, muitos aplicativos da web Java usam testes Selenium ou WebDriver em execução em uma instância
local do Jetty que é iniciada automaticamente pelo trabalho de construção. Scripts de construção como este precisam ser
especialmente configurados para serem executados em paralelo na mesma máquina, para evitar conflitos de porta. O acesso
simultâneo ao banco de dados durante os testes pode ser outra fonte de problemas se a simultaneidade não for incluída nos
testes. Se suas compilações não forem projetadas para serem executadas em paralelo, você pode forçar o Jenkins a executar os
testes sequencialmente marcando a caixa de seleção Executar cada configuração sequencialmente na parte inferior da seção
Matriz de configuração.
Por padrão, o Jenkins executará todas as combinações possíveis dos diferentes eixos. Portanto, no exemplo acima, temos três
ambientes, dois JDKs e quatro bancos de dados. Isso resulta em um total de 24 compilações. No entanto, em alguns casos, pode
não fazer sentido (ou ser possível) executar determinadas combinações. Por exemplo, suponha que você tenha um trabalho de
build que execute testes web automatizados. Se um eixo contém os navegadores a serem testados (Firefox, Internet Explorer,
Chrome, etc.) e outro os sistemas operacionais (Linux, Windows, Mac OS), não faria sentido executar o Internet Explorer com
Linux ou Mac OS.
A opção Filtro de Combinação permite configurar regras sobre quais combinações de variáveis são válidas.
Este campo é uma expressão booleana Groovy que usa os nomes das variáveis definidas para cada eixo.
A expressão deve ser avaliada como verdadeira para que a construção seja executada. Por exemplo, suponha que você tenha um trabalho
de construção executando testes web em diferentes navegadores e diferentes sistemas operacionais (veja a Figura 10.25, “Configurando um
272
www.dbooks.org
filtro combinado”). Os testes precisam rodar Firefox, Internet Explorer e Chrome, em Windows, Mac OS X e Linux. No
entanto, o Internet Explorer só funciona no Windows e o Chrome não funciona no Linux.
Figura 10.25. Configurando um filtro combinado
Para configurar isso com um Filtro Combinado, poderíamos usar uma expressão como a seguinte:
(navegador=="firefox")
|| (navegador=="iexplorer" && os=="janelas") || (navegador = =
"chrome" && os! = "linux")
Isso resultaria na execução apenas das combinações corretas de navegador/sistema operacional (veja Figura 10.26,
“Construir resultados usando um filtro de combinação”). As compilações executadas são exibidas nas cores normais,
enquanto as compilações ignoradas são mostradas em cinza.
273
Figura 10.26. Crie resultados usando um filtro de combinação
Outro motivo para usar um filtro de construção é que existem muitas combinações válidas para serem executadas em um
tempo razoável. Nesse caso, a melhor solução pode ser fazer upgrade do seu servidor de compilação. A segunda melhor
solução, por outro lado, poderia ser executar apenas um subconjunto de combinações, possivelmente executando o conjunto
completo de combinações todas as noites. Você pode fazer isso usando a variável de índice especial . Se você incluir a
expressão (index%2 == 0), por exemplo, garantirá que apenas um trabalho de construção em dois seja realmente executado.
Você também pode querer que certas compilações sejam executadas antes das outras, como uma verificação de integridade.
Por exemplo, você pode querer executar primeiro a configuração padrão (e, teoricamente, a mais confiável) do seu aplicativo,
antes de prosseguir para combinações mais exóticas. Para fazer isso, você pode usar a opção “Execute touchstone builds
first”. Aqui, você insere um valor de filtro (como o visto acima) para definir a primeira ou mais construções a serem
executadas. Você também pode especificar se a compilação deve prosseguir somente se essas compilações forem bem-
sucedidas ou mesmo se não forem bem-sucedidas. Depois que essas compilações forem concluídas conforme esperado,
Jenkins prosseguirá com as outras combinações.
10.5. Gerando seus trabalhos de compilação Maven automaticamente
Contribuição de Evgeny Goldin
Conforme mencionado na seção anterior, o número de trabalhos de construção que seu servidor Jenkins hospedará pode
variar. À medida que o número de trabalhos de construção aumenta, fica mais difícil não apenas visualizá-los no painel do
Jenkins, mas também configurá-los. Imagine o que seria necessário para configurar de 20 a 50 trabalhos Jenkins, um por
um! Além disso, muitos desses trabalhos podem ter elementos de configuração comuns, como objetivos do Maven ou
configurações de memória de compilação, o que resulta em configuração duplicada e maior sobrecarga de manutenção.
274
www.dbooks.org
Por exemplo, se você decidir executar mvn clean install em vez de mvn clean deploy para seus trabalhos de lançamento e mudar
para métodos de implantação alternativos, como aqueles fornecidos pelo plugin Artifactory1 , você não terá escolha a não ser visitar
todos os trabalhos relevantes e atualizá-los manualmente.
Alternativamente, você pode aproveitar o fato de que Jenkins é uma ferramenta simples e direta que mantém todas as suas
definições em arquivos simples no disco. Na verdade, você pode atualizar os arquivos config.xml dos seus trabalhos diretamente
no diretório .jenkins/jobs onde eles são mantidos. Embora essa abordagem funcione, ainda está longe do ideal, pois envolve muita
seleção manual e substituições frágeis em arquivos XML do Jenkins.
Existe uma terceira maneira de alcançar o nirvana das atualizações massivas de trabalhos: gerar seus arquivos de configuração
automaticamente usando algum tipo de arquivo de definição. O plug-in Maven Jenkins2 faz exatamente isso, gerando arquivos
config.xml para todos os trabalhos usando definições padrão do Maven mantidas em um único arquivo pom.xml .
10.5.1. Configurando um Trabalho
Ao configurar um único trabalho com o plug-in Maven Jenkins, você pode definir todos os elementos usuais de configuração do
Jenkins, como objetivos do Maven, localização do POM, URLs do repositório, endereços de e-mail, número de dias para manter os
logs e assim por diante. O plugin tenta trazê-lo o mais próximo possível da maneira usual do Jenkins de configurar um trabalho
manualmente.
Vamos dar uma olhada no Google Guice3 construir trabalho:
<job>
<id>google-guice-trunk</id>
<description>Construindo o tronco do Google Guice.</description>
<descriptionTable> <row>
<key>Página do Projeto</key>
<value>
<a href="http://code.google.com/p/google-guice/">
<b><code>code.google.com/p/google-guice</code></b> </a> </value>
<escapeHTML>falso</escapeHTML>
<bottom>falso</bottom>
</linha>
</descriptionTable>
<jdkName>jdk1.6.0</jdkName>
<mavenName>apache-maven-3</mavenName>
<mavenOpts>-Xmx256m -XX:MaxPermSize=128m</mavenOpts>
<daysToKeep>5</daysToKeep> <
useUpdate>false</useUpdate>
<mavenGoals>-e instalação limpa</mavenGoals>
<trigger>
<type>temporizador</type>
1
http://wiki.jenkins-ci.org/display/JENKINS/Artifactory+Plugin
2
http://evgeny-goldin.com/wiki/Maven-jenkins-plugin
3
http://code.google.com/p/google- guia/
275
<expressão>0 0 * * *</expressão> </trigger>

<repositório>
<remote>http://google-guice.googlecode.com/svn/trunk/</remote> </repository> <mail>
<recipients>jenkins@evgeny-goldin.org</recipients>
</mail> </
job>
Este trabalho usa diversas configurações padrão, como <jdkName>, <mavenName> e <mavenOpts>. O código é
retirado de um repositório Subversion (definido no elemento <repository> ) e um cron <trigger> executa o trabalho todas
as noites às 00:00. Notificações por email são enviadas para pessoas especificadas com o elemento <mail> . Esta
configuração também adiciona um link para a página do projeto na tabela de descrição que é gerada automaticamente
para cada trabalho.
O trabalho gerado é exibido em seu servidor Jenkins conforme ilustrado na Figura 10.27, “Um trabalho gerado pelo
plugin Maven Jenkins”.
Figura 10.27. Um trabalho gerado pelo plugin Maven Jenkins
Aqui está outro trabalho de construção do branch master Jenkins no GitHub:
<job>
<id>jenkins-master</id>
<jdkName>jdk1.6.0</jdkName>
<numToKeep>5</numToKeep>
<trigger>
<type>temporizador </
type> <expressão>0 1 * * *</expressão>
</trigger>
<scmType>git</scmType>
<repositório>
<remote>git://github.com/jenkinsci/jenkins.git</remote>
276
www.dbooks.org
</repositório>
<mail>
<recipients>jenkins@evgeny-goldin.org</recipients> <sendForUnstable>falso</
sendForUnstable>
</mail>
</trabalho>
Isso geraria o trabalho mostrado na Figura 10.28, “trabalho jenkins-master gerado”.
Figura 10.28. trabalho jenkins-master gerado
A documentação do plugin4 fornece uma referência detalhada de todas as configurações que podem ser definidas.
10.5.2. Reutilizando a configuração do trabalho com herança
Ser capaz de gerar jobs Jenkins usando configuração centralizada, como Maven POM, resolve o problema de criação e
atualização de muitos jobs de uma vez. Tudo o que você precisa fazer agora é modificar as definições do trabalho,
executar novamente o plugin e carregar as definições atualizadas com Gerenciar Jenkins#“Recarregar configuração do
disco”. Essa abordagem também tem a vantagem de facilitar o armazenamento das configurações de trabalho no sistema
de controle de versão, o que, por sua vez, facilita o controle das alterações feitas nas configurações de compilação.
Mas ainda não resolvemos o problema de manter trabalhos que compartilham diversas propriedades idênticas, como
objetivos do Maven, destinatários de e-mail ou URL do repositório de código. Para isso, o Maven Jenkins Plugin fornece
herança de jobs, demonstrada no exemplo a seguir:
<jobs>
<job>
<id>google-guice-inheritance-base</id> <abstract>true</
abstract> <jdkName>jdk1.6.0</
jdkName> <mavenName>apache-
maven-3</mavenName> <daysToKeep>5</daysToKeep>
<useUpdate>true</useUpdate>
<mavenGoals>-B -e -U instalação limpa</
mavenGoals>
4
http://evgeny-goldin.com/wiki/Maven-jenkins-plugin#.3Cjob.3E
277
<mail><recipients>jenkins@evgeny-goldin.org</recipients></mail> </job>
<job>
<id>google-guice-inheritance-trunk</id> <parent>google-
guice-inheritance-base</parent> <repositório>
<remote>http://google-guice.googlecode.com/svn/trunk/</remote> </repository> </job>
<job>
<id>google-guice-inheritance-3.0-rc3</id> <parent>google-
guice-inheritance-base</parent> <repositório>
<remote>http://google-guice.googlecode.com/svn/tags/3.0-rc3/</remote> </repository> </job>
<job>
<id>google-guice-inheritance-2.0-maven</id> <parent>google-
guice-inheritance-base</parent> <mavenName>apache-maven-2</
mavenName> <repositório>
<remote>http://google-guice.googlecode.com/svn/branches/2.0-maven/ </remote>
</repositório> </
job> </
jobs>
Nesta configuração, google-guice-inheritance-base é um trabalho pai abstrato que contém todas as propriedades comuns:
nome JDK, nome Maven, dias para manter os logs, política de atualização SVN, metas Maven e destinatários de e-mail. Os
três trabalhos a seguir são muito curtos, apenas especificando que eles estendem um trabalho <parent> e adicionam quaisquer
configurações ausentes (URLs de repositório neste caso). Quando gerados, eles herdam automaticamente todas as
propriedades do trabalho pai.
Qualquer propriedade herdada pode ser substituída, conforme demonstrado no trabalho google-guice-inheritance-2.0-maven
onde Maven 2 é usado em vez de Maven 3. Se quiser “cancelar” uma propriedade herdada, você precisará substituí-la por um
vazio valor.
A herança de jobs é um conceito muito poderoso que permite que jobs formem grupos hierárquicos de qualquer tipo e para
qualquer finalidade. Você pode agrupar seus trabalhos de CI, noturnos ou de liberação dessa forma, centralizando gatilhos de
execução compartilhados, metas Maven ou destinatários de e-mail em trabalhos pai. Esta abordagem emprestada de um
mundo OOP resolve o problema de manter empregos compartilhando um número de propriedades idênticas.
10.5.3. Suporte a plug-ins
Além de configurar um trabalho e reutilizar suas definições, você pode aplicar suporte especial para vários plug-ins do Jenkins.
No momento, é fornecido um uso simplificado dos plug-ins Parameterized Trigger e Artifactory, com suporte para outros plug-
ins populares planejados para versões futuras.
278
www.dbooks.org
Abaixo está um exemplo de invocação de jobs com o plugin Parameterized Trigger. Usar esta opção pressupõe que
você já tenha este plugin instalado:
<job>
<id>google-guice-inheritance-trunk</id>
...
<invocar>
<empregos> google-guice-inheritance-3.0-rc3, google-

guice-inheritance-2.0-maven
</jobs> </
invoke> </
job>
<job>
<id>google-guice-inheritance-3.0-rc3</id>
...
</trabalho>
<job>
<id>google-guice-inheritance-2.0-maven</id>
...
</trabalho>
O elemento <invoke> permite invocar outros trabalhos sempre que o trabalho atual for concluído com êxito. Você pode
criar um pipeline de trabalhos dessa maneira, certificando-se de que cada trabalho em um pipeline invoque o seguinte.
Observe que se houver mais de um executor Jenkins disponível no momento da invocação, os trabalhos especificados
começarão a ser executados em paralelo. Para execução serial, você precisará conectar cada trabalho upstream a um
downstream com <invoke>.
Por padrão, a invocação acontece apenas quando o trabalho atual é estável. Isso pode ser modificado, conforme
mostrado nos exemplos a seguir:
<invocar>
<jobs>jobA, jobB, jobC</jobs> <always>true</
always> </invoke>
<invocar>
<jobs>jobA, jobB, jobC</jobs> <unstable>true</
unstable> </invoke>
<invocar>
<jobs>jobA, jobB, jobC</jobs> <stable>falso</
stable>
<unstable>falso</unstable>
<failed>verdadeiro</failed> </
invoke>
A primeira invocação no exemplo acima sempre invoca os trabalhos downstream. Pode ser usado para um pipeline de
jobs que sempre devem ser executados, mesmo que alguns deles ou seus testes falhem.
279
A segunda invocação no exemplo acima invoca trabalhos downstream mesmo se um trabalho upstream for instável:
a invocação acontece independentemente dos resultados do teste. Ele pode ser usado para um pipeline de
trabalhos menos sensíveis a testes e suas falhas.
A terceira invocação no exemplo acima invoca trabalhos downstream somente quando um trabalho upstream falha,
mas não quando está estável ou instável. Essa configuração pode ser útil quando um trabalho com falha precisa
executar ações adicionais além das tradicionais notificações por email.
Artefato5 é um repositório binário de uso geral que pode ser usado como gerenciador de repositório Maven. O
plugin Jenkins Artifactory6 , mostrado na Figura 10.29, “Configuração do plugin Artifactory Jenkins”, oferece vários
benefícios para trabalhos de construção do Jenkins. Já revisamos alguns deles na Seção 5.9.4, “Implantando em
um Enterprise Repository Manager”, incluindo a capacidade de implantar artefatos após a conclusão do trabalho
ou de enviar informações do ambiente de construção junto com artefatos para sua melhor rastreabilidade.
Figura 10.29. Configuração do plugin Artifactory Jenkins
5
http://jfrog.org
6
http://wiki.jenkins-ci.org/display/JENKINS/Artifactory+Plugin
280
www.dbooks.org
Você também pode usar o plug-in Artifactory Jenkins em conjunto com o plug-in Maven Jenkins para implantar artefatos no
Artifactory, conforme mostrado no exemplo a seguir:
<trabalho>
...
<artefatório>
<name>http://artifactory-server/</name>
<deployArtifacts>true</deployArtifacts>
<includeEnvVars>true</includeEnvVars>
<evenIfUnstable>true</evenIfUnstable>
</artifactory> </job>
As credenciais de implantação padrão são especificadas quando o Jenkins é configurado na tela Gerenciar Jenkins#Configure
System. Eles também podem ser especificados para cada trabalho do Jenkins. Os repositórios Maven padrão são libs-releases-
local e libs-snapshots-local. Você pode encontrar mais detalhes na documentação do plugin em http://wiki.jenkins-ci.org/display/
JENKINS/Artifactory+Plugin.
10.5.4. Empregos de estilo livre
Além dos trabalhos do Maven, o plug-in Maven Jenkins permite configurar trabalhos de estilo livre do Jenkins.
Um exemplo é mostrado aqui:
<job>
<id>estilo livre</id>
<jobType>grátis</jobType>
<scmType>git</scmType>
<repositório>
<remote>git://github.com/evgeny-goldin/maven-plugins-test.git</remote> </repository> <tasks>
<maven>
<jvmOptions>-Xmx128m -XX:MaxPermSize=128m -ea</jvmOptions> <properties>plugins-
version = 0.2.2</properties> </maven> <shell> <comando>pwd; ls -al;
du -hs .</
command></shell> </tasks> </job>
Os trabalhos de estilo livre permitem executar um comando shell ou em lote, executar Maven ou Ant e invocar outros trabalhos.
Eles fornecem um ambiente de tempo de execução conveniente para scripts de sistema ou qualquer outro tipo de atividade
não disponível com Jenkins ou um de seus plug-ins. Usando essa abordagem, você pode gerar arquivos de configuração de
trabalho de construção Freestyle de maneira semelhante à abordagem que vimos para trabalhos de construção Maven, o que
pode ajudar a tornar seu ambiente de construção mais consistente e sustentável.
10.6. Coordenando suas construções

Acionar trabalhos de construção downstream é bastante fácil. No entanto, ao configurar configurações de trabalho de build
maiores e mais complicadas, às vezes você gostaria que os builds pudessem ser executados simultaneamente ou possivelmente
281
espere que certos trabalhos de construção terminem antes de continuar. Nesta seção, veremos técnicas e plug-ins que podem ajudá-
lo a fazer isso.
10.6.1. Construções paralelas em Jenkins
Jenkins tem suporte integrado para compilações paralelas – quando um trabalho de compilação é iniciado, o Jenkins o atribui ao
primeiro nó de compilação disponível, para que você possa ter tantas compilações paralelas em execução quanto nós de compilação
disponíveis.
Se você precisar executar pequenas variações do mesmo trabalho de construção em paralelo, os trabalhos de construção
multiconfiguração (consulte a Seção 10.4, “Trabalhos de construção multiconfiguração”) são uma excelente opção. Isso pode ser útil
como forma de acelerar o processo de construção. Uma aplicação típica de trabalhos de construção multiconfiguração neste contexto
é executar testes de integração em paralelo. Uma estratégia é configurar um trabalho de construção de teste de integração que possa
ser executado de diferentes maneiras para executar diferentes subconjuntos de testes de integração. Você pode definir perfis Maven
separados, por exemplo, ou configurar sua compilação para usar um parâmetro de linha de comando para decidir quais testes
executar. Depois de configurar seu script de construção dessa forma, será fácil configurar um trabalho de construção multiconfiguração
para executar os subconjuntos de seus testes de integração em paralelo.
Você também pode fazer com que o Jenkins acione várias compilações downstream em paralelo, simplesmente listando todas elas
no campo “Construir outros projetos” (consulte a Figura 10.30, “Acionando várias outras compilações após um trabalho de construção”).
Os trabalhos de construção subsequentes serão executados em paralelo, tanto quanto possível. Porém, como veremos mais adiante,
nem sempre isso pode ser exatamente o que você precisa.
Figura 10.30. Acionando vários outros builds após um trabalho de build
10.6.2. Gráficos de Dependência
Antes de investigarmos os detalhes das construções paralelas, é útil poder visualizar os relacionamentos entre seus trabalhos de
construção. O plugin Dependency Graph View analisa seus trabalhos de construção e exibe um gráfico que descreve as conexões
upstream e downstream entre seus trabalhos. Este plugin usa graphviz7 , que você precisará instalar em seu servidor, caso ainda
não o tenha feito.
Este plug-in adiciona um ícone Gráfico de Dependência no menu principal, que exibe um gráfico mostrando os relacionamentos entre
todos os trabalhos de construção em seu projeto (no nível do painel) ou todos os trabalhos de construção relacionados ao trabalho de
construção atual (quando você está dentro de um projeto específico [veja a Figura 10.31, “Um build
7
http://www.graphviz.org
282
www.dbooks.org
gráfico de dependência de trabalho”]). Além do mais, se você clicar em um trabalho de construção no gráfico, o Jenkins o levará
diretamente para a página do projeto desse trabalho de construção.
Figura 10.31. Um gráfico de dependência de trabalho de construção
10.6.3. Junta-se
Ao configurar pipelines de construção mais complicados, você frequentemente se depara com situações em que um trabalho de
construção não pode prosseguir até que vários outros trabalhos de construção tenham sido concluídos, mas esses trabalhos de
construção upstream não precisam ser executados sequencialmente. Por exemplo, na Figura 10.31, “Um gráfico de dependência do
trabalho de construção”, imagine que o trabalho de construção phoenix-deploy-to-uat na verdade requer três trabalhos para ter sucesso
antes de poder ser executado: phoenix-compatibility-tests, phoenix-load-tests , e
testes de desempenho de Phoenix.
Podemos configurar isso usando o plugin Joins, que você precisará instalar da maneira usual através do Centro de atualização. Depois
de instalado, você configura uma junção no trabalho de construção que inicia o processo de junção (em nosso exemplo, seria phoenix-
web-tests). Em nosso exemplo, precisamos modificar o trabalho de construção phoenix-web-tests para que ele acione primeiro os
testes de compatibilidade phoenix, testes de carga phoenix e testes de desempenho phoenix e, em seguida, se esses três forem
bem-sucedidos, o Trabalho de construção phoenix-deploy-to-uat .
Fazemos isso simplesmente configurando o campo Join Trigger com o nome do trabalho de compilação phoenix-deploy-to-uat (consulte
a Figura 10.32, “Configurando uma junção no trabalho de compilação phoenix-web-tests”). O campo “Construir outros projetos” não é
modificado e ainda lista os trabalhos de construção a serem acionados imediatamente após o atual. O campo Join Trigger contém os
trabalhos de construção a serem construídos assim que todos os trabalhos de construção downstream imediatos forem concluídos.
283
Figura 10.32. Configurando uma junção no trabalho de compilação phoenix-web-tests
Como resultado, você não precisa mais do gatilho de build original para o trabalho de build final, pois agora ele é redundante.
Esse novo fluxo aparece muito bem nos gráficos de dependência, conforme ilustrado na Figura 10.33, “Um gráfico de dependência de
trabalho de construção mais complicado”.
Figura 10.33. Um gráfico de dependência de trabalho de construção mais complicado
10.6.4. Fechaduras e travas

Em outras situações, você poderá executar uma série de builds em paralelo até certo ponto, mas determinados jobs de build não poderão
ser executados em paralelo porque acessam recursos simultâneos. Claro, uma construção bem projetada
284
www.dbooks.org
Os empregos devem esforçar-se para serem tão independentes quanto possível, mas por vezes isso pode ser difícil. Por exemplo, diferentes
trabalhos de construção podem precisar acessar o mesmo banco de dados de teste ou arquivos no disco rígido, e fazer isso simultaneamente
pode comprometer potencialmente os resultados dos testes. Ou um trabalho de criação de desempenho pode precisar de acesso exclusivo ao
servidor de teste, para obter resultados consistentes sempre.
O plugin Locks and Latches permite contornar esse problema até certo ponto. Este plugin permite configurar “bloqueios” para determinados
recursos, de forma semelhante aos bloqueios na programação multithread. Suponha, por exemplo, nos trabalhos de construção representados
na Figura 10.33, “Um gráfico de dependência de trabalho de construção mais complicado”, que os testes de carga e os testes de desempenho
sejam executados em um servidor dedicado, mas apenas um trabalho de construção possa ser executado neste servidor a qualquer momento.
um tempo. Imagine ainda que os testes de desempenho de outros projetos também sejam executados neste servidor.
Para evitar contenção sobre o servidor de desempenho, você pode usar o plugin Locks and Latches para configurar um “bloqueio” reservando
acesso a este servidor para um único trabalho de construção por vez. Primeiro, na página Configuração do Sistema, você precisa adicionar um
novo bloqueio na seção Bloqueios (veja Figura 10.34, “Adicionando um novo bloqueio”). Esse bloqueio estará disponível para todos os trabalhos
de construção no servidor.
Figura 10.34. Adicionando um novo bloqueio
Em seguida, você precisa configurar cada trabalho de construção que usará o recurso contestado. Na seção Build Environment, você encontrará
um campo Locks. Marque a caixa de seleção e selecione o bloqueio que você acabou de criar (veja Figura 10.35, “Configurando um trabalho
de construção para usar um bloqueio”). Depois de fazer isso para cada um dos trabalhos de construção que precisam acessar o recurso em
questão, apenas um desses trabalhos de construção poderá ser executado em um determinado momento.
Figura 10.35. Configurando um trabalho de build para usar um bloqueio
10.7. Crie pipelines e promoções

A Integração Contínua não se trata apenas de construir e testar software automaticamente, mas também pode ajudar no contexto mais amplo
do desenvolvimento de produtos de software e do ciclo de vida de lançamento. Em muitas organizações,
285
a vida de uma versão específica de um aplicativo ou produto começa no desenvolvimento. Quando for considerado pronto, ele será
repassado a uma equipe de controle de qualidade para teste. Se considerarem a versão aceitável, eles a repassam a usuários selecionados
para mais testes em um ambiente de Teste de Aceitação de Usuário (UAT). E se os usuários estiverem satisfeitos, ele será enviado para
produção. É claro que existem quase tantas variações quanto há equipes de desenvolvimento de software, mas um princípio comum é
que versões específicas do seu software sejam selecionadas, de acordo com certos critérios relacionados à qualidade, para serem
“promovidas” para o próximo estágio de desenvolvimento. o ciclo de vida. Isso é conhecido como promoção de build, e o processo mais
amplo é conhecido como pipeline de build. Nesta seção, veremos como você pode implementar pipelines de construção usando Jenkins.
10.7.1. Gerenciando versões do Maven com o plug-in M2Release

Uma parte importante de qualquer pipeline de construção é uma estratégia de lançamento bem definida. Isto envolve, entre outras coisas,
decidir como e quando lançar um novo lançamento e como identificá-lo com um rótulo ou número de versão exclusivo. Se você estiver
trabalhando com projetos Maven, usar o plugin Maven Release para lidar com números de versão é uma prática altamente recomendada.
Os projetos Maven usam números de versão bem definidos e estruturados. Um número de versão típico é composto de três dígitos (por
exemplo, “1.0.1”). Os desenvolvedores trabalham em versões do SNAPSHOT (por exemplo, “1.0.1-SNAPSHOT”), que, como o nome
indica, não foram projetadas para serem definitivas. As versões definitivas (por exemplo, “1.0.1”) são construídas uma vez e implantadas
no repositório corporativo local (ou no repositório central Maven para bibliotecas de código aberto), onde podem ser usadas por outros
projetos. Os números de versão usados nos artefatos Maven são uma parte crítica do sistema de gerenciamento de dependências do
Maven, e é altamente recomendável seguir as convenções do Maven.
O plugin Maven Release ajuda a automatizar o processo de atualização dos números de versão do Maven em seus projetos. Resumindo,
ele verifica, cria e testa seu aplicativo, aumenta os números de versão, atualiza seu sistema de controle de versão com as tags apropriadas
e implanta as versões lançadas de seus artefatos em seu repositório Maven. Esta é uma tarefa tediosa de fazer manualmente, então o
plugin Maven Release é uma excelente maneira de automatizar as coisas.
No entanto, o plugin Maven Release também pode ser inconstante. Arquivos locais não confirmados ou modificados podem causar falha
no processo, por exemplo. O processo também é demorado e exige muita CPU, especialmente para projetos grandes: ele cria o aplicativo
e executa todo o conjunto de testes unitários e de integração várias vezes, verifica uma nova cópia do código-fonte do repositório e
carrega muitos artefatos. para o repositório corporativo. Na verdade, esse não é o tipo de coisa que você deseja executar em uma máquina
de desenvolvedor.
Portanto, faz sentido executar esse processo em seu servidor de compilação.
Uma maneira de fazer isso é configurar um trabalho de construção manual especial para invocar o plugin Maven Release. No entanto, o
plugin M2Release propõe uma abordagem mais simples. Usando este plug-in, você pode adicionar a capacidade de construir uma versão
de lançamento do Maven em um trabalho de construção existente. Dessa forma, você pode evitar a duplicação desnecessária de trabalhos
de construção, facilitando a manutenção dos trabalhos de construção.
Depois de instalar este plugin, você pode definir qualquer trabalho de construção para propor também uma etapa manual de lançamento
do Maven. Você faz isso marcando a caixa de seleção “Maven release build” no Build Environment
286
www.dbooks.org
seção (veja Figura 10.36, “Configurando uma versão Maven usando o plugin M2Release”). Aqui, você define os objetivos
que deseja executar para acionar a construção (normalmente release:prepare release:perform).
Figura 10.36. Configurando uma versão do Maven usando o plugin M2Release
Depois de configurar isso, você pode acionar uma versão do Maven manualmente usando uma nova opção de menu
chamada “Executar versão do Maven” (consulte a Figura 10.37, “A opção de menu Executar versão do Maven”).
Figura 10.37. A opção de menu Executar lançamento do Maven
Isso iniciará um trabalho de construção especial usando os objetivos fornecidos na configuração do plugin (veja a Figura
10.38, “Executando uma versão do Maven no Jenkins”). Jenkins oferece a opção de usar os números de versão padrão
fornecidos pelo Maven (por exemplo, a versão 1.0.1-SNAPSHOT será lançada como versão 1.0.1 e o número da versão
de desenvolvimento aumentou para 1.0.2-SNAPSHOT) ou fornecer
287
seus próprios números personalizados. Se quiser lançar uma versão principal, por exemplo, você pode optar por especificar
manualmente 1.1.0 como o número da versão de lançamento e 1.1.1-SNAPSHOT como o próximo número da versão de
desenvolvimento.
Se você tiver um projeto Maven multimódulo, poderá optar por fornecer uma configuração de número de versão único para
todos os módulos ou fornecer uma atualização de número de versão diferente para cada módulo. Observe que geralmente
não é uma prática recomendada fornecer números de versão diferentes para módulos diferentes em um projeto multimódulo.
Figura 10.38. Executando um lançamento do Maven no Jenkins
Dependendo da configuração do SCM, você também pode precisar fornecer um nome de usuário e uma senha válidos do
SCM para permitir que o Maven crie tags no seu repositório de código-fonte.
A edição profissional do Nexus Enterprise Repository oferece um recurso chamado Staging Repositories, que é uma forma
de implantar artefatos em uma área de teste especial para testes adicionais antes de liberá-los oficialmente. Se estiver
usando esse recurso, você precisará ajustar a configuração do servidor de compilação para obter melhores resultados.
O Nexus Professional funciona criando uma nova área de teste para cada endereço IP exclusivo, implantando usuários e
agente de usuário HTTP. Uma determinada máquina de construção Jenkins sempre terá o mesmo endereço IP e usuário.
No entanto, normalmente você desejará ter uma área de preparação separada para cada compilação. O truque, então, é
configurar o Maven para usar um agente de usuário HTTP exclusivo para o processo de implantação. Você pode fazer isso
configurando o arquivo settings.xml em seu servidor de compilação para conter algo como as seguintes linhas (o ID deve
corresponder ao ID do repositório de lançamento na seção de implantação do seu projeto):
<servidor>
<id>nexus</id>
<username>meu_login</username>
<password>minha_senha</password> <configuration>
<httpHeaders>
<property>
<name>User-Agent</name>
288
www.dbooks.org
<value>Maven m2Release (java:20.1-b02-383 ${env.BUILD_TAG }</value> </property> </

httpHeaders>
</configuration> </
server>
10.7.2. Copiando artefatos

Durante um processo de construção que envolve vários trabalhos de construção, como aquele ilustrado na Figura 10.33,
“Um gráfico de dependência de trabalho de construção mais complicado”, às vezes pode ser útil reutilizar artefatos produzidos
por um trabalho de construção em um trabalho de construção subsequente. Por exemplo, você pode querer executar uma
série de testes web em paralelo em máquinas separadas, usando servidores de aplicativos locais para melhorar o
desempenho. Nesse caso, faz sentido recuperar o artefato binário exato que foi produzido na construção anterior, em vez de
reconstruí-lo a cada vez ou, se você estiver usando o Maven, contar com uma construção SNAPSHOT implementada em
seu repositório corporativo. Na verdade, ambas as abordagens podem correr o risco de resultados de construção
inconsistentes: se você usar um SNAPSHOT do repositório corporativo, por exemplo, você estará usando a construção
SNAPSHOT mais recente, que pode não ser necessariamente aquela construída na tarefa de construção upstream.
O plugin Copy Artifact permite copiar artefatos de uma compilação upstream e reutilizá-los em sua compilação atual. Depois
de instalar este plug-in e reiniciar o Jenkins, você poderá adicionar um novo tipo de etapa de construção chamada “Copiar
artefatos de outro projeto” aos seus trabalhos de construção de estilo livre (consulte a Figura 10.39, “Adicionando uma opção
“Copiar artefatos de outro projeto” etapa de construção”).
Figura 10.39. Adicionando uma etapa de construção “Copiar artefatos de outro projeto”
Esta nova etapa de construção permite copiar artefatos de outro projeto para o espaço de trabalho do projeto atual.
Você pode especificar qualquer outro projeto, embora normalmente seja um dos trabalhos de construção upstream. E é claro
que você pode especificar, com muita flexibilidade e precisão, os artefatos exatos que deseja copiar.
Você precisa especificar onde encontrar os arquivos desejados no espaço de trabalho do outro trabalho de construção e
onde Jenkins deve colocá-los no espaço de trabalho do seu projeto atual. Esta pode ser uma expressão regular flexível
289

Jenkins - The Definitive Guide-Páginas-8

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Jenkins - The Definitive Guide-Páginas-8

Enviado por

Direitos autorais:

Formatos disponíveis

Machine Translated by Google

Figura 9.16. Configurar o plugin Task Scanner é simples

Figura 9.17. O gráfico de tendência de tarefas abertas

9.8. Integrando com Sonar

Figura 9.18. Relatórios de qualidade de código do Sonar

Jenkins Banco de dados de sonar

Figura 9.19. Jenkins e Sonar

Figura 9.20. Configurando Sonar no Jenkins

Figura 9.21. Configurando o Sonar em um trabalho de build

Figura 9.22. Agendamento de compilações do Sonar

Capítulo 10. Construções Avançadas

10.2. Jobs de compilação parametrizados

10.2.1. Criando um trabalho de construção parametrizado

Figura 10.1. Criando um job de build parametrizado

Figura 10.2. Adicionando um parâmetro ao trabalho de construção

Figura 10.3. Adicionando um parâmetro ao trabalho de construção

10.2.2. Adaptando suas compilações para funcionar com scripts de compilação

Figura 10.4. Demonstrando um parâmetro de construção

Iniciado pelo usuário anônimo Com

Figura 10.5. Adicionando um parâmetro a um trabalho de construção do Maven

Figura 10.6. Muitos tipos diferentes de parâmetros estão disponíveis

10.2.3. Tipos de parâmetros mais avançados

Figura 10.7. Configurando um parâmetro Choice

Figura 10.8. Configurando um parâmetro Run

Figura 10.9. Configurando um parâmetro de arquivo

10.2.4. Construindo a partir de uma tag Subversion

Figura 10.11. Construindo a partir de uma tag Subversion

10.2.5. Construindo a partir de uma tag Git

Figura 10.12. Configurando um parâmetro para uma tag Git

Figura 10.13. Construindo a partir de uma tag Git

10.2.6. Iniciando um trabalho de compilação parametrizado remotamente

10.2.7. Histórico de trabalho de construção parametrizado

10.3. Gatilhos parametrizados

Figura 10.16. Adicionando um gatilho parametrizado a um trabalho de build

atuais (a variável DATABASE neste caso) e um parâmetro adicional chamado TARGET_PLATFORM.

Figura 10.18. Passando um parâmetro predefinido para um trabalho de construção parametrizado

10.4. Trabalhos de compilação multiconfiguração

10.4.1. Configurando uma compilação multiconfiguração

Figura 10.19. Criando um trabalho de build multiconfiguração

Figura 10.20. Adicionando um eixo a uma construção multiconfiguração

Vejamos os tipos de eixo que você pode definir.

10.4.2. Configurando um eixo escravo

Figura 10.21. Definindo um eixo de nós escravos

10.4.3. Configurando um eixo JDK

Figura 10.22. Definindo um eixo de versões do JDK

10.4.4. Eixo personalizado

Figura 10.23. Definindo um eixo definido pelo usuário

10.4.5. Executando uma compilação multiconfiguração

Figura 10.24. Resultados de compilação multiconfiguração

Figura 10.25. Configurando um filtro combinado

Figura 10.26. Crie resultados usando um filtro de combinação

10.5. Gerando seus trabalhos de compilação Maven automaticamente

Contribuição de Evgeny Goldin

10.5.1. Configurando um Trabalho

Vamos dar uma olhada no Google Guice3 construir trabalho:

<expressão>0 0 * * *</expressão> </trigger>

<remote>http://google-guice.googlecode.com/svn/trunk/</remote> </repository> <mail>

Figura 10.27. Um trabalho gerado pelo plugin Maven Jenkins

Aqui está outro trabalho de construção do branch master Jenkins no GitHub:

Isso geraria o trabalho mostrado na Figura 10.28, “trabalho jenkins-master gerado”.

Figura 10.28. trabalho jenkins-master gerado

10.5.2. Reutilizando a configuração do trabalho com herança

<remote>http://google-guice.googlecode.com/svn/trunk/</remote> </repository> </job>