Base de conhecimento  /  Gerenciador de aplicativos em nuvem  /  Integração com Jenkins
Base de conhecimento  /  Gerenciador de aplicativos em nuvem  /  Integração com Jenkins

Configurar CI/CD com o Cloud Application Manager, Jenkins e Bitbucket


Código do artigo: kb/416

Configurar CI/CD com o Cloud Application Manager, Jenkins e Bitbucket

O plugin Jenkins do Cloud Application Manager automatiza CI/CD em qualquer nuvem e SCM. Neste artigo, usamos Bitbucket como SCM.

Observação: Observação: para começar, você precisa de um servidor Jenkins com os plugins do Bitbucket e Cloud Application Manager.

Para adicionar etapas de compilação do Cloud Application Manager em trabalhos do Jenkins, vá para a página de trabalho. Em Compilar, clique em Adicionar etapa de compilação e selecione uma etapa de implementação, gerenciamento ou atualização do Cloud Application Manager.

Neste artigo:

  • Requisitos anteriores
  • Configurar o ambiente de integração contínua
  • Reagir a mudanças no Bitbucket
  • Ciclo de vida da solicitação pull
  • Requisitos anteriores

Requisitos anteriores

  1. Você precisará de um repositório Bitbucket.

    Exemplo: Exemplo: Neste repositório você pode encontrar um aplicativo Java Web:

    jenkins-bitbucket-1.png

    O repositório foi clonado no ambiente local:

    jenkins-bitbucket-2.png

  2. Você precisará de uma instância do Jenkins em funcionamento.
    No nosso caso, vamos implementar a última versão estável do Jenkins usando uma caixa criada no Cloud Application Manager. Criamos esta caixa para uso futuro quando precisarmos provisionar um ambiente Jenkins novamente. Neste ponto, tudo o que precisamos fazer é implementar esta caixa e um master do Jenkins com todas as configurações do plugin que será configurado em poucos minutos.

    jenkins-bitbucket-3.png

  3. Precisaremos de um Apache Tomcat 0.1.

    Para simplificar, decidimos criar uma caixa tomcat no Cloud Application Manager para implementar o servidor apache tomcat.

    jenkins-bitbucket-4.png

Configurar o ambiente de integração contínua

O objetivo é demonstrar como é fácil configurar um ambiente de integração contínua usando o Jenkins, o plugin Jenkins do Cloud Application Manager e o Bitbucket como repositório.

Abaixo, um diagrama do fluxo de trabalho e como todos os componentes trabalham juntos.

jenkins-bitbucket-5.png

  1. Configure a instância do Jenkins (no nosso caso, vamos implementar a caixa que criamos anteriormente).

    • Implemente a caixa.

    jenkins-bitbucket-6.png

    • Escolha a caixa de política da implementação.

    jenkins-bitbucket-7.png

    • Implementada.
  2. Configure a nuvem do Cloud Application Manager na seção Gerenciador do Jenkins.

    jenkins-bitbucket-8.png

    • Na seção de nuvem, adicionamos a nuvem do Cloud Application Manager:

    jenkins-bitbucket-9.png

  3. Crie um trabalho no Jenkins para ver todas as partes trabalhando juntas.

    jenkins-bitbucket-10.png

  4. Agora vamos configurar o trabalho:

    jenkins-bitbucket-11.png

  5. Na seção Gerenciamento de código-fonte, temos que configurar o repositório Bitbucket (o Git deve estar instalado no nó Jenkins):

    jenkins-bitbucket-12.png

    Neste caso, o URL será: https://cgarciadelpozo@bitbucket.org/oserna/hello-world-war.git
    Insira suas credenciais para acessar o repositório.

    jenkins-bitbucket-13.png

  6. Na seção Compilar, adicionamos uma etapa de criação do DeployBox para implementar nossa caixa Tomcat criada anteriormente.

    jenkins-bitbucket-14.png

    jenkins-bitbucket-15.png

    No esquema anterior, você viu que selecionamos a caixa Tomcat com sua versão mais recente. Também adicionamos a tag "tomcat" a essa instância para fácil localização em nossa nuvem. Nesse caso, selecionamos implementar essa caixa no Google Compute Engine (GCE) usando a caixa de política de implementação abaixo:

    jenkins-bitbucket-16.png

  7. Agora, uma vez configurada a caixa Tomcat que será implementada, precisamos criar o código-fonte que baixamos anteriormente do repositório Bitbucket. Usando um trabalho do Jenkins de estilo livre e não um trabalho maven Jenkins, teremos que criar um compilador de etapa de script shell:

    jenkins-bitbucket-17.png

    O Apache Maven deve ser previamente instalado e adicionado ao caminho para executar a ordem:

        mvn clean install
    

    Como você deve ter notado, o último comando no shell implementa o pacote just war criado no Tomcat.

    curl -v -T ${artifact} 'http://manager:manager@'${tomcat_host}':'${tomcat_port}'/manager/text/deploy?path=/'${context_path}''
    
  8. Vamos ver como isso funciona:

    • O trabalho recebe o código do repositório:

    jenkins-bitbucket-19.png

    • Na próxima etapa, o trabalho implementa a caixa tomcat.

    jenkins-bitbucket-20.png

    • Agora o trabalho executa a compilação.

    jenkins-bitbucket-21.png

    jenkins-bitbucket-22.png

    • Observe que ele finalmente implementa o pacote war no servidor Tomcat.

    jenkins-bitbucket-23.png

    • E funciona!

    jenkins-bitbucket-24.png

  9. Todas as partes trabalhando em conjunto.

    jenkins-bitbucket-25.png

  10. Tomcat implementado com plugin Jenkins do Cloud Application Manager.

    jenkins-bitbucket-26.png

Reagir a mudanças no Bitbucket

Em nosso caso anterior, passamos algum tempo configurando nosso ambiente de integração contínua. Começamos usando o Jenkins, o Bitbucket e o plugin Jenkins do Cloud Application Manager, e até agora estamos indo bem. Nosso próximo objetivo é configurar um hook de serviço Bitbucket para acionar nossas compilações.

jenkins-bitbucket-27.png

No trabalho que criamos ao configurar nosso ambiente de integração contínua, ativamos as notificações quando uma alteração é feita no repositório Bitbucket. Fazemos isso na seção do acionador de Compilação na página de trabalhos de configuração.

jenkins-bitbucket-28.png

Agora temos que fazer as alterações apropriadas para habilitar os hooks do repositório Bitbucket. Adicionando webhooks apontando para o nosso servidor de CI Jenkins.

jenkins-bitbucket-29.png

Fazemos uma alteração em nosso código-fonte (previamente clonado do repositório) dentro de um ambiente local por uma nova tag de parágrafo HTML.

jenkins-bitbucket-30.png

Após a alteração (o recurso), fazemos a confirmação em nosso repositório local e o push é feito no repositório remoto do Bitbucket.

jenkins-bitbucket-31.png

jenkins-bitbucket-32.png

Após o envio para o repositório do Bitbucket, o trabalho é acionado.

jenkins-bitbucket-33.png

Confirmaremos que o resultado é o esperado, o pacote foi criado e implementado corretamente no servidor Tomcat.

jenkins-bitbucket-34.png

Podemos ver que nossa alteração está pronta para ser testada. Sim! Nosso novo parágrafo está lá.
Veja a página Olá Mundo servida pelo Tomcat.

jenkins-bitbucket-35.png

Apenas o fato de estar ciente das alterações push em seu repositório oferece muitas possibilidades de gerenciamento, dependendo do tipo de fluxo de trabalho de desenvolvimento em sua empresa. Você tem que decidir quais ganchos de push acionarão trabalhos do Jenkins. Tais cenários, como todos os eventos push capazes de acionar um trabalho do Jenkins ou de impulsionar atividades específicas de eventos em um ramo específico realmente dependem do seu fluxo de trabalho de desenvolvimento e podem ser personalizados com base em seus negócios. Como você pode imaginar, o evento push é a maneira mais simples e mais detalhada de lidar com um evento. Por exemplo, tome o seguinte fluxo de trabalho clássico do Git abaixo:

jenkins-bitbucket-36.png

Portanto, supondo que você esteja usando uma ramificação que serve como uma ramificação de integração para recursos (isso é a ramificação roxa no esquema acima), pode ser o suficiente (da perspectiva do Jenkins) ser notificado sobre os pushes na ramificação de integração. Um trabalho Jenkins será disparado toda vez que uma nova confirmação for adicionada à ramificação de integração. O trabalho também pode enviar um e-mail para quem você quiser notificar sobre o resultado da compilação ou outras ações que o trabalho é capaz de fazer. No entanto, melhores modelos de integração seriam mais eficazes se pudéssemos estar cientes (no Jenkins) das diferentes fases do ciclo de vida da solicitação pull. Vamos agora analisar o processo a seguir.

Ciclo de vida da solicitação pull

Como você provavelmente sabe, as solicitações pull são uma ferramenta para os desenvolvedores notificarem o restante da equipe quando um novo recurso é concluído. Isso faz com que todos saibam que precisam revisar o código antes de mesclá-lo da ramificação de recursos para o master. Portanto, estar ciente de cada confirmação no repositório, como fizemos no capítulo anterior, é muito bom, mas se for possível criar solicitações pull do Bitbucket e relatar os resultados do teste, isso seria ainda melhor. Abaixo, você pode ver o ciclo de vida da solicitação pull como parte de nossa visão sobre como o CI e CD podem ser implementados.

jenkins-bitbucket-37.png

Na imagem abaixo, você pode ver a implementação mais simples do ciclo anterior, que será o nosso exemplo de trabalho que percorreremos nesta configuração.

jenkins-bitbucket-38.png

Há várias maneiras de conseguir esse tipo de integração, dependendo do mecanismo envolvido, seja ele de polling ou pushing, e do tipo de repositório que você está usando, servidor Stash ou Bitbucket.

Sinta-se à vontade para consultar as páginas wiki quanto à abordagem mais simples para o uso desses plugins Jenkins juntos:

Neste caso, nosso servidor Jenkins pesquisará o repositório Bitbucket de acordo com o intervalo de tempo escolhido. Criamos um trabalho Jenkins para demonstrar como funciona este método que vai configurar o SCM como visto na seção abaixo:

jenkins-bitbucket-39.png

Também precisamos configurar a parte relacionada ao Bitbucket Pull Request Builder na seção "Acionadores de compilação":

jenkins-bitbucket-40.png

Depois de configurar nossos plugins, veremos o resultado a partir da perspectiva do Bitbucket. Então, toda vez que criamos um novo recurso em uma nova ramificação, criamos o "master_branch_feature_0" contendo a confirmação 1:

jenkins-bitbucket-41.png

Ao criar a solicitação pull no Bitbucket, isso é o que veremos:

jenkins-bitbucket-42.png

O interior da confirmação:

jenkins-bitbucket-43.png

Observe que o build foi disparado devido à confirmação 0.

jenkins-bitbucket-45.png

A ramificação que está sendo verificada é a master_branch_feature_0.

jenkins-bitbucket-46.png

E assim que a compilação terminar, você verá o resultado no Bitbucket.

jenkins-bitbucket-47.png

A notificação do resultado da compilação:

jenkins-bitbucket-48.png

Para fins de simplicidade, decidimos usar a combinação de plugins que você viu acima, mas há algumas outras maneiras de integrar o Bitbucket e o Jenkins.

  • Serviço POST no Bitbucket (baseado em push).

    jenkins-bitbucket-49.png

    Como visto acima, Gerenciamento de pós-serviço está obsoleto a favor dos webhook 2.0. Como visto acima, o gerenciamento de serviços POST foi descontinuado em favor dos Webhooks 0.1. Por favor, note que o plugin Bitbucket Jenkins só funciona para eventos push do Bitbucket e não para eventos de solicitação pull.

  • Serviço de agente de CI Jenkins (também baseado em push).

    jenkins-bitbucket-50.png

    Atualmente, o Suporte da Atlassian não fornece assistência para essa configuração. Além disso, como você notará, eles redirecionam para o plugin do Jenkins Bitbucket, mas esse plugin só funciona para eventos push do Bitbucket, não para eventos de solicitação pull.

  • Com outra combinação de plugins, você também pode gerenciar o ciclo de vida da solicitação pull. Por exemplo, usando esses plugins (com o Stash, mas não com o Bitbucket):

    1. Plugin Git Jenkins

    2. Plugin Pre SCM Buildstep Jenkins

    3. Plugin Stash Notifier Jenkins

    4. Plugin Pull Request Notifier Stash

Veja todos os detalhes aqui.

Como contatar o suporte do Cloud Application Manager

Lamentamos que você tenha encontrado um problema com o Cloud Application Manager. Consulte as dicas de troubleshooting ou entre em contato com o suporte do Cloud Application Manager e apresente detalhes e capturas de tela, conforme possível.

Para problemas relacionados a chamadas de API, envie o corpo da solicitação junto com os detalhes referentes ao problema.

Em caso de erro de caixa, compartilhe a caixa no espaço de trabalho que sua organização e o Cloud Application Manager podem acessar e anexe os registros.

  • Linux: SSH e localize o registro em /var/log/elasticbox/elasticbox-agent.log
  • Windows: Windows: RDP na instância para localizar o registro em ProgramData/ElasticBox/Logs/elasticbox-agent.log
Powered by Translations.com GlobalLink OneLink SoftwarePowered By OneLink