Tutorial de entrega contínua - Construindo um pipeline de entrega contínua usando Jenkins

Entrega contínua:

A entrega contínua é um processo em que as alterações de código são criadas, testadas e preparadas automaticamente para serem liberadas para produção.Eu espero que você tenha gostado do meu Aqui, falarei sobre os seguintes tópicos:

• O que é entrega contínua?
• Tipos de teste de software
• Diferença entre integração contínua, entrega e implantação
• Qual é a necessidade de entrega contínua?
• Prática usando Jenkins e Tomcat

Vamos entender rapidamente como funciona a entrega contínua.

perguntas da entrevista c ++ stl

O que é entrega contínua?

É um processo em que você cria um software de forma que ele possa ser liberado para produção a qualquer momento.Considere o diagrama abaixo:

Deixe-me explicar o diagrama acima:

• Scripts de compilação automatizados irão detectar mudanças no Source Code Management (SCM) como Git.
• Assim que a alteração for detectada, o código-fonte será implantado em um servidor de construção dedicado para garantir que a construção não esteja falhando e que todas as classes de teste e testes de integração estejam funcionando bem.
• Em seguida, o aplicativo de construção é implantado nos servidores de teste (servidores de pré-produção) para o Teste de Aceitação do Usuário (UAT).
• Finalmente, o aplicativo é implantado manualmente nos servidores de produção para lançamento.

Antes de prosseguir, será justo explicar a você os diferentes tipos de teste.

Tipos de teste de software:

Em termos gerais, existem dois tipos de teste:

• Teste da caixa preta: É uma técnica de teste que ignora o mecanismo interno do sistema e se concentra na saída gerada em relação a qualquer entrada e execução do sistema. Também é chamado de teste funcional. É basicamente usado para validar o software.
• Teste de caixa branca: é uma técnica de teste que leva em consideração o mecanismo interno de um sistema. É também chamado de teste estrutural e teste de caixa de vidro. É basicamente usado para verificar o software.

Teste de caixa branca:

Existem dois tipos de teste, que se enquadram nesta categoria.

• Teste de Unidade: É o teste de uma unidade individual ou grupo de unidades relacionadas. Freqüentemente, é feito pelo programador para testar se a unidade que ele implementou está produzindo a saída esperada em relação à entrada fornecida.
• Teste de integração: É um tipo de teste em que um grupo de componentes sãocombinados para produzir a saída. Além disso, a interação entre software e hardware é testada se os componentes de software e hardware têm alguma relação. Ele pode se enquadrar nos testes de caixa branca e caixa preta.

Teste da caixa preta:

Existem vários testes que se enquadram nesta categoria. Vou focar emum pouco, que são importantes para você saber, para entender este blog:

• Teste Funcional / Aceitação: Ele garante que a funcionalidade especificada exigida nos requisitos do sistema funcione. Isso é feito para garantir que o produto entregue atenda aos requisitos e funcione como o cliente esperava
• Teste de sistema: Ele garante que, ao colocar o software em ambientes diferentes (por exemplo, sistemas operacionais), ele ainda funcionará.
• Teste de estresse: Ele avalia como o sistema se comporta em condições desfavoráveis.
• Teste beta: Isso é feito por usuários finais, uma equipe externa de desenvolvimento ou lançando publicamente uma pré-versão completa do produto, que é conhecida comobetaversão. O objetivo do teste beta é cobrir erros inesperados.

Agora é o momento certo para eu explicar a diferença entre integração contínua, entrega e implantação.

Diferenças entre integração contínua, entrega e implantação:

O conteúdo visual chega ao cérebro de um indivíduo de uma forma mais rápida e compreensível do que a informação textual. Vou começar com um diagrama que explica claramente a diferença:

Na integração contínua, cada confirmação de código é construída e testada, mas não está em condições de ser liberada. Quero dizer, o aplicativo de compilação não é implantado automaticamente nos servidores de teste para validá-lo usando diferentes tipos de teste de caixa preta como - Teste de aceitação do usuário (UAT).

