Implantação de Aplicativos Heroku em Ambientes de Staging e Produção com GitLab CI/CD

Tutoriais

GitLab

Em um artigo anterior, exploramos como automatizar implantações no Heroku usando GitLab CI/CD. Essa configuração implantava o aplicativo no seu ambiente de produção a cada vez que pushesávamos código para o branch main.

Neste artigo, vamos considerar uma abordagem ligeiramente mais sutil: E se temos múltiplos ambientes? A maioria das organizações de engenharia usa pelo menos três ambientes: um ambiente de desenvolvimento local, um ambiente de pré-produção e um ambiente de produção.

Além disso, algumas equipes de engenharia seguem uma estratégia de branches Gitflow, onde têm um branch dev e um branch main. Essa estratégia caiu em desuso e foi substituída pela desenvolvimento baseado em tronco, mas não é incomum encontrar organizações que ainda seguem essa prática.

Hoje, vamos ver como configurar o GitLab CI/CD para implantar nosso aplicativo no ambiente de pré-produção quando fazemos push na branch dev e implantar nosso aplicativo no ambiente de produção quando fazemos push na branch main.

Início

Antes de começar, precisaremos de duas coisas: uma conta do Heroku e uma conta do GitLab.

O Heroku é um ótimo lugar para hospedar e implantar seus aplicativos. Como uma plataforma como serviço (PaaS), o Heroku permite que você se concentre em construir coisas legais, abstractando muita complexidade de infraestrutura. Você pode criar uma conta do Heroku aqui.

O GitLab é um ótimo lugar para armazenar seu código. Além de ser apenas uma ferramenta de gerenciamento de código-fonte, o GitLab também oferece capacidades nativas de CI/CD, para que você possa configurar pipelines para testar e implantar seu código sem precisar de outra ferramenta de terceiros. Você pode criar uma conta do GitLab aqui.

O aplicativo de demonstração mostrado neste artigo usa tanto o GitLab quanto o Heroku. Você pode encontrar todo o código no repositório do GitLab aqui.

Executando Nosso App Localmente

Você pode executar o aplicativo localmente克隆ando o repositório, instalando as dependências e executando o comando de inicialização. No seu terminal, faça o seguinte:

$ git clone https://gitlab.com/tylerhawkins1/heroku-gitflow-staging-production-gitlab-cicd-demo.git
$ cd heroku-gitflow-staging-production-gitlab-cicd-demo
$ npm install
$ npm start

Após iniciar o aplicativo, acesse este host local no seu navegador, e você verá o aplicativo rodando localmente:

Aplicativo Demo Heroku

Implantando Nosso Aplicativo no Heroku

Agora que o aplicativo está rodando localmente, vamos implantá-lo no Heroku para que você possa acessá-lo de qualquer lugar, não apenas no seu computador.

Lembre-se de que vamosimplantar seu aplicativo tanto em um ambiente de pré-produção quanto em um ambiente de produção. Isso significa que teremos dois aplicativos Heroku baseados no mesmo repositório GitLab.

Se você ainda não tiver o Heroku CLI instalado no seu computador, precisará instalá-lo antes de prosseguir.

Após instalar o Heroku CLI, execute os seguintes comandos do terminal para verificar o branch main, criar um novo aplicativo Heroku de produção, implantá-lo no seu ambiente de produção e abri-lo no seu navegador:

$ git checkout main
$ heroku create heroku-gitlab-ci-cd-production --remote heroku-production
$ git push heroku-production main
$ heroku open --remote heroku-production

Com isso, você deve ver o mesmo aplicativo, mas desta vez rodando em um URL do Heroku em vez de no localhost. Bom trabalho — você implantou seu aplicativo Heroku em produção!

Mas, ainda não estamos prontos. Também precisamos configurar e implantar seu aplicativo de pré-produção. Para fazer isso, execute o seguinte conjunto de comandos semelhantes mostrados abaixo:

$ git checkout dev
$ heroku create heroku-gitlab-ci-cd-staging --remote heroku-staging
$ git push heroku-staging main
$ heroku open --remote heroku-staging

Agora você terá o mesmo aplicativo implantado novamente, mas dessa vez em um URL diferente que servirá como seu ambiente de pré-produção. Agora temos ambos os seus ambientes configurados!

Notem as diferenças e semelhanças entre os comandos para o aplicativo de produção e o aplicativo de pré-produção:

O aplicativo de produção usa o branch main, e o aplicativo de pré-produção usa o branch dev.
O aplicativo de produção é chamado heroku-gitlab-ci-cd-production, e o aplicativo de pré-produção é chamado heroku-gitlab-ci-cd-staging.
O remote git do aplicativo de produção é chamado heroku-production, e o remote git do aplicativo de pré-produção é chamado heroku-staging.
Ambos os aplicativos de produção e de pré-produção usam um branch main para os remotes git, já que a Heroku apenas implanta o aplicativo quando o código é enviado para o seu branch principal.

Lembre-se de que este branch main é diferente do seu conjunto de branches main e dev. O branch main para o qual você está enviando é o branch main no seu remote git — neste caso, a Heroku.

Quando você está no seu branch local main e executa git push heroku-production main, você está empurrando o seu branch main para o branch main do app de produção do Heroku. E quando você está no seu branch local dev e executa git push heroku-staging main, você está empurrando o seu branch dev para o branch main do app de estágio do Heroku.

Fazendo Mudanças em Nosso App

Agora que temos nosso app do Heroku funcionando, e se quisermos fazer algumas mudanças? Seguindo uma approximação grosseira da estratégia de分支 do Gitflow, poderíamos fazer o seguinte:

Checkout no branch dev
Fazer mudanças no código
Adicionar, commit e empurrar essas mudanças para o branch dev
Implantar essas mudanças no app de estágio do Heroku executando git push heroku-staging main
Checkout no branch main
Mesclar o branch dev no branch main
Implantar essas mudanças no app de produção do Heroku executando git push heroku-production main

(Se realmente estivéssemos seguindo o Gitflow, teríamos criado um branch de feature para mesclar no dev, e um branch de release para mesclar no main, mas omitimos esses passos para manter as coisas simples.)

Agora, não seria bom se pudéssemos automatizar a implantação em qualquer um dos nossos ambientes em vez de ter que implantar manualmente sempre?

É aí que entra o GitLab CI/CD.

Integração Contínua/Implantação Contínua

A integração contínua (CI) é sobre commitar frequentemente e manter a compilação em um bom estado a todo momento. Tipicamente, você verificaria se a compilação está em um bom estado executando verificações em um pipeline de CI. Essas verificações podem incluir linters, testes unitários e/ou testes de integração completa.

A implantação contínua (CD) é sobre implantar frequentemente. Se as verificações no pipeline de CI passam, a compilação é implantada. Se as verificações no pipeline de CI falham, a compilação não é implantada.

Com GitLab CI/CD, podemos configurar nosso pipeline de CI para fazer exatamente isso — executar nossos testes e depois implantar nosso app no Heroku se todos os testes passarem. Mais importante para nossa configuração, podemos definir regras dentro do nosso pipeline de CI para especificar onde o app deve ser implantado.

Configurando GitLab CI/CD

Podemos criar um pipeline de CI no GitLab programaticamente usando um arquivo .gitlab-ci.yml. Nosso arquivo se parece com isso:

YAML

image: node:20.10.0

cache:
  paths:
    - node_modules/

before_script:
  - node -v
  - npm install

stages:
  - test
  - deploy

unit-test-job:
  stage: test
  script:
    - npm test

deploy-job:
  stage: deploy
  variables:
    HEROKU_APP_NAME: $HEROKU_APP_NAME_PRODUCTION
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      variables:
        HEROKU_APP_NAME: $HEROKU_APP_NAME_PRODUCTION
    - if: $CI_COMMIT_REF_NAME =~ /dev/
      variables:
        HEROKU_APP_NAME: $HEROKU_APP_NAME_STAGING
  script:
    - apt-get update -yq
    - apt-get install -y ruby-dev
    - gem install dpl
    - dpl --provider=heroku --app=$HEROKU_APP_NAME --api-key=$HEROKU_API_KEY

Pipelines de CI do GitLab consistem em estágios e jobs. Cada estágio pode conter um ou mais jobs. Em nosso pipeline, temos dois estágios: test e deploy. No estágio test, executamos nossos testes unitários no unit-test-job. No estágio deploy, implantamos nosso app no Heroku no deploy-job.

Só podemos avançar para o próximo estágio se todos os jobs no estágio anterior passarem. Isso significa que se os testes unitários falharem, o app não será implantado, o que é uma coisa boa! Não queremos implantar nosso app se ele estiver em um estado ruim.

