Saiba mais sobre entrega contínua com o Bitbucket Pipelines

Neste guia, a gente vai ver como você pode usar Bitbucket Pipelines para adotar um fluxo de trabalho de entrega contínua. Leia mais! 

Sten Pittet Sten Pittet

Requisitos

Tempo:

30 minutos

Público-alvo:

Você é novo na entrega contínua e/ou no Bitbucket Pipelines

Pré-requisito:

Experimente grátis

Lançar um novo recurso é sempre um momento emocionante, pois você está prestes a dar novos recursos aos seus clientes. Mas também pode ser um exercício arriscado que requer muita preparação, deixando a equipe relutante em fazer esses lançamentos com frequência. E quanto mais você espera, mais difícil se torna implementar na produção. As mudanças estão se acumulando, é difícil entender o escopo da mudança, e vai ser difícil identificar as causas raiz se ocorrerem problemas na produção.

Uma maneira simples de eliminar o medo e o custo de implementar software é automatizá-lo e liberar alterações menores com mais frequência. Em primeiro lugar, você economizará inúmeras horas que normalmente são gastas preparando a versão. Porém, você reduzirá também o risco de implementar software ao ter um escopo muito menor para cada lançamento, tornando mais fácil monitorar ambientes e solucionar problemas.

Essa automação de implementação é algo que você pode fazer facilmente com o Bitbucket Cloud hoje. Para cada um dos repositórios, você pode configurar um pipeline que vai criar, testar e implementar seu código automaticamente em seus ambientes em cada push. Neste guia, a gente vai ver como você pode usar Bitbucket Pipelines para adotar um fluxo de trabalho de entrega contínua.

Entrega contínua vs. implementação contínua

Entrega contínua é a prática de garantir que seu código esteja sempre pronto para ser liberado, mesmo que você não esteja implementando todas as alterações na produção. Recomenda-se atualizar sua produção com a maior frequência possível para garantir que você mantenha o escopo das mudanças pequeno, mas, em última análise, você esteja no controle do ritmo de seus lançamentos.

Na implementação contínua, as novas alterações enviadas ao repositório são implementadas de forma automática na produção se passarem nos testes, o que dá mais ênfase (leia-se: pressão) à cultura de teste, mas é uma ótima maneira de acelerar o ciclo de feedback com os clientes.

Um diagrama mostrando a entrega contínua versus integração contínua (CI vs. CD) | Atlassian CI/CD

Como adotar um pipeline de entrega contínua

Neste exemplo, a gente vai criar um pipeline de entrega contínua simples que vai ser implementado automaticamente no ambiente de staging quando o build passar no teste. A gente vai ver duas estratégias diferentes para a implementação de produção: uma usando ramificações e solicitações pull e outra usando pipelines personalizados e gatilhos manuais.

Em ambos os exemplos, a gente vai usar um aplicativo Node.js simples que exibe uma mensagem "Hello World" no seu navegador. Você pode clonar e usar o código do aplicativo "Hello World!" abaixo para acompanhar este tutorial.

Vamos implementar este aplicativo em ambientes de staging e produção hospedados no Heroku usando ambos os métodos.

Um aplicativo básico Hello World | Atlassian CI/CD

Nosso próprio aplicativo Olá, Mundo básico

Preparando a implementação para o Heroku

Para começar, vai ser necessário adicionar algumas variáveis de ambiente aos Bitbucket Pipelines para que possamos implementar no Heroku:

  • HEROKU_API_KEY: Você pode encontrar sua chave de API em sua conta Heroku
  • HEROKU_STAGING: nome do seu ambiente de preparação
  • HEROKU_PROD: nome do seu ambiente de produção

Acesse Pipelines > Variáveis de ambiente nas configurações do repositório para adicionar todas essas variáveis.

Uma captura de tela da configuração do Heroku no Bitbucket | Atlassian CI/CD

Configuração de variáveis de ambiente para implementar no Heroku

Estamos usando Heroku neste guia, certamente é possível adaptar este exemplo a outros serviços de hospedagem. Você pode encontrar outros guias de implementação na documentação.

Entrega contínua com ramificações como portão para a produção

Essa configuração é adequada para equipes que têm ramificações de lançamento especiais que podem ser mapeadas para uma implementação. Ela também permite que você revise as alterações em uma solicitação pull antes que elas sejam implementadas na produção.

Nesta configuração, a gente vai usar 2 ramificações diferentes para acionar implementações:

  • Principal: qualquer push para o principal vai implementar o código em um ambiente de staging depois de executar os testes.
  • produção: a liberação do código mesclado à ramificação de produção para o ambiente de produção vai ser automática.

Primeiro, vamos configurar a implementação para staging. Para fazer essa ação, usamos os pipelines específicos da ramificação e criamos um pipeline que é executado para cada push na ramificação principal.

bitbucket-pipelines.yml

image: node:4.6.0   # Doing a full clone to be able to push back to Heroku. clone:   depth: full   pipelines:   branches:     # When code is pushed to the main branch it is deployed automatically to the staging environment.     main:       - step:           script:             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_STAGING.git main

Agora a gente criou um pipeline que vai implementar cada push para principal no Heroku depois de criar e testar o aplicativo. A seção clone no início da configuração garante que o clone seja completo (caso contrário, Heroku pode rejeitar o git push). Basta enviar essa configuração por push para o Bitbucket para ver a primeira implementação automatizada acontecendo no ambiente de staging.

