Neste tutorial, veja como configurar e usar um sistema de desenvolvimento, integração contínua (CI) e entrega contínua (CD) com um conjunto integrado de ferramentas do Google Cloud. Use esse sistema para desenvolver e implantar aplicativos no Google Kubernetes Engine (GKE).
Neste guia, mostramos como criar a arquitetura descrita no Pipeline de implantação para desenvolvimento e entrega de aplicativos em contêineres.
Este guia de implantação é destinado a desenvolvedores e operadores de software, e você desempenha os seguintes papéis à medida que o conclui:
- Primeiro, você vai atuar como operador para configurar o pipeline de CI/CD. Os principais componentes desse pipeline são o Cloud Build, o Artifact Registry e o Cloud Deploy.
- Depois, você vai atuar como desenvolvedor para alterar um aplicativo usando o Cloud Code. Ao atuar como desenvolvedor, você vai ver a experiência integrada que esse pipeline oferece.
- Por fim, você vai atuar como operador e seguir as etapas para implantar um aplicativo na produção.
Para seguir este tutorial, você precisa saber executar comandos do gcloud
no
Google Cloud e implantar contêineres de aplicativos no
GKE.
Arquitetura
O diagrama a seguir mostra os recursos usados neste guia de implantação:
Para detalhes sobre os componentes usados nessa arquitetura, consulte Pipeline de implantação para desenvolvimento e entrega de aplicativos em contêineres.
Objetivos
Ao atuar como operador, você vai fazer o seguinte:
- Configurar o pipeline de CI e o de CD. Essa configuração inclui:
- Configurar as permissões necessárias.
- Criar os clusters do GKE para os ambientes de preparo e de produção.
- Criar um repositório no Cloud Source Repositories para o código-fonte.
- Criar um repositório no Artifact Registry para o contêiner do aplicativo.
- Criar um gatilho do Cloud Build no repositório principal do GitHub.
- Criar um pipeline de entrega do Cloud Deploy e os destinos. Os destinos são o ambiente de preparo e de produção.
- Iniciar o processo de CI/CD para implantar no preparo e depois promover para a produção.
Como desenvolvedor, você vai fazer uma alteração no aplicativo. Para isso, faça o seguinte:
- Clone o repositório para trabalhar com um ambiente de desenvolvimento pré-configurado.
- Faça uma alteração no aplicativo no espaço de trabalho do desenvolvedor.
- Crie e teste a alteração. Os testes incluem um teste de validação para governança.
- Visualize e valide a alteração em um cluster de desenvolvimento. Esse cluster é executado no minikube.
- Confirme a alteração no repositório principal.
Custos
Neste documento, você usará os seguintes componentes faturáveis do Google Cloud:
- Cloud Build
- Cloud Deploy
- Artifact Registry
- Google Kubernetes Engine
- Cloud Source Repositories
- Cloud Storage
Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços.
Ao concluir as tarefas descritas neste documento, é possível evitar o faturamento contínuo excluindo os recursos criados. Saiba mais em Limpeza.
Antes de começar
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
-
Enable the Artifact Registry, Cloud Build, Cloud Deploy, Cloud Source Repositories, Google Kubernetes Engine, Resource Manager, and Service Networking APIs.
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
Preparar o ambiente
Nesta seção, você vai atuar como o operador do aplicativo e fazer o seguinte:
- Configurar as permissões necessárias.
- Criar os clusters do GKE para os ambientes de preparo e de produção.
- Clonar o repositório de origem.
- Criar um repositório no Cloud Source Repositories para o código-fonte.
- Criar um repositório no Artifact Registry para o aplicativo do contêiner.
Configurar permissões
Nesta seção, você vai conceder as permissões necessárias para configurar o pipeline de CI/CD.
Se você estiver trabalhando em uma nova instância do editor do Cloud Shell, especifique o projeto a ser usado neste tutorial:
gcloud config set project PROJECT_ID
Substitua PROJECT_ID pelo ID do projeto que você selecionou ou criou para este guia de implantação.
Se uma caixa de diálogo for exibida, clique em Autorizar.
Verifique se a conta de serviço padrão do Compute Engine tem permissões suficientes para executar jobs no Cloud Deploy e extrair contêineres do Artifact Registry. O Cloud Build e o Cloud Deploy usam essa conta de serviço padrão.
A conta de serviço já pode ter as permissões necessárias. Essa etapa garante que as permissões necessárias sejam concedidas aos projetos que desativam as concessões automáticas de papéis para contas de serviço padrão.
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:$(gcloud projects describe PROJECT_ID \ --format="value(projectNumber)")-compute@developer.gserviceaccount.com \ --role="roles/clouddeploy.jobRunner" gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:$(gcloud projects describe PROJECT_ID \ --format="value(projectNumber)")-compute@developer.gserviceaccount.com \ --role="roles/artifactregistry.reader"
Conceda o privilégio de conta de serviço do Cloud Build para invocar implantações com o Cloud Deploy e atualizar o pipeline de entrega e as definições de destino:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:$(gcloud projects describe PROJECT_ID \ --format="value(projectNumber)")@cloudbuild.gserviceaccount.com \ --role="roles/clouddeploy.operator"
Para mais informações sobre esse papel do IAM, consulte o papel clouddeploy.operator.
Conceda o privilégio de conta de serviço do Cloud Build e do Cloud Deploy para o GKE:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:$(gcloud projects describe PROJECT_ID \ --format="value(projectNumber)")-compute@developer.gserviceaccount.com \ --role="roles/container.admin"
Para mais detalhes sobre esse papel do IAM, consulte o papel container.admin.
Conceda à conta de serviço do Cloud Build as permissões necessárias para invocar operações do Cloud Deploy:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:$(gcloud projects describe PROJECT_ID \ --format="value(projectNumber)")@cloudbuild.gserviceaccount.com \ --role="roles/iam.serviceAccountUser"
Quando o Cloud Build invoca o Cloud Deploy, ele usa uma conta de serviço do Compute Engine para criar uma versão, o que torna esta permissão necessária.
Para mais detalhes sobre esse papel do IAM, consulte o papel iam.serviceAccountUser.
Você já concedeu as permissões necessárias para o pipeline de CI/CD.
Criar os clusters do GKE
Nesta seção, você vai criar os ambientes de preparo e de produção, que são clusters do GKE. Não é necessário configurar o cluster de desenvolvimento aqui, porque ele usa o minikube.
Crie os clusters do GKE de preparo e de produção:
gcloud container clusters create-auto staging \ --region us-central1 \ --project=$(gcloud config get-value project) \ --async gcloud container clusters create-auto prod \ --region us-central1 \ --project=$(gcloud config get-value project) \ --async
O cluster de preparo é o local em que você testa as alterações no código. Depois de verificar se a implantação no preparo não afetou negativamente o aplicativo, implante na produção.
Execute o seguinte comando e verifique se a saída tem
STATUS: RUNNING
para os clusters de preparo e de produção:gcloud container clusters list
Recupere as credenciais para os arquivos
kubeconfig
dos clusters de preparo e de produção.gcloud container clusters get-credentials staging --region us-central1 gcloud container clusters get-credentials prod --region us-central1
Use essas credenciais para interagir com os clusters do GKE, como verificar se um aplicativo está sendo executado corretamente.
Você criou os clusters do GKE para os ambientes de preparo e de produção.
Abrir o ambiente de desenvolvimento integrado e clonar o repositório
Para clonar o repositório e visualizar o aplicativo no ambiente de desenvolvimento, faça o seguinte:
Clone o repositório do GitHub no Cloud Shell.
Clique em Confirmar.
O editor do Cloud Shell abre e clona o repositório de amostra.
Agora você pode ver o código do aplicativo no editor do Cloud Shell.
Especifique o projeto que será usado neste guia de implantação:
gcloud config set project PROJECT_ID
Se uma caixa de diálogo for exibida, clique em Autorizar.
Agora você tem o código-fonte do aplicativo no ambiente de desenvolvimento.
Esse repositório de origem inclui os arquivos do Cloud Build e do Cloud Deploy necessários para o pipeline de CI/CD.
Criar repositórios para o código-fonte e os contêineres
Nesta seção, você vai configurar um repositório no Cloud Source Repositories para o código-fonte e outro no Artifact Registry para armazenar os contêineres criados pelo pipeline de CI/CD.
Crie um repositório no Cloud Source Repositories para armazenar o código-fonte e vinculá-lo ao processo de CI/CD:
gcloud source repos create cicd-sample
Verifique se as configurações do Cloud Deploy se destinam ao projeto correto:
sed -i s/project-id-placeholder/$(gcloud config get-value project)/g deploy/* git config --global credential.https://source.developers.google.com.helper gcloud.sh git remote add google https://source.developers.google.com/p/$(gcloud config get-value project)/r/cicd-sample
Envie o código-fonte para o repositório:
git push --all google
Crie um repositório de imagens no Artifact Registry:
gcloud artifacts repositories create cicd-sample-repo \ --repository-format=Docker \ --location us-central1
Agora você tem um repositório para o código-fonte no Cloud Source Repositories e outro para o contêiner do aplicativo no Artifact Registry. O repositório do Cloud Source Repositories permite clonar e conectar o código-fonte ao pipeline de CI/CD.
Configurar o pipeline de CI/CD
Nesta seção, você vai atuar como o operador do aplicativo e configurar o pipeline de CI/CD. O pipeline usa o Cloud Build para CI e o Cloud Deploy para CD. As etapas do pipeline são definidas no gatilho do Cloud Build.
Crie um bucket do Cloud Storage para o Cloud Build para armazenar o arquivo
artifacts.json
, que rastreia os artefatos gerados pelo Skaffold para cada build:gcloud storage buckets create gs://$(gcloud config get-value project)-gceme-artifacts/
Armazenar o arquivo
artifacts.json
de cada build em um ponto central é uma prática recomendada, porque fornece rastreabilidade, o que facilita a solução de problemas.Analise o arquivo
cloudbuild.yaml
, que define o gatilho do Cloud Build e já está configurado no repositório de origem clonado.Esse arquivo define o gatilho invocado sempre que há um novo envio para a ramificação principal do repositório de código-fonte.
As etapas a seguir para o pipeline de CI/CD são definidas no arquivo
cloudbuild.yaml
:O Cloud Build usa o Skaffold para criar o contêiner do aplicativo.
O Cloud Build coloca o arquivo
artifacts.json
do build no bucket do Cloud Storage.O Cloud Build coloca o contêiner do aplicativo no Artifact Registry.
O Cloud Build executa testes no contêiner do aplicativo.
O comando
gcloud deploy apply
registra os seguintes arquivos com o serviço Cloud Deploy:deploy/pipeline.yaml
, que é o pipeline de entregadeploy/staging.yaml
edeploy/prod.yaml
, que são os arquivos de destino
Quando os arquivos são registrados, o Cloud Deploy cria o pipeline e os destinos, se ainda não existirem, ou os recria se a configuração mudou. Os destinos são os ambientes de preparo e de produção.
O Cloud Deploy cria uma nova versão para o pipeline de entrega.
Essa versão faz referência ao contêiner do aplicativo que foi criado e testado no processo de CI.
O Cloud Deploy implanta a versão no ambiente de preparo.
O pipeline de entrega e os destinos são gerenciados pelo Cloud Deploy e são separados do código-fonte. Essa separação significa que você não precisa atualizar o pipeline de entrega e os arquivos de destino quando é feita uma alteração no código-fonte do aplicativo.
Crie o gatilho do Cloud Build:
gcloud beta builds triggers create cloud-source-repositories \ --name="cicd-sample-main" \ --repo="cicd-sample" \ --branch-pattern="main" \ --build-config="cloudbuild.yaml"
Este gatilho instrui o Cloud Build a observar o repositório de origem e a usar o arquivo
cloudbuild.yaml
para reagir a qualquer alteração no repositório. O gatilho é invocado sempre que há um novo envio para a ramificação principal.Acesse a página de visão geral do Cloud Functions no console do Google Cloud.
Observe que não há compilações para seu aplicativo.
Você configurou os pipelines de CI e CD e criou um gatilho na ramificação principal do repositório.
Fazer uma alteração no aplicativo no espaço de trabalho do desenvolvedor
Nesta seção, você vai atuar como o desenvolvedor do aplicativo.
À medida que desenvolve o aplicativo, você faz e verifica alterações iterativas usando o Cloud Code como espaço de trabalho de desenvolvimento:
- Faça uma alteração no aplicativo.
- Crie e teste o novo código.
- Implante o aplicativo no cluster do minikube e verifique as alterações voltadas para o usuário.
- Envie a alteração para o repositório principal.
Quando essa alteração é confirmada no repositório principal, o gatilho do Cloud Build inicia o pipeline de CI/CD.
Criar, testar e executar o aplicativo
Nesta seção, você vai criar, testar, implantar e acessar o aplicativo.
Use a mesma instância do editor do Cloud Shell da seção anterior. Se o tiver fechado, abra o editor do Cloud Shell no navegador em ide.cloud.google.com.
No terminal, inicie o minikube:
minikube start
O minikube configura um cluster local do Kubernetes no seu Cloud Shell. Essa configuração leva alguns minutos para ser executada. Após a conclusão, o processo do minikube é executado em segundo plano na instância do Cloud Shell.
No painel na parte inferior do editor do Cloud Shell, selecione Cloud Code.
No painel fino que aparece entre o terminal e o editor, selecione Executar no Kubernetes.
Se você vir uma solicitação
Use current context (minikube) to run the app?
, clique em Sim.Esse comando cria o código-fonte e executa testes. Isso pode levar alguns minutos. Eles incluem testes de unidade e uma etapa de validação pré-configurada que verifica as regras definidas para o ambiente de implantação. Isso faz com que você receba avisos sobre problemas de implantação enquanto ainda está trabalhando no ambiente de desenvolvimento.
A guia Saída mostra o progresso do Skaffold durante a criação e a implantação do aplicativo.
Deixe essa guia aberta nesta seção.
Quando o build e os testes terminarem, a guia Saída vai mostrar
Update succeeded
e também dois URLs.À medida que você cria e testa o aplicativo, o Cloud Code faz o streaming dos registros e URLs na guia Saída. Ao fazer alterações e executar testes no ambiente de desenvolvimento, é possível ver a versão do aplicativo nesse ambiente e verificar se ele está funcionando corretamente.
A saída também mostra
Watching for changes...
, ou seja, o modo de observação está ativado. Enquanto o Cloud Code estiver no modo de observação, o serviço vai detectar todas as alterações salvas no seu repositório, bem como recriar e reimplantar automaticamente o aplicativo com as alterações mais recentes.No terminal do Cloud Code, mantenha o ponteiro do mouse sobre o primeiro URL da saída (
http://localhost:8080
).Na dica exibida, selecione Abrir visualização na Web.
Em segundo plano, o Cloud Code automaticamente faz o encaminhamento de portas do tráfego para o serviço
cicd-sample
em execução no minikube.No navegador, atualize a página.
O número ao lado de Contador aumenta, mostrando que o aplicativo está respondendo à atualização.
No navegador, mantenha esta página aberta para ver o aplicativo enquanto você faz alterações no ambiente local.
Você criou e testou seu aplicativo no ambiente de desenvolvimento. Você implantou o aplicativo no cluster de desenvolvimento em execução no minikube e viu o comportamento voltado para o usuário do aplicativo.
Faça uma alteração
Nesta seção, você vai fazer uma alteração no aplicativo e ver a alteração à medida que o aplicativo é executado no cluster de desenvolvimento.
No editor do Cloud Shell, abra o arquivo
index.html
.Procure e altere a string
Sample App Info
parasample app info
, para que o título fique em letras minúsculas.O arquivo é salvo automaticamente, acionando uma recriação do contêiner do aplicativo.
O Cloud Code detecta a alteração e a reimplanta automaticamente. A guia Saída mostra
Update initiated
. A reimplantação leva alguns minutos para ser executada.Esse recurso de reimplantação automática está disponível para qualquer aplicativo em execução em um cluster do Kubernetes.
Quando a criação estiver concluída, acesse o navegador em que o aplicativo está aberto e atualize a página.
Ao atualizar, observe que o texto agora está em letras minúsculas.
Essa configuração permite o recarregamento automático de qualquer arquitetura, com qualquer componente. Ao usar o Cloud Code e o minikube, tudo o que é executado no Kubernetes tem essa funcionalidade de recarga dinâmica de código.
É possível depurar aplicativos implantados em um cluster do Kubernetes no Cloud Code. Essas etapas não são abordadas neste guia de implantação, mas para detalhes, consulte Como depurar um aplicativo do Kubernetes.
Confirmar o código
Agora que você fez uma alteração no aplicativo, confirme o código.
Configure a identidade do Git:
git config --global user.email "YOU@EXAMPLE.COM" git config --global user.name "NAME"
Substitua:
- YOU@EXAMPLE.COM: o endereço de e-mail conectado à sua conta do GitHub.
- NAME: o nome conectado à sua conta do GitHub.
No terminal, confirme o código:
git add . git commit -m "use lowercase for: sample app info"
Não é necessário executar o comando
git push
agora. Isso será feito depois.
Ao trabalhar no ambiente de desenvolvimento, você fez uma alteração no aplicativo, criou e testou a alteração e verificou o comportamento voltado para o usuário dessas alterações. Os testes no ambiente de desenvolvimento incluem verificações de governança, que permitem corrigir problemas no ambiente de produção.
Neste tutorial, ao confirmar o código no repositório principal, você não vai precisar fazer uma revisão de código. No entanto, a revisão de código ou a aprovação de alterações são processos recomendados no desenvolvimento de software.
Saiba mais sobre as práticas recomendadas para a aprovação de alterações em Como otimizar a aprovação de alterações.
Implantar uma alteração na produção
Nesta seção, você vai atuar como o operador do aplicativo e fazer o seguinte:
- Acionar o pipeline de CI/CD, que implanta a versão no ambiente de preparo.
- Promover e aprovar a versão para a produção.
Iniciar o pipeline de CI/CD e implantar no preparo
Nesta seção, você vai iniciar o pipeline de CI/CD invocando o gatilho do Cloud Build. Esse gatilho é invocado sempre que uma alteração é confirmada no repositório principal. Também é possível iniciar o sistema de CI com um gatilho manual.
No editor do Cloud Shell, execute o seguinte comando para acionar um build:
git push google
Este build inclui a alteração feita em
cicd-sample
.Volte para o painel do Cloud Build e veja se um build foi criado.
Clique em Em execução: cicd-sample - cicd-sample-main no registro do build à direita e procure o texto azul que indica o início e o fim de cada etapa.
A Etapa 0 mostra a saída das instruções
skaffold build
eskaffold test
do arquivocloudbuild.yaml
. As tarefas de criação e teste da Etapa 0 (a parte de CI do pipeline) foram aprovadas. Portanto, as tarefas de implantação da Etapa 1 (a parte de CD do pipeline) passam a ser executadas.Esta etapa termina com a seguinte mensagem:
Created Cloud Deploy rollout ROLLOUT_NAME in target staging
Abra a página de pipelines de entrega do Cloud Deploy e clique no pipeline
cicd-sample delivery
.O aplicativo é implantado no preparo, mas não na produção.
Verifique se o aplicativo está funcionando no preparo:
kubectl proxy --port 8001 --context gke_$(gcloud config get-value project)_us-central1_staging
Esse comando configura um proxy do kubectl para acessar o aplicativo.
Acesse o aplicativo no Cloud Shell:
No editor do Cloud Shell, abra uma nova guia do terminal.
Envie uma solicitação para
localhost
se quiser aumentar um contador:curl -s http://localhost:8001/api/v1/namespaces/default/services/cicd-sample:8080/proxy/ | grep -A 1 Counter
É possível executar esse comando várias vezes e observar o incremento do valor do contador a cada vez.
Ao visualizar o aplicativo, observe que o texto alterado está na versão do aplicativo que você implantou no preparo.
Feche essa segunda guia.
Na primeira guia, pressione
Control+C
para interromper o proxy.
Agora você invocou o gatilho do Cloud Build para iniciar o processo de CI, que inclui criar o aplicativo, fazer a implantação no ambiente de preparo e executar testes para verificar se o aplicativo está funcionando no preparo.
O processo de CI é bem-sucedido quando o código é criado e aprovado em testes no ambiente de preparo. Em seguida, o processo de CI inicia o sistema de CD no Cloud Deploy.
Promover a versão para a produção
Nesta seção, você vai promover a versão do preparo para a produção. O destino de produção vem pré-configurado para exigir aprovação. Portanto, faça a aprovação manualmente.
Para seu próprio pipeline de CI/CD, é bom usar uma estratégia que inicie a implantação gradualmente antes de fazer uma implantação completa na produção. Iniciar a implantação gradualmente pode facilitar a detecção de problemas e, se necessário, a restauração de uma versão anterior.
Para promover a versão para a produção, faça o seguinte:
Abra a visão geral dos pipelines de entrega do Cloud Deploy e selecione o pipeline cicd-sample.
Promova a implantação do preparo para a produção. Para isso, siga estas etapas:
No diagrama do pipeline na parte superior da página, clique no botão azul Promover na caixa do preparo.
Na janela exibida, clique no botão Promover na parte inferior.
A implantação ainda não está em execução na produção. Ela está aguardando a aprovação manual necessária.
Aprove manualmente a implantação:
Na visualização do pipeline, clique no botão Revisar entre as caixas do preparo e da produção.
Na janela exibida, clique no botão Revisar.
Na janela seguinte, clique em Aprovar.
Volte à visão geral dos pipelines de entrega do Cloud Deploy e selecione o pipeline cicd-sample.
Depois que a visualização do pipeline mostrar a caixa da produção como verde (o que significa um lançamento bem-sucedido), verifique se o aplicativo está funcionando na produção configurando um proxy do kubectl usado para acessar o aplicativo:
kubectl proxy --port 8002 --context gke_$(gcloud config get-value project)_us-central1_prod
Acesse o aplicativo no Cloud Shell:
No editor do Cloud Shell, abra uma nova guia do terminal.
Aumente o contador:
curl -s http://localhost:8002/api/v1/namespaces/default/services/cicd-sample:8080/proxy/ | grep -A 1 Counter
É possível executar esse comando várias vezes e observar o incremento do valor do contador a cada vez.
Feche essa segunda guia do terminal.
Na primeira guia, pressione
Control+C
para interromper o proxy.
Você promoveu e aprovou a implantação na produção. O aplicativo com a alteração recente está sendo executado na produção.
Limpar
Para evitar cobranças na sua conta do Google Cloud pelos recursos usados no tutorial, exclua o projeto que contém eles ou mantenha o projeto e exclua os recursos individuais.
Opção 1: excluir o projeto
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
Opção 2: excluir os recursos individuais
Exclua o pipeline do Cloud Deploy:
gcloud deploy delivery-pipelines delete cicd-sample --region=us-central1 --force
Exclua o gatilho do Cloud Build:
gcloud beta builds triggers delete cicd-sample-main
Exclua os clusters de preparo e de produção:
gcloud container clusters delete staging gcloud container clusters delete prod
Exclua o repositório no Cloud Source Repositories:
gcloud source repos delete cicd-sample
Exclua os buckets do Cloud Storage:
gcloud storage rm -r gs://$(gcloud config get-value project)-gceme-artifacts/ gcloud storage rm -r gs://$(gcloud config get-value project)_clouddeploy/
Exclua o repositório no Artifact Registry:
gcloud artifacts repositories delete cicd-sample-repo \ --location us-central1
A seguir
- Saiba como implantar em uma instância particular do GKE em Como implantar em um cluster particular em uma rede de nuvem privada virtual.
- Veja práticas recomendadas sobre como automatizar suas implantações em:
- Automação de implantação para saber como implementar, melhorar e medir a automação da implantação.
- Automatize suas implantações usando o framework de arquitetura.
- Para saber mais sobre estratégias de implantação, consulte:
- Lance implantações gradualmente usando o framework de arquitetura.
- Estratégias de implantação e teste de aplicativos
- Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.