Você notará que a etapa deploy possui uma seção rules comsome lógica condicional em vigor. É aqui que especificamos para qual ambiente nossaplicação deve ser implantada. Se estamos no branch main, entãoimplantamos nossa aplicação de produção. Se estamos no branch dev,então implantamos nossa aplicação de estágio.

Você também notará que a etapa deploy faz referência a várias variáveischamadas $HEROKU_APP_NAME_PRODUCTION, $HEROKU_APP_NAME_STAGINGe $HEROKU_API_KEY. Essas estão armazenadas como variáveis CI/CDdentro do GitLab.

Se você está configurando isso em sua própria conta GitLab, precisará primeiramenteencontrar sua chave API em sua conta Heroku. Dentro das configurações da suaconta Heroku, você deve ver uma seção para sua chave API. Se ainda não gerou uma chaveAPI, gere uma agora.

Em seguida, no seu projeto GitLab, clique em Configurações > CI/CD> Variáveis. Expanda essa seção e adicione três novas variáveis:

O valor para $HEROKU_API_KEY será a chave API da sua conta Heroku.
O valor para $HEROKU_APP_NAME_PRODUCTION será o nome da suaaplicação de produção no Heroku. O nome da minha aplicação de produção éheroku-gitlab-ci-cd-production, mas, como os nomes de aplicativosHeroku são universalmente únicos, o seu será algo diferente.
O valor para $HEROKU_APP_NAME_STAGING será o nome do seu app Heroku de homologação. O nome do meu app de homologação é heroku-gitlab-ci-cd-staging. Novamente, como os nomes dos apps Heroku são universalmente únicos, o seu será algo diferente.

Com isso, o seu pipeline GitLab CI está pronto para ser utilizado! Vamos testá-lo.

Implantando Nosso App Heroku no Ambiente de Homologação

Vamos verificar o branch dev e fazer uma alteração no código do nosso app. Eu fiz uma mudança simples no texto do cabeçalho e adicionei várias novas linhas ao texto na interface do usuário. Você pode fazer uma mudança semelhante no seu código.

Agora, adicione, faça commit e empurre essa alteração para o branch dev. Isso iniciará o pipeline GitLab CI. Você pode visualizar o pipeline dentro do GitLab e ver o progresso em tempo real.

Se tudo correr bem, você deve ver que tanto as etapas test quanto deploy foram concluídas com sucesso. Agora, acesse o seu app Heroku hospedado no URL do ambiente de homologação. O pipeline GitLab CI cuidou de implantar o app para você, então você agora verá suas mudanças em tempo real no ambiente de homologação!

Com um ambiente de homologação configurado, você agora tem um ótimo lugar para testar manualmente seu código em um ambiente hospedado. Este também é um ponto perfeito para que os testadores de QA ou gerentes de produto verifiquem as mudanças antes que elas vão para produção.

Agora, acesse o URL do seu app de produção. Você notará que ele ainda está mostrando a antiga interface do usuário sem as mudanças mais recentes. Isso porque o pipeline GitLab CI apenas implantou as mudanças no ambiente de homologação, não no ambiente de produção.

Verificamos que o código está bom no nosso ambiente de pré-produção, então vamos promovê-lo para o ambiente de produção.

Implantando Nosso App Heroku no Ambiente de Produção

Vamos verificar o branch main e depois mesclar o branch dev no seu branch main. Você pode fazer isso através de um pull request ou executando git merge dev e depois git push.

Isso iniciará o pipeline do GitLab CI novamente, mas dessa vez ele estará se preparando para implantar seu app de produção.

Você também pode visualizar todas as execuções do pipeline na página de Pipelines no GitLab para ver as várias construções para seus branches dev e main:

Quando o pipeline terminar, acesse o URL do seu app Heroku em produção. Agora você deve ver suas mudanças também implantadas em produção. Parabéns!

Conclusão

A good CI pipeline allows you to ship new features quickly and confidently without manually managing the deployment process. Having multiple environments configured for local development, staging, and production gives you more control over where and when code is released.

Heroku e GitLab CI/CD permitem automatizar tudo isso para tornar seus processos DevOps uma brisa!

Source:
https://dzone.com/articles/deploying-heroku-apps-to-staging-and-production