Na entrega contínua, o aplicativo é continuamente implantado nos servidores de teste para UAT. Ou você pode dizer que o aplicativo está pronto para ser lançado para produção a qualquer momento. Portanto, obviamente, a integração contínua é necessária para a entrega contínua.

A implantação contínua é a próxima etapa após a entrega contínua, onde você não está apenas criando um pacote implantável, mas na verdade o está implantando de maneira automatizada.

Deixe-me resumir as diferenças usando uma tabela:

Em termos simples, a integração contínua é uma parte tanto da entrega contínua quanto da implantação contínua. E a implantação contínua é como a entrega contínua, exceto que as liberações acontecem automaticamente.

Aprenda a criar pipelines de CI / CD usando Jenkins na nuvem

Mas a questão é se a integração contínua é suficiente.

Por que precisamos de entrega contínua?

Vamos entender isso com um exemplo.

Imagine que haja 80 desenvolvedores trabalhando em um grande projeto. Eles estão usando pipelines de integração contínua para facilitar compilações automatizadas. Sabemos que a construção inclui testes de unidade também. Um dia eles decidiram implantar a compilação mais recente que havia passado nos testes de unidade em um ambiente de teste.

Essa deve ser uma abordagem demorada, mas controlada, de implantação realizada por seus especialistas em ambiente. No entanto, o sistema não parecia funcionar.

Qual pode ser a causa óbvia do fracasso?

Bem, a primeira razão que a maioria das pessoas vai pensar é que há algum problema com a configuração. Como a maioria das pessoas, até eles pensavam assim.Eles passaram muito tempo tentando descobrir o que havia de errado com a configuração do ambiente, mas não conseguiram encontrar o problema.

Um desenvolvedor perceptivo adotou uma abordagem inteligente:

Então, um dos desenvolvedores sênior testou o aplicativo em sua máquina de desenvolvimento. Também não funcionou lá.

Ele voltou para as versões anteriores e anteriores até descobrir que o sistema havia parado de funcionar três semanas antes. Um pequeno e obscuro bug impediu o sistema de iniciar corretamente. Embora o projeto tenha uma boa cobertura de teste de unidade.Apesar disso, 80 desenvolvedores, que normalmente executavam apenas os testes e não o próprio aplicativo, não viram o problema por três semanas.

Declaração do problema:

Sem executar testes de aceitação em um ambiente de produção, eles não sabem nada sobre se o aplicativo atende às especificações do cliente, nem se pode ser implantado e sobreviver no mundo real. Se quiserem feedback oportuno sobre esses tópicos, eles devem estender o alcance de seu processo de integração contínua.

Deixe-me resumir as lições aprendidas ao examinar os problemas acima:

• Os testes de unidade apenas testam a perspectiva de um desenvolvedor da solução para um problema. Eles têm apenas uma capacidade limitada de provar que o aplicativo faz o que deve da perspectiva do usuário. Eles não são suficientes paraidentificar os reais problemas funcionais.
• A implantação do aplicativo no ambiente de teste é um processo complexo e manual intensivo que estava sujeito a erros.Isso significava que cada tentativa de implantação era um novo experimento - um processo manual sujeito a erros.

Solução - Pipeline de entrega contínua (teste de aceitação automatizada):

Eles levaram a Integração Contínua (Entrega Contínua) para a próxima etapa e introduziram alguns Testes de Aceitação simples e automatizados que provaram que o aplicativo era executado e podia realizar sua função mais fundamental.A maioria dos testes executados durante o estágio de Teste de Aceitação são Testes de Aceitação Funcional.

Basicamente, eles construíram um pipeline de entrega contínua, a fim de garantir que o aplicativo seja perfeitamente implantado no ambiente de produção, garantindo que o aplicativo funcione bem quando implantado no servidor de teste, que é uma réplica do servidor de produção.

Chega de teoria, agora mostrarei como criar um pipeline de entrega contínua usando Jenkins.

Pipeline de entrega contínua usando Jenkins:

Aqui, usarei o Jenkins para criar um Pipeline de entrega contínua, que incluirá as seguintes tarefas:

Etapas envolvidas na demonstração:

• Buscando o código do GitHub
• Compilando o código fonte
• Teste de unidade e geração de relatórios de teste JUnit
• Empacotar o aplicativo em um arquivo WAR e implementá-lo no servidor Tomcat

Pré-requisitos:

• Máquina CentOS 7
• Jenkins 2.121.1
• Docker
• Tomcat 7

Etapa - 1 Compilando o código-fonte:

Vamos começar criando um projeto Freestyle no Jenkins. Considere a captura de tela abaixo:

Dê um nome ao seu projeto e selecione Freestyle Project:

Ao rolar para baixo, você encontrará uma opção para adicionar repositório de código-fonte, selecione git e adicione a URL do repositório, nesse repositório há uma multa pom.xml que usaremos para construir nosso projeto. Considere a captura de tela abaixo:

Agora vamos adicionar um Build Trigger. Escolha a opção poll SCM, basicamente, vamos configurar o Jenkins para pesquisar o repositório GitHub a cada 5 minutos para mudanças no código. Considere a captura de tela abaixo:

Antes de prosseguir, vou apresentar uma pequena introdução ao ciclo de construção do Maven.

Cada um dos ciclos de vida de construção é definido por uma lista diferente de fases de construção, em que uma fase de construção representa um estágio no ciclo de vida.

A seguir está a lista de fases de construção:

• validar - validar se o projeto está correto e todas as informações necessárias estão disponíveis
• compilar - compilar o código fonte do projeto
• test - testa o código-fonte compilado usando uma estrutura de teste de unidade adequada. Esses testes não devem exigir que o código seja empacotado ou implantado
• pacote - pegue o código compilado e empacote-o em seu formato distribuível, como um JAR.
• verificar - execute qualquer verificação dos resultados dos testes de integração para garantir que os critérios de qualidade sejam atendidos
• instalar - instalar o pacote no repositório local, para usar como uma dependência em outros projetos localmente
• implantar - feito no ambiente de construção, copia o pacote final para o repositório remoto para compartilhamento com outros desenvolvedores e projetos.

Posso executar o comando abaixo, para compilar o código-fonte, testar a unidade e até mesmo empacotar o aplicativo em um arquivo war:

pacote limpo mvn

Você também pode dividir seu trabalho de construção em várias etapas de construção. Isso torna mais fácil organizar compilações em estágios limpos e separados.

Portanto, começaremos compilando o código-fonte. Na guia de construção, clique em invocar alvos maven de nível superior e digite o comando abaixo:

compilar

Considere a captura de tela abaixo:

Isso irá puxar o código-fonte do repositório GitHub e também irá compilá-lo (fase de compilação do Maven).

Clique em Salvar e execute o projeto.

Agora, clique na saída do console para ver o resultado.

Etapa - Teste de 2 unidades:

Agora vamos criar mais um projeto Freestyle para testes de unidade.

Adicione a mesma URL do repositório na guia de gerenciamento do código-fonte, como fizemos no trabalho anterior.

Agora, na aba “Buid Trigger” clique em “construir depois que outros projetos forem construídos”. Lá digite o nome do projeto anterior onde estamos compilando o código-fonte, e você pode selecionar qualquer uma das opções abaixo:

• Acione apenas se a construção estiver estável
• Acione mesmo se a construção estiver instável
• Acione mesmo se a compilação falhar

Acho que as opções acima são bastante autoexplicativas, então, selecione qualquer uma. Considere a captura de tela abaixo:

Na guia Construir, clique em invocar alvos maven de nível superior e use o comando abaixo:

teste

Jenkins também faz um ótimo trabalho em ajudá-lo a exibir os resultados dos testes e as tendências dos resultados dos testes.

O padrão de fato para relatórios de teste no mundo Java é um formato XML usado pelo JUnit. Este formato também é usado por muitas outras ferramentas de teste Java, como TestNG, Spock e Easyb. Jenkins entende esse formato, portanto, se sua construção produzir resultados de teste JUnit XML, Jenkins pode gerar bons relatórios gráficos de teste e estatísticas sobre resultados de teste ao longo do tempo, e também permite que você visualize os detalhes de quaisquer falhas de teste. Jenkins também controla quanto tempo seus testes levam para serem executados, tanto globalmente quanto por teste - isso pode ser útil se você precisar rastrear problemas de desempenho.