Uma captura de tela de uma implementação de pipeline bem-sucedida | Atlassian CI/CD

Um pipeline bem-sucedido que implementa o aplicativo no ambiente de staging

Como você deve ter adivinhado, só precisamos adicionar outro pipeline de ramificação para a ramificação de produção a fim de lançar automaticamente o ambiente de produção quando as alterações forem mescladas na ramificação da produção.

bitbucket-pipelines.yml

image: node:4.6.0   # Doing a full clone to be able to push back to Heroku. clone:   depth: full   pipelines:   branches:     # When code is pushed to the main branch it is deployed automatically to the staging environment.     main:       - step:           script:             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_STAGING.git main     # When code is pushed to the main branch it is deployed automatically to the production environment.     production:       - step:           script:             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_PROD.git production:main  

A gente executou os testes de novo na ramificação de produção para garantir que nada afetou o build antes de lançar o aplicativo.

Nossos pipelines agora estão configurados e podemos restringir o branch de produção para aceitar apenas merges por meio de solicitações pull. Simplesmente vá para Fluxo de trabalho > Permissões de branch em suas configurações de repositório para restringir o branch de produção. Esta é uma etapa importante, pois queremos evitar que as pessoas passem direto para a produção a partir de seus computadores locais.

Como configurar as permissões da ramificação de produção | Atlassian CI/CD

Como configurar as permissões da ramificação de produção

Na captura de tela acima, você pode ver as permissões:

  • Ninguém tem acesso de gravação
  • Apenas um desenvolvedor pode mesclar para a ramificação

A gente também adicionou uma verificação de mesclagem para garantir que a ramificação de origem tenha pelo menos um build verde antes de mesclar o código. Assim a gente vai poder economizar tempo de compilação e impedir que os desenvolvedores mesclem código ruim para a ramificação de produção.

Quando estiver pronto, você pode criar uma solicitação pull para fazer o merge do código do main para a production e, depois, lançar as alterações novas no ambiente de produção.

Uma captura de tela do Bitbucket de como criar uma solicitação pull | Atlassian CI/CD

Crie uma solicitação pull para mesclar alterações na produção

Assim que você mescla a solicitação pull, pode ver um novo pipeline ser acionado para o branch de produção.

Um pipeline foi acionado com êxito pela solicitação pull | Atlassian CI/CD

Quando concluir, as novas alterações vão ter sido implementadas com êxito no ambiente de produção.

O ambiente de produção está atualizado!

Agora você configurou um fluxo de trabalho de entrega contínua com o Bitbucket Pipelines e pode usar com segurança solicitações pull para lançar o código para seus clientes.

Você pode encontrar a fonte final deste exemplo no repositório vinculado abaixo.

Entrega contínua com acionador manual para o lançamento

Essa configuração é ótima para equipes que estão praticando o desenvolvimento baseado no tronco.

Com o Bitbucket Pipelines, é possível configurar pipelines personalizados com possibilidade de acionamento manual. Eles podem ser usados para vários fins: testes de longa duração que você não quer executar em cada push, ou ações específicas que você quer controlar por conta própria. A gente vai usar um pipeline personalizado para configurar um fluxo de trabalho de entrega contínua no qual a implementação de push para a ramificação principal em um ambiente de staging seja automática, e a implementação dos commits no ambiente de produção pode ser manual.

Primeiro, precisamos configurar a implementação automática no ambiente de staging. Você só precisa adicionar um pipeline específico da ramificação para o principal que vai implementar o ambiente de staging.

bitbucket-pipelines.yml

image: node:4.6.0   # Doing a full clone to be able to push back to Heroku. clone:   depth: full   pipelines:   branches:     main:       - step:           script: # Modify the commands below to build your repository.             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_STAGING.git main  

Você pode enviar essa configuração por push para o repositório para ver a primeira implementação de staging em ação.

Primeira implementação automática de staging

Agora que a implementação no ambiente de staging está configurada, a gente pode só adicionar um pipeline personalizado à configuração bitbucket-pipelines.yml que a gente vai usar para acionar a versão para produção manualmente.

bitbucket-pipelines.yml

image: node:4.6.0   # Doing a full clone to be able to push back to Heroku. clone:   depth: full   pipelines:   branches:     main:       - step:           script: # Modify the commands below to build your repository.             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_STAGING.git main   custom:     prod-deployment:       - step:           script:             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_PROD.git main  

Depois de enviar a nova configuração para o repositório do Bitbucket por push, você pode ir para o commit e clicar no link Executar pipeline sob as informações do commit para acionar a implementação para produção.

A ação Executar pipeline vai listar os pipelines personalizados disponíveis

Basta pressionar o botão Executar e você vai ser redirecionado para o pipeline de implementação de produção, onde você pode monitorar os registros.

Na seção de informações do commit do pipeline, você pode ver o nome do pipeline personalizado que foi usado. Agora você está pronto para usar sua nova configuração do Bitbucket Pipelines para entrega contínua e pode verificar seu Hello World na produção para garantir que tudo correu bem!

O Hello World foi implementado na produção usando um acionador manual

Você pode encontrar a fonte final deste exemplo no repositório vinculado abaixo.