Introdução
Moss & Mallow é uma loja fictícia de presentes de bairro. Sua nova coleção de kits de sementes deve manter as regras existentes de desconto por quantidade e entrega. A loja já funciona, mas o Pipeline do Jenkins fornecido pode publicar uma versão candidata mesmo quando um teste real de preços falha.
Você lerá a falha real do teste, conectará o status do build no Jenkins à decisão de liberar a versão e publicará a versão candidata que funciona corretamente. Este laboratório pressupõe conhecimentos básicos de navegação no Jenkins e a capacidade de reconhecer um Declarative Pipeline curto. Ele explica as novas configurações de relatório de testes e de controle de liberação; não é necessário programar a aplicação, instalar software, ter uma conta na nuvem ou fazer uma compra real.
Use Gift Shop para o percurso do cliente e Jenkins para a configuração e os builds. São dois serviços em uma única VM preparada. As duas versões candidatas, broken e fixed, são versões de teste fornecidas. Cada unidade começa de forma independente. A estimativa de tempo inclui leitura e erros comuns e não foi medida com iniciantes.
Veja o que um teste com falha realmente impede
Nesta etapa, você comparará os preços normais com um teste real que falhou e descobrirá por que um build instável do Jenkins ainda pode publicar uma versão. Comece em Gift Shop.
Selecione Find a little gift ou Shop na navegação. Um kit de sementes custa £12. Três ou mais kits de sementes recebem um desconto de 10% por quantidade. A entrega custa £4 e se torna gratuita quando o total das mercadorias é de pelo menos £40. Os preços são estimativas; a loja não recebe pagamentos.
Defina Quantity do kit de sementes como 3 e selecione Check basket. O preço normal das mercadorias é £32.40, a entrega é £4.00 e o total é £36.40. Use Shop para voltar. Confira também duas caixas de piquenique: as mercadorias custam £40.00 e a entrega é gratuita. Abra Visit, baixe o cartão de cuidados com as sementes e leia o arquivo de texto salvo. Essas funções normais devem continuar disponíveis ao final.
Uma versão candidata é uma versão que está sendo considerada para liberação. Um build é uma execução do Jenkins, com seu próprio número, parâmetros e resultado. Mude para a aba Jenkins. Abra shop-update e selecione Build with Parameters. Mantenha RELEASE como broken e selecione Build. Essa primeira execução publica deliberadamente uma versão candidata incorreta de treinamento para que você possa observar o problema; nenhum cliente real é afetado.
Aguarde até que o build termine. Abra sua entrada numerada em Builds e, em seguida, Console Output. O Pipeline tem três estágios: Prepare copia a versão candidata escolhida para o diretório de trabalho do build, Test executa as verificações de preços fornecidas e Publish entrega o pacote à loja.
O console deve incluir estas linhas, cujo conteúdo é estável:
Pricing failures: 1
Release received
Finished: UNSTABLE
UNSTABLE significa que o build tem um problema de qualidade, como testes que falharam. Por si só, isso não impede todos os estágios posteriores. Release received mostra que esse Pipeline ainda realizou a publicação.
Abra Tests nesse build. Abra o teste seed_bundle que falhou e leia os detalhes da falha:
Expected 3240 400; got 2880 400
Os valores estão em pence, os centavos da libra: o teste esperava £32.40 em mercadorias e £4 de entrega, mas a versão candidata calculou £28.80 em mercadorias. Os outros três testes passaram. Esses resultados vêm da execução do programa real de preços da versão candidata; o relatório XML é gerado a partir dessas comparações.
Mude para Gift Shop, use Shop e confira novamente três kits de sementes. Atualize a página se necessário. O total incorreto agora é £32.80. Você observou uma versão incorreta realmente publicada, e não apenas uma cor de aviso. Volte ao build numerado do Jenkins antes de usar a verificação desta etapa.
Conecte o resultado do teste à publicação
Nesta etapa, você alterará o Pipeline para que um teste com falha continue visível e impeça o estágio Publish. Comece em Jenkins e abra a página do job shop-update usando o link correspondente na trilha de navegação.
Selecione Configure e, em seguida, a seção Pipeline. Seu editor Script contém um Declarative Pipeline. agent any seleciona um executor disponível do Jenkins; neste ambiente introdutório preparado, ele é executado dentro do contêiner do controlador. Um workspace é o diretório alocado para esse build. Um projeto separado ensina o uso de agentes independentes.
Leia o estágio Test. A linha fornecida sh returnStatus: true, script: ... executa o script de testes e retorna seu status de saída, em vez de gerar imediatamente um erro no Pipeline. Isso permite que a etapa junit seguinte publique os detalhes dos testes. Um status de saída igual a zero significa que o script passou; um status diferente de zero significa que não passou. junit lê o arquivo XML de resultados, associa os testes a esse build e normalmente o marca como UNSTABLE quando um teste falha.
Uma opção de Pipeline altera a maneira como o Jenkins executa o Pipeline. Adicione a linha a seguir imediatamente depois de agent any. As chaves agrupam a opção; mantenha tanto a chave de abertura quanto a de fechamento exatamente como mostrado.
options { skipStagesAfterUnstable() }
O início do script agora deve ficar assim. Mantenha todas as outras linhas existentes, incluindo o endereço do receptor e os estágios Prepare, Test e Publish fornecidos.
pipeline {
agent any
options { skipStagesAfterUnstable() }
Essa opção ignora os estágios subsequentes depois que o build se torna instável. Ela não transforma um teste com falha em um teste aprovado. Mantenha o publicador padrão de relatórios:
junit testResults: 'reports/pricing.xml'
Mantenha as chamadas de shell fornecidas para copiar a versão candidata, executar test-shop.sh e publicar o pacote. O relatório de testes deve vir desse executor de testes; não o substitua por uma etapa que escreva um relatório nem adicione outros comandos de shell.
Não adicione skipMarkingBuildUnstable: true: essa configuração suprime o status do build do qual esse controle de liberação depende. Não remova testes, não altere os preços esperados, não modifique as versões candidatas ou o publicador fornecidos e não ignore a publicação de todas as versões candidatas.
Selecione Save. Selecione Build with Parameters, mantenha broken e selecione Build. Aguarde o término do novo build numerado. Abra Console Output. Desta vez, você deve ver:
Pricing failures: 1
Stage "Publish" skipped due to earlier stage(s) marking the build as unstable
Finished: UNSTABLE
Abra Tests. O mesmo teste com falha e os três testes aprovados ainda devem estar presentes. O novo build não deve conter Release received. A loja ainda pode mostrar a versão incorreta anterior: bloquear uma nova tentativa não reverte automaticamente uma publicação anterior. Na próxima etapa, você a substituirá pela versão candidata que funciona corretamente.
Se, em vez disso, o build informar um erro de sintaxe do Groovy, abra Configure novamente. Confira se a linha options adicionada está dentro de pipeline, logo abaixo de agent any, com as chaves de abertura e fechamento correspondentes. Corrija-a, selecione Save e execute broken novamente. Uma falha de sintaxe, por si só, não conclui esta etapa. Às vezes, o Jenkins exibe um aviso do publicador da Checks API; este curso local não usa um serviço Git hospedado, portanto esse aviso não substitui o resultado real do teste.
Publique a versão candidata que funciona corretamente
Nesta etapa, você comprovará que o mesmo Pipeline pode entregar uma atualização correta e preservar o percurso normal do cliente. Comece na página do job shop-update em Jenkins.
Selecione Build with Parameters. Defina RELEASE como fixed e selecione Build. Isso seleciona a versão candidata funcional fornecida; não altera o Pipeline que você acabou de testar. Aguarde a conclusão e abra Console Output do novo build.
Pricing failures: 0
Release received
Finished: SUCCESS
Abra Tests. Todos os quatro testes de preços devem passar. Volte à página de status desse build e encontre Build Artifacts. Baixe shop-release.tar.gz. Um artefato é um arquivo que o Jenkins mantém para esse build; esse arquivo compactado contém o programa de preços, os metadados da versão e o cartão de cuidados. O arquivo compactado também é o pacote real enviado à loja, e não uma cópia reconstruída separadamente.
Mude para Gift Shop, selecione o link da marca para voltar à página inicial e atualize a página. A coleção agora é Gifts to grow together. Abra Shop e confira três kits de sementes: mercadorias £32.40, entrega £4.00, total £36.40. Duas caixas de piquenique ainda devem ter entrega gratuita. Abra Delivery e Visit, baixe o cartão de cuidados novamente e confirme que ele está completo.
A verificação final conecta os builds reais com falha e com sucesso ao Pipeline salvo atualmente e aos bytes implantados. Se você editar o Pipeline depois dessas execuções, repita broken e depois fixed para que ambos os resultados descrevam a versão que você está enviando. Mantenha os builds anteriores e os recursos originais da loja; não é necessário escrever um relatório nem copiar um arquivo do console.
Se você selecionar broken novamente por engano, mantenha o controle de liberação e execute fixed. Se o Jenkins ainda estiver executando um build, aguarde o resultado final do build numerado em vez de iniciar mais builds repetidamente. Uma página inicial funcionando, por si só, é insuficiente: os preços do carrinho e o download fazem parte do trabalho concluído.
Resumo
Você observou uma falha real em um teste de preços, viu por que um build instável ainda publicava uma versão e conectou o resultado do teste do Jenkins a um controle de liberação. Depois, usou o mesmo Pipeline para entregar a versão candidata que funciona corretamente e verificou os preços reais, o pacote arquivado e as funções normais da loja.