Portanto, a próxima coisa que precisamos fazer é fazer com que o Jenkins controle nossos testes de unidade.

Vá para a seção Ações de pós-construção e marque a caixa de seleção “Publicar relatório de resultado de teste JUnit”. Quando o Maven executa testes de unidade em um projeto, ele gera automaticamente os relatórios de teste XML em um diretório chamado surefire-reports. Portanto, digite “** / target / surefire-reports / *. Xml” no campo “Testar XMLs de relatório”. Os dois asteriscos no início do caminho (“**”) são uma prática recomendada para tornar a configuração um pouco mais robusta: eles permitem que o Jenkins encontre o diretório de destino independentemente de como configuramos o Jenkins para verificar o código-fonte.

** / target / surefire-reports / *. xml

Salve novamente e clique em Build Now.

Agora, o relatório JUnit é gravado em / var / lib / jenkins / workspace / test / gameoflife-core / target / surefire-reports / TEST-behaviour.

No painel do Jenkinsvocê também pode observar os resultados do teste:

Etapa 3 - Criação de um arquivo WAR e implantação no servidor Tomcat:

Agora, a próxima etapa é empacotar nosso aplicativo em um arquivo WAR e implementá-lo no servidor Tomcat para teste de aceitação do usuário.

Crie mais um projeto freestyle e adicione a URL do repositório de código-fonte.

Em seguida, na guia do acionador de compilação, selecione compilar quando outros projetos forem compilados, considere a captura de tela abaixo:

Basicamente, após o trabalho de teste, a fase de implantação começará automaticamente.

Na guia de construção, selecione script de shell. Digite o comando abaixo para empacotar o aplicativo em um arquivo WAR:

pacote mvn

A próxima etapa é implantar este arquivo WAR no Tomcatservidor. Na guia “Ações pós-construção”, selecione implantar war / ear em um contêiner. Aqui, forneça o caminho para o arquivo war e o caminho de contexto. Considere a captura de tela abaixo:

Selecione as credenciais do Tomcat e observe a captura de tela acima. Além disso, você precisa fornecer a URL do seu servidor Tomcat.

Para adicionar credenciais no Jenkins, clique na opção credenciais no painel do Jenkins.

Clique em Sistema e selecione as credenciais globais.

Em seguida, você encontrará uma opção para adicionar as credenciais. Clique nele e adicione credenciais.

sort array c ++ decrescente

Adicione as credenciais do Tomcat, considere a captura de tela abaixo.

Clique em OK.

Agora em sua configuração de projeto, adicione as credenciais do tomcat que você inseriu na etapa anterior.

Clique em Salvar e selecione Construir agora.

Vá para a URL do tomcat, com o caminho do contexto, no meu caso é http: // localhost: 8081. Agora adicione o caminho do contexto no final, considere a captura de tela abaixo:

Link - http: // localhost: 8081 / gof

Espero que você tenha entendido o significado do caminho do contexto.

Agora crie uma visualização do pipeline, considere a captura de tela abaixo:

Clique no ícone de adição para criar uma nova visualização.

Configure o pipeline da maneira que desejar, considere a captura de tela abaixo:

Não mudei nada além de selecionar o trabalho inicial. Portanto, meu pipeline começará a partir da compilação. Com base na forma como configurei outras tarefas, após a compilação, o teste e a implantação acontecerão.

Finalmente, você pode testar o pipeline clicando em RUN. A cada cinco minutos, se houver alteração no código-fonte, todo o pipeline será executado.

Portanto, podemos implantar continuamente nosso aplicativo no servidor de teste para o teste de aceitação do usuário (UAT).

Espero que você tenha gostado de ler esta postagem sobre Entrega Contínua. Se você tiver alguma dúvida, fique à vontade para colocá-las na seção de comentários abaixo e eu retornarei com uma resposta o mais breve possível.

Para construir pipelines de CI / CD, você precisa dominar uma ampla variedade de habilidades Domine as habilidades necessárias de DevOps agora