Como criar um pipeline de DevOps sem servidor para o Salesforce com o Cloud Build

Last reviewed 2021-02-22 UTC

Neste tutorial, mostramos como criar um pipeline de integração contínua/implantação contínua (CI/CD, na sigla em inglês) para o Salesforce usando o Salesforce Developer Experience (SFDX) e o Cloud Build. Os pipelines do Cloud Build usam a conteinerização. Os pipelines executam versões como uma série de etapas de versão, em que cada uma delas é executada em um contêiner do Docker. O pipeline pode escalonar verticalmente e reduzir o escalonamento vertical em resposta para carregar sem a necessidade de pré-provisionar servidores e oferece versões rápidas, consistentes e automatizadas.

Este tutorial se destina a qualquer pessoa responsável por projetar, desenvolver e manter fluxos de trabalho do DevOps em uma organização. Esses papéis podem incluir arquitetos, equipes de DevOps e engenheiros. As diferentes seções do documento ilustram partes do pipeline para papéis diferentes. Por exemplo, uma parte é para administradores e leads de DevOps e outra para desenvolvedores do Salesforce.

Ele pressupõe que você esteja familiarizado com o Salesforce DX, o Salesforce CLI, Git, GitHub, Docker, produtos do Google Cloud, como o Cloud Build, e os conceitos de conteinerização. Também pressupomos que você tenha uma conta do GitHub.

Os ciclos de vida de desenvolvimento de software podem variar muito. Neste tutorial, pressupomos que você siga uma metodologia de lançamento agile.

Objetivos

Configurar a experiência do desenvolvedor com o Salesforce.
Configurar uma estratégia de ramificação do Git.
Configurar o Cloud Build.
Executar o pipeline de CI/CD para o Salesforce usando as ferramentas de criação do Google Cloud e o GitHub.

Custos

Neste tutorial, usamos o seguinte componente faturável do Google Cloud:

Use a calculadora de preços para gerar uma estimativa de custo com base no uso previsto.

Também pode haver custos do Salesforce. Neste tutorial, você usa uma organização do Salesforce Developer Edition, que pode ser gratuita. Para obter mais informações, consulte a página do Salesforce sobre a Developer Edition.

Antes de começar

No console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.

Observação: se você não pretende manter os recursos criados neste procedimento, crie um projeto novo em vez de selecionar um que já existe. Depois de concluir essas etapas, é possível excluir o projeto. Para fazer isso, basta remover todos os recursos associados a ele.

Acessar o seletor de projetos
Verifique se a cobrança está ativada para o seu projeto do Google Cloud.
Ative a API Cloud Build.
Ative a API
No Console do Google Cloud, ative o Cloud Shell.

Ativar o Cloud Shell
Verifique se você tem uma conta do Salesforce que pode assumir o papel da organização do Dev Hub. Se você não tiver uma organização, crie uma conta do Developer Edition no site para desenvolvedores do Salesforce.

Ao concluir este tutorial, exclua os recursos criados para evitar o faturamento contínuo. Para obter mais informações, consulte Como fazer a limpeza.

Arquitetura

O diagrama a seguir ilustra a arquitetura do fluxo de trabalho de CI/CD que você cria neste tutorial. Nessa arquitetura, os projetos são organizados como versões. Os desenvolvedores que querem trabalhar em um recurso criam uma nova ramificação de recurso a partir de uma ramificação de versão.

Arquitetura do pipeline mostrando o fluxo de criação de uma ramificação, criação de uma solicitação de envio e mesclagem da alteração na ramificação principal. Várias etapas acionam jobs do Cloud Build.

O diagrama ilustra o seguinte fluxo:

Os desenvolvedores criam ramificações de recursos no GitHub para os recursos que estão desenvolvendo.
Os desenvolvedores concluem o trabalho de desenvolvimento e executam testes de unidade em organizações de rascunho do Salesforce.
Os desenvolvedores confirmam e enviam o trabalho de desenvolvimento para o repositório de código-fonte (GitHub neste tutorial).
Os desenvolvedores criam uma solicitação de envio para mesclar o trabalho deles na ramificação de versão.
A criação de uma solicitação de envio aciona automaticamente um job do Cloud Build para executar testes.
A equipe responsável (normalmente líderes de equipe) analisa e aprova as solicitações de envio para mesclar o trabalho de desenvolvimento na ramificação da versão.
Uma mesclagem na ramificação de versão aciona automaticamente um job do Cloud Build para implantar a base de código no controle de qualidade ou em outros ambientes do Salesforce.
Opcionalmente, testes e avaliações manuais são realizados em um ambiente de controle de qualidade.
A equipe responsável cria uma solicitação de envio para mesclar o código na ramificação main.
A solicitação de envio para a ramificação main aciona um job do Cloud Build para implantar o código na produção.

Os desenvolvedores que querem trabalhar em projetos começam clonando o repositório do projeto da ferramenta de controle de origem empresarial (GitHub neste tutorial). O diagrama a seguir representa essa estratégia como um gráfico.

Estratégia de ramificação mostrada como um conjunto de versões, em que uma ramificação é dividida em várias ramificações de recursos, que são mescladas separadamente em uma ramificação da versão e, a partir daí, para a ramificação principal.

Conforme ilustrado no diagrama, a estratégia de ramificação consiste no seguinte:

Uma ramificação principal. O código na ramificação principal reflete a versão atual do código em execução na produção.
Uma ramificação da versão. Uma ramificação de versões é relativamente mais longa (em comparação com uma ramificação de recursos) que coordena todas as alterações e códigos necessários para uma versão. Uma organização cria uma nova ramificação de versão para cada nova versão.
Uma ou mais ramificações de recursos. As ramificações de recursos ajudam a isolar o trabalho em andamento da versão mais atualizada do código na ramificação principal. Normalmente, várias ramificações de recursos formam uma ramificação de versão. É uma prática recomendada para os desenvolvedores criarem ramificações de recursos para correções de bugs.

Depois que os desenvolvedores clonam um repositório de projeto, eles desenvolvem em suas máquinas locais ou em uma organização de rascunho do Salesforce. Eles podem usar uma organização de rascunho para executar testes de unidade nas alterações que fazem. Se os testes de unidade forem aprovados, eles confirmarão o código e o enviarão para o repositório do código-fonte. Em seguida, eles geram uma solicitação de envio para que o código seja mesclado na ramificação de versão principal.

A solicitação de envio aciona automaticamente um job do Cloud Build que realiza as ações a seguir:

Cria uma nova organização de rascunho para executar testes de unidade.
Atualiza a solicitação de envio com o resultado dos testes.

Nesse momento, os líderes de equipe e os proprietários dos produtos podem avaliar a solicitação de envio. Se a solicitação for aprovada, as alterações serão mescladas na ramificação de versão.

Dependendo do ciclo de vida de desenvolvimento do software, é possível ter outras etapas automatizadas acionadas com base em uma mescla para a ramificação de versão. Exemplos de etapas automatizadas são implantar o código validado em um sandbox maior, como garantia de qualidade ou sandboxes de teste de integração do sistema.

Também é possível configurar o Cloud Build para enviar notificações de versão e realizar outras ações usando o Cloud Functions, o Cloud Run ou outras ferramentas do Google Cloud. (Essas ações adicionais não são abordadas neste tutorial.) Essa abordagem oferece a flexibilidade para adaptar o pipeline e adaptar o framework do DevOps de sua empresa.

Para simplificar, neste tutorial você implantará a base do código de amostra em uma única organização do Salesforce (Dev Hub). Ao criar um pipeline de CI/CD para produção, você usa a arquitetura ilustrada anteriormente e automatiza implantações para sandboxes que fazem parte do ciclo de desenvolvimento de software.

Perfis que, normalmente, estão envolvidos no desenvolvimento de software

Cada organização é diferente e cada uma tem sua própria matriz de papéis e equipes. A tabela a seguir lista os perfis (papéis) principais que costumam interagir com os pipelines do Salesforce DevOps, como o descrito neste tutorial.

Pessoas em diferentes papéis têm diferentes responsabilidades para configurar os pipelines da Salesforce. Portanto, o tutorial tem dois caminhos. Um caminho é para administradores e líderes de DevOps, e o outro é para desenvolvedores.

Perfil	Responsabilidades
Administrador ou líder de DevOps	Configura a organização do Dev Hub. Gera certificados que permitem que os usuários se conectem à organização do Dev Hub a partir da CLI do Salesforce. Cria apps conectados em todos os ambientes do Salesforce em que o código é implantado usando o pipeline de DevOps. Configura as contas de desenvolvedor na organização do Dev Hub. Configura o pipeline de DevOps e os acionadores necessários. Inicializa o repositório do código-fonte. Configura os acionadores do Cloud Build.
Desenvolvedor do Salesforce	Clona o repositório do código-fonte. Configura a CLI do Salesforce para desenvolvimento. Desenvolve e faz testes de unidade nos recursos de uma versão. Quando os recursos são concluídos, gera uma solicitação de envio para mesclar os recursos na ramificação da versão.
Lead de controle de qualidade	Analisa e aprova solicitações de envio para mesclar o trabalho de um desenvolvedor em um recurso na ramificação de versão.
Lead de versão	Gerencia e aprova as solicitações de envio para mesclagem na ramificação principal, que promove o código para a produção.

Como configurar pipelines para administradores do Salesforce e leads de DevOps

Nesta seção, descrevemos as tarefas que os administradores e as equipes de DevOps seguem para configurar o fluxo de trabalho de CI/CD.

Ative a organização Dev Hub

Faça login na sua organização de produção do Salesforce.
Na guia Setup, na caixa Quick Find, digite Dev Hub e selecione Dev Hub.
Ative o Dev Hub.

Nesta etapa, você pode criar uma organização de rascunho. Use a organização de rascunho para implantar o código de amostra no tutorial em uma organização do Developer Edition do Salesforce.

Crie um certificado e um par de chaves

Depois de ativar a organização do Dev Hub, é necessário gerar um certificado e um par de chaves que podem ser usados para autenticação na organização do Salesforce Dev Hub. Use esse certificado e esse par de chaves ao configurar o Cloud Build em etapas posteriores.

Para pipelines de produção de CI/CD, é necessário gerar certificados adicionais para autenticar-se em sandboxes do Salesforce. (Você não cria esses certificados adicionais como parte deste tutorial.) Ao gerar certificados e pares de chaves para cada ambiente, certifique-se de fornecer nomes identificáveis, como nos exemplos a seguir:

Produção (organização do Dev Hub): salesforce.key e salesforce.crt. Você usa esses nomes no procedimento a seguir.
Sandbox de controle de qualidade (QA, na sigla em inglês): salesforce_qa.key e salesforce_qa.crt.
Sandbox de desenvolvimento integrado (IDEV, na sigla em inglês): salesforce_dev.key e salesforce_dev.crt.

Para gerar um certificado e um par de chaves, siga estas etapas:

No Cloud Shell, gere um certificado e um par de chaves para que o Cloud Build possa se autenticar na sua organização do Salesforce Dev Hub a partir da CLI do Salesforce:
```
openssl req -x509 -sha256 -nodes -days 36500 -newkey \
rsa:2048 -keyout salesforce.key -out \
salesforce.crt
```
Você precisará inserir detalhes para identificar o certificado. Para este tutorial, esses valores não são importantes. Dessa forma, pressione Enter para aceitar os padrões.

No comando, você usa os nomes salesforce.key e salesforce.crt, porque está criando o certificado e o par de chaves para a organização do Dev Hub.
Clique em Mais e selecione Fazer o download do arquivo.
Na caixa Caminho do arquivo totalmente qualificado, insira o seguinte nome de arquivo e clique em Fazer o download:
```
salesforce.crt
```
Nesta etapa, o certificado gerado é baixado na sua máquina local. Faça upload do certificado em sua organização do Salesforce na próxima seção.

Crie apps conectados no Salesforce

Nesta seção, você cria um aplicativo conectado que o Cloud Build pode usar para implantar seu código do Salesforce. Neste tutorial, você implanta código apenas na organização do Dev Hub. Em um ambiente de produção, implante o código para cada sandbox e para a organização de produção em que você quer que o Cloud Build implante o código do Salesforce para o pipeline de DevOps.

Como parte desse processo, use o certificado e o par de chaves gerados na seção anterior. O certificado é a chave pública para autenticar o cliente do Salesforce em uma sessão do Cloud Shell na organização do Salesforce Dev Hub (sandbox do Salesforce). O certificado também é usado para autenticar o Cloud Build em implantações automatizadas.

Os detalhes de algumas das etapas no procedimento a seguir dependem da edição do Salesforce que você está usando. Use o certificado e os pares de chaves corretos no ambiente selecionado.

Se você estiver usando a Salesforce Lightning Experience, use o App Manager para criar apps conectados. Em Configuração na sua organização do Salesforce, faça o seguinte:
1. Na caixa Quick Find, digite App.
2. Selecione App Manager.
3. Clique em New Connected App.
Se você estiver usando o Salesforce Classic, na Configuração em sua organização do Salesforce, faça o seguinte:
1. Na caixa Quick Find, digite Apps.
2. Em Build > Create, selecione Apps.
3. Em Connected Apps, clique em New.
Para o nome do seu aplicativo, insira Google Cloud DevOps.

Isso preenche Google_Cloud_DevOps na caixa Nome da API.
Insira as informações do e-mail de contato e outras informações adequadas para seu aplicativo.
Selecione Ativar configurações do OAuth.
Para o valor de Callback URL, digite o seguinte URL:
```
http://localhost:1717/OauthRedirect
```
Para ativar a opção de usar assinaturas digitais, clique em Escolher arquivo e selecione o arquivo de salesforce.crt baixado anteriormente.
Adicione os seguintes escopos do OAuth aos Escopos OAuth selecionados:
- Acessar e gerenciar seus dados (API)
- Fazer solicitações em seu nome a qualquer momento (refresh_token, offline_access)
- Fornecer acesso aos dados pela Web (Web)
Clique em Salvar e em Continuar.
Anote o valor do Token do cliente que é exibido na seção da API. Você precisará dele mais tarde ao configurar o manifesto do Cloud Build.

Se estiver trabalhando em um ambiente de produção, você terá uma chave para cada ambiente de implantação.
Clique em Gerenciar e, para alterar as políticas do OAuth, clique em Editar políticas.
Defina Usuários permitidos como Os usuários aprovados pelo administrador são pré-autorizados e confirme.
Defina o relaxamento de IP como Relaxar restrições de IP.
Clique em Salvar.
Clique em Gerenciar perfis e selecione a opção Administrador do sistema.

Após essa etapa, os usuários que assumem esse perfil podem fazer login na CLI do Salesforce.
Clique em Salvar.

Inicialize o ambiente do Google Cloud

No Cloud Shell, defina o projeto criado ou selecionado como projeto padrão:
```
gcloud config set project PROJECT_ID
```
Substitua PROJECT_ID pelo ID do projeto do Google Cloud.
Atribua configurações para região e zona:
```
gcloud config set compute/region us-central1
gcloud config set compute/zone us-central1-a
```
Neste tutorial, us-central1 é usado como a região e us-central1-a como a zona.

Exporte o ID do projeto atual do Google para uma variável de ambiente chamada GCP_PROJECT_NUMBER:

export GCP_PROJECT_NUMBER=$(gcloud projects describe $DEVSHELL_PROJECT_ID --format='value(projectNumber)')

Faça upload de chaves do Salesforce para o Cloud Storage

No Cloud Shell, crie um bucket do Cloud Storage no projeto de versão para criar os arquivos de chave privada do Salesforce:
```
gsutil mb -p ${DEVSHELL_PROJECT_ID} -l us-central1 \
    gs://salesforce-ref-${DEVSHELL_PROJECT_ID}
```
O nome de um bucket deve ser exclusivo globalmente. Esse comando cria um nome de bucket que inclui o ID do projeto do Cloud.
Copie as chaves privadas do Salesforce geradas na seção Como ativar a organização do Dev Hub para o novo bucket do Cloud Storage:
```
gsutil cp salesforce.key gs://salesforce-ref-${DEVSHELL_PROJECT_ID}
```

Crie seu repositório GitHub

No Cloud Shell, clone o repositório associado a este tutorial:

git clone https://github.com/GoogleCloudPlatform/salesforce-serverless-cicd-cloudbuild

Crie um novo repositório do GitHub chamado DEV_REPO_NAME.

Substitua DEV_REPO_NAME pelo nome que você quer atribuir ao repositório localmente.

Este é o repositório que os desenvolvedores usam para enviar ou receber códigos. Para os fins deste tutorial, crie esse repositório na sua própria conta do GitHub.

Acesse o repositório clonado:

cd salesforce-serverless-cicd-cloudbuild

Adicione seu repositório de desenvolvedor do GitHub como um repositório remoto:
```
git remote add github DEV_REPO_NAME
```

Configure o Cloud Build

Nesta seção, você concluirá as etapas de configuração necessárias para acionar jobs do Cloud Build quando os desenvolvedores gerarem solicitações de envio para mesclar o trabalho em uma ramificação de versão.

Configure dois acionadores para o pipeline de CI/CD que você criará neste tutorial:

Um acionador que executa um job do Cloud Build quando um desenvolvedor cria uma solicitação de envio para mesclar o código na ramificação da versão. Um uso típico deste acionador é executar testes de unidade.
Um acionador que executa um job do Cloud Build quando uma solicitação de envio é mesclada na ramificação da versão. Um uso típico deste acionador é implantar alterações em um sandbox de destino (Dev Hub neste tutorial).

Crie uma imagem de base que inclua o Salesforce DX

O Cloud Build executa a compilação como um conjunto de etapas, em que cada uma delas é executada em um contêiner do Docker. Você cria uma imagem de contêiner base do Docker que inclui a CLI do Salesforce e o Cloud Build usa comandos da CLI do Salesforce para executar o job.

No Cloud Shell, crie um Dockerfile para a imagem que você precisa criar:

cat <<EOF > Dockerfile
FROM debian:buster
RUN apt-get update && \
apt-get install -y wget xz-utils
RUN wget https://developer.salesforce.com/media/salesforce-cli/sfdx-linux-amd64.tar.xz && \
mkdir sfdx && \
tar xJf sfdx-linux-amd64.tar.xz -C sfdx --strip-components 1 && \
./sfdx/install
ENTRYPOINT [ "sfdx" ]
EOF

Exporte o nome da imagem do Docker para uma variável de ambiente chamada SFDX_BASE_IMAGE:
```
export SFDX_BASE_IMAGE="gcr.io/${DEVSHELL_PROJECT_ID}/salesforcedx-base-image:1"
```
Crie seu contêiner com o Cloud Build e publique a imagem no Container Registry:
```
gcloud builds submit --tag ${SFDX_BASE_IMAGE}
```

Configure o job do Cloud Build

Você define um job do Cloud Build editando um arquivo cloudbuild.yaml.

No Cloud Shell, crie um arquivo cloudbuild.yaml para definir as etapas do job a serem executadas quando o Cloud Build implantar código na sua organização do Salesforce Dev Hub:
```
cat <<EOF > cloudbuild.yaml
steps:
- name: gcr.io/cloud-builders/gsutil
  args: ['cp', 'gs://\${_BUCKET_NAME}/salesforce.key', 'salesforce.key']
- name: "${SFDX_BASE_IMAGE}"
  args:
  - force:auth:jwt:grant
  - --setdefaultusername
  - -u
  - \${_SF_USERNAME}
  - -f
  - ./salesforce.key
  - -i
  - \${_CONSUMER_KEY}
- name: "${SFDX_BASE_IMAGE}"
  args: ['force:source:deploy', '-p', './force-app/']
substitutions:
  _BUCKET_NAME: __BUCKET_NAME__
  _SF_USERNAME: __USERNAME__
  _CONSUMER_KEY: __CONSUMER_KEY__
EOF
```
O arquivo configura o Cloud Build para fazer o seguinte:
1. Fazer o download do arquivo salesforce.key que o Cloud Build usa para se autenticar na organização do Dev Hub.
2. Iniciar um contêiner do Docker que tenha a CLI do Salesforce instalada e conecte-se à organização do Dev Hub usando uma concessão do JWT. O Cloud Build usa parâmetros de configuração, como o token do cliente e o nome de usuário do Salesforce que está na definição do acionador do Cloud Build.
3. Implantar o código enviado pelo desenvolvedor para a organização do Dev Hub ou em outro sandbox de destino em pipelines de CI/CD de produção.
Observação: para manter este tutorial rápido, esta etapa mostra como é possível implantar diretamente na organização do Dev Hub. Em pipelines de produção de CI/CD, você normalmente usa um acionador para implantar em ambientes de teste, como sandboxes de controle de qualidade (QA, na sigla em inglês) ou sandbox de teste de aceitação do usuário (UAT, na sigla em inglês).
Crie outro arquivo chamado cloudbuild_pr.yaml para definir as etapas do job a serem executadas quando o Cloud Build implantar código de uma solicitação de envio para uma organização de rascunho do Salesforce ou sandbox temporários para teste:
```
cat <<EOF > cloudbuild_pr.yaml
steps:
- name: gcr.io/cloud-builders/gsutil
  args: ['cp', 'gs://\${_BUCKET_NAME}/salesforce.key', 'salesforce.key']
- name: "${SFDX_BASE_IMAGE}"
  args:
  - force:auth:jwt:grant
  - -u
  - \${_SF_USERNAME}
  - -f
  - ./salesforce.key
  - -i
  - \${_CONSUMER_KEY}
- name: "${SFDX_BASE_IMAGE}"
  args:
  - force:org:create
  - --setdefaultusername
  - --definitionfile
  - config/project-scratch-def.json
  - --targetdevhubusername
  - \${_SF_USERNAME}
  - --setalias
  - testing org
- name: "${SFDX_BASE_IMAGE}"
  args: ['force:source:push']
- name: "${SFDX_BASE_IMAGE}"
  args: ['force:apex:test:run', '--resultformat', 'tap', '--codecoverage']
- name: "${SFDX_BASE_IMAGE}"
  args: ['force:org:delete', '--noprompt']
substitutions:
  _BUCKET_NAME: __BUCKET_NAME__
  _SF_USERNAME: __USERNAME__
  _CONSUMER_KEY: __CONSUMER_KEY__
EOF
```
O arquivo configura o Cloud Build para fazer o seguinte:
1. Fazer o download do arquivo salesforce.key que o Cloud Build usa para se autenticar na organização do Dev Hub.
2. Iniciar um contêiner do Docker que tenha a DX CLI do Salesforce instalada e conecte-se à organização do Dev Hub usando uma concessão do JWT. O Cloud Build usa parâmetros de configuração, como o token do cliente e o nome de usuário do Salesforce que está na definição do acionador do Cloud Build.
3. Criar uma nova organização de rascunho para implantar o código do desenvolvedor para testes automatizados.
4. Exibir textos do Apex na organização de rascunho.
5. Gerar o resultado do texto Apex, que fica disponível no resumo da solicitação de envio do GitHub.
6. Excluir a organização de rascunho temporária.

Envie seu repositório para o GitHub

No Cloud Shell, adicione o novo arquivo cloudbuild yaml e o Dockerfile ao repositório e envie os arquivos para a ramificação principal do repositório DEV_REPO_NAME. Quando solicitado, faça login no GitHub.
```
git add .
git commit -m "Added cloud build configuration"
git push github main
```
Crie uma ramificação da versão onde os desenvolvedores possam enviar ou receber códigos. Para este tutorial, nomeie a ramificação release-sample.
```
git checkout -b release-sample
```
Envie a ramificação para o GitHub:
```
git push github release-sample
```

Conecte seu repositório do GitHub ao Cloud Build

Acesse a página Aplicativo do Cloud Build no Marketplace do GitHub.
Role para baixo e clique em Configurar com o Google Cloud Build. Se solicitado, faça login no GitHub.
Conecte seu repositório ao Cloud Build:
1. Selecione Somente repositórios selecionados.
2. Na lista Selecionar repositórios, selecione repositório.
Clique em Instalar.
Faça login no Google Cloud.

A página Autorização é exibida, onde você precisa autorizar o aplicativo Google Cloud Build a se conectar ao Google Cloud.
Clique em Authorize Google Cloud Build by GoogleCloudBuild.

Você irá para o Console do Google Cloud.
Selecione seu projeto do Google Cloud.
Se você concordar, aceite os termos e clique em Avançar.
Na página Selecionar repositório, selecione o repositório DEV_REPO_NAME do GitHub.
Clique em Conectar repositório.
Clique em Criar gatilho Push.

Atualize a definição do gatilho do Cloud Build

Defina os detalhes do novo acionador que foi criado quando você clicou em Criar acionador de envio na seção anterior.

No console do Google Cloud, abra a página Gatilhos de compilação do Cloud.

Acesse a página de gatilhos do Cloud Build
Clique em Menu para o novo gatilho e em Editar.
Defina o Nome como pull-request-to-release-branch.
Altere a descrição para Run unit tests when a pull request is created from a feature branch.
Altere Evento para Solicitação de envio (somente para aplicativo GitHub).
Em Origem, na caixa de texto Ramificação de base, insira a seguinte expressão:
```
^release.*
```
Em Configuração, selecione Arquivo de configuração do Cloud Build (yaml ou json) e digite cloudbuild_pr.yaml na caixa de texto.

Em Variáveis de substituição, crie três variáveis. Para cada variável, faça o seguinte:

Clique em Adicionar item.

Defina os campos Variável e Valor conforme listado na tabela a seguir:

Variável	Valor
`_BUCKET_NAME`	O nome do bucket do Cloud Storage para o arquivo de chave do Salesforce, no seguinte formato: `salesforce-ref-PROJECT_ID` Substitua `PROJECT_ID` pelo ID do projeto do Cloud.
`_CONSUMER_KEY`	O token do cliente no aplicativo conectado que você criou na organização do Salesforce Dev Hub.
`_SF_USERNAME`	O nome de usuário do Salesforce para a organização do Dev Hub.

Clique em Salvar.

Não feche esta página. Você fará mais trabalhos nesta página no procedimento seguinte.

Crie um segundo gatilho do Cloud Build

A próxima etapa é criar outro acionador para iniciar jobs do Cloud Build quando as confirmações forem feitas na ramificação da versão. Este acionador invoca um job do Cloud Build para enviar as alterações à sua organização do Dev Hub. No pipeline de DevOps, é preciso garantir que somente pessoal e processos autorizados possam confirmar alterações na ramificação da versão.

Na página Acionadores do Cloud Build, clique em Criar acionador para criar um novo acionador.
Defina o Nome como commits-to-release-branch.
Em Tipo de acionador, selecione Enviar para uma ramificação.
Na lista Repositório, selecione seu repositório do GitHub Salesforce.
Na caixa de texto Ramificação (regex), digite a seguinte expressão:
```
^release.*
```
Em Configuração do build, selecione o arquivo de configuração do Cloud Build e insira cloudbuild.yaml.

Em Variáveis de substituição, crie três variáveis. Para cada variável, faça o seguinte:

Clique em Adicionar item.

Defina os campos Variável e Valor conforme listado na tabela a seguir.

Variável	Valor
`_BUCKET_NAME`	Insira o nome do bucket para o arquivo de chave do Salesforce, no seguinte formato: `salesforce-ref-PROJECT_ID` Substitua `PROJECT_ID` pelo ID do projeto do Cloud.
`_CONSUMER_KEY`	O token do cliente no aplicativo conectado que você criou na organização do Salesforce Dev Hub.
`_SF_USERNAME`	O nome de usuário do Salesforce para a organização do Dev Hub.

Clique em Salvar.

Adicione permissões para permitir que o Cloud Build leia as chaves do Salesforce

No Cloud Shell, adicione permissões à sua conta de serviço do Cloud Build para permitir que ela leia as chaves do Salesforce do bucket do Cloud Storage criado:
```
gsutil iam ch serviceAccount:$GCP_PROJECT_NUMBER@cloudbuild.gserviceaccount.com:objectViewer \
    gs://salesforce-ref-${DEVSHELL_PROJECT_ID}
```

Como configurar pipelines para desenvolvedores do Salesforce

As tarefas descritas nesta seção são para desenvolvedores do Salesforce.

Se você executou as etapas da parte anterior deste tutorial que estão na seção para administradores e leads, use um conjunto diferente de credenciais para executar as etapas nesta seção.

As etapas de instalação da CLI do Salesforce DX podem variar de acordo com o sistema operacional que você está usando. As etapas nesta seção descrevem as etapas para o Debian Linux. Para obter instruções sobre o macOS e o Windows, consulte Instalar a CLI do Salesforce (em inglês) na documentação do Salesforce.

Como configurar a CLI do Salesforce DX

Nesta seção, você instalará a CLI do Salesforce e configurará sua autorização.

Na sua máquina local (não no Cloud Shell), acesse o diretório principal:
```
cd $HOME
```

Instale as ferramentas xz-utils e wget:

sudo apt-get install --assume-yes xz-utils wget

Instale a CLI do Salesforce:

wget https://developer.salesforce.com/media/salesforce-cli/sfdx-linux-amd64.tar.xz

Crie um diretório sfdx:
```
mkdir sfdx
```

Extraia o arquivo tar salvo:

tar xJf sfdx-linux-amd64.tar.xz -C sfdx --strip-components 1

Instale a CLI:
```
./sfdx/install
```
A CLI do Salesforce está instalada em /usr/local/bin/sfdx.

Verifique se a CLI foi configurada corretamente:

sfdx

A resposta será semelhante a:

VERSION
sfdx-cli/7.8.1-8f830784cc linux-x64 node-v10.15.3

USAGE
$ sfdx [COMMAND]

COMMANDS
commands  list all the commands
force     tools for the Salesforce developer
help      display help for sfdx
plugins   add/remove/create CLI plug-ins
update    update the sfdx CLI
which     show which plugin a command is in

TOPICS
Run help for each topic below to view subcommands

commands  list all the commands
force     tools for the Salesforce developer
plugins   add/remove/create CLI plug-ins

Conecte seu ambiente de desenvolvimento local à sua organização do Salesforce Dev Hub

Na máquina local, faça login na sua organização do Salesforce usando credenciais para um papel de desenvolvedor:
```
sfdx force:auth:web:login --setalias YOUR_HUB_ORG
```
Substitua YOUR_HUB_ORG por um alias apropriado para sua organização do Dev Hub.

Esse comando abre um navegador da Web na sua máquina local para que não seja possível executá-lo em uma VM à qual você esteja conectado.

Clone o repositório do GitHub

Clone o repositório do GitHub que foi criado pelo administrador do Salesforce:
```
git clone DEV_REPO_NAME -o github
```
Acesse o diretório do repositório clonado:
```
cd DEV_REPO_NAME
```

Envie a base de código e os metadados do Salesforce para uma organização de rascunho

Nesta seção, você envia a base do código e os metadados para uma organização de rascunho para que seja testada em unidades.

Na máquina local, exporte seu nome de usuário do Dev Hub para uma variável de ambiente chamada SALESFORCE_USERNAME:
```
export SALESFORCE_USERNAME=YOUR_DEVHUB_USERNAME
```
Substitua YOUR_DEVHUB_USERNAME pelo nome de usuário que você configurou anteriormente.

Crie uma organização de rascunho para testar o repositório clonado para este tutorial:

sfdx force:org:create \
    --setdefaultusername \
    --definitionfile config/project-scratch-def.json \
    --targetdevhubusername ${SALESFORCE_USERNAME} \
    --setalias feature-test-scratch-org

Envie os metadados e o código para a organização de rascunho:
```
sfdx force:source:push
```
Gere um URL para a organização de rascunho e navegue até ele em uma janela do navegador:
```
sfdx force:org:open
```

Normalmente, a próxima etapa no ciclo de vida de um projeto é executar testes de unidade e validar os recursos que você desenvolveu. Você não fará isso neste tutorial porque está trabalhando com um código de amostra pré-validado.

Envie o código para um repositório de código-fonte

Na sua máquina local, crie uma nova ramificação chamada feature-1:
```
git checkout -b feature-1
```
Envie as alterações para um repositório de código-fonte:
```
git add .
git commit -m "Feature 1 changes"
git push github feature-1
```
Neste tutorial, você usará o GitHub como ferramenta de código-fonte.

Teste a implantação

Nesta seção, veja os testes que podem ser executados para verificar se os acionadores que você criou estão funcionais. O repositório que o administrador do Salesforce criou contém uma classe de teste de amostra.

Na sua máquina local (não no Cloud Shell), crie uma nova ramificação do Git:
```
git checkout -b feature-1
```

Com um editor de texto, abra o seguinte arquivo:

./force-app/main/default/classes/SampleTest.cls

Para que o teste falhe, na instrução System.assertEquals, altere o valor 101 para 102. Depois de fazer a alteração, salve o arquivo, mas mantenha-o aberto, porque você irá alterá-lo novamente mais tarde neste procedimento.
```
@isTest
public class SampleTest {
static testmethod void testAddOne() {
    Test.startTest();
    System.assertEquals(Sample.addOne(100), 102); // Change to 102 from 101
    Test.stopTest();
  }
}
```

Adicione e confirme a alteração na ramificação do recurso:

git add .
git commit -m "Changed test case"
git push github feature-1

Crie uma solicitação de envio para mesclar o código na ramificação de amostra da versão.

Um novo job do Cloud Build é acionado. No entanto, o job falha porque o teste de unidade falha.
Para ver o status do build, abra a página Cloud Build.

Acessar a página do Cloud Build

Acesse a seção Histórico da página Cloud Build.

Você verá o registro do build a seguir para o job. Ele mostra que a declaração de teste falhou.

Step #4: not ok 1 SampleTest.testAddOne
Step #4: # System.AssertException: Assertion Failed: Expected: 101, Actual: 102
Step #4: # Class.SampleTest.testAddOne: line 24, column 1
Step #4: # Run "sfdx force:apex:test:report -i 7076300001gEzne --resultformat <format>" to retrieve test results in a different format.
[. . .]
Finished Step #4
ERROR
ERROR: build step 4 "gcr.io/serverless-devops-sf/salesforcedx-base-image:1" failed: step exited with non-zero status: 100

Para fazer o teste passar, no arquivo ./force-app/main/default/classes/SampleTest.cls, altere o valor 102 de volta para 101:

@isTest
public class SampleTest {
static testmethod void testAddOne() {
    Test.startTest();
    System.assertEquals(Sample.addOne(100), 101); //Change back to 101 from 102
    Test.stopTest();
  }
}

Adicione e confirme a alteração na ramificação do recurso:
```
git add .
git commit -m "Changed test case to make it pass"
git push github feature-1
```
A operação de confirmação aciona um job do Cloud Build.
Quando o job for concluído, analise a solicitação de envio no GitHub e mescle-a na ramificação release-sample.

Nos fluxos de trabalho de produção, a autoridade para mesclar solicitações de envio normalmente é limitada a leads e administradores de DevOps. Para obter mais informações sobre como fazer essa configuração, consulte Como definir a mesclagem de solicitações de envio no site do GitHub.
No console do Google Cloud, avalie o job do Cloud Build que é acionado automaticamente quando você mescla a solicitação de envio para a ramificação de amostra de versão.
Quando o job for concluído, faça login na organização do Dev Hub. É possível fazer login como desenvolvedor ou como administrador.

As modificações de código do desenvolvedor estão disponíveis nesta organização do Salesforce. Para vê-las, acesse a página Configuração e procure em Classes de código personalizado/Apex.

Limpar

Para evitar cobranças na sua conta do Google Cloud pelos recursos usados no tutorial, exclua o projeto que os contém ou mantenha o projeto e exclua os recursos individuais.

Exclua o projeto

Cuidado: excluir um projeto tem os seguintes efeitos:

Tudo no projeto é excluído. Se você tiver usado um projeto existente para as tarefas neste documento, a exclusão dele incluirá a exclusão de quaisquer outros trabalhos feitos no projeto.
Os IDs do projeto personalizados são perdidos. Ao criar o projeto, você pode ter criado um código do projeto personalizado para ser usado no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, exclua recursos específicos do projeto, em vez de excluir o projeto inteiro.

Se você planeja passar por várias arquiteturas, tutoriais ou guias de início rápido, a reutilização de projetos pode evitar que você exceda os limites da cota do projeto.

No Console do Google Cloud, acesse a página Gerenciar recursos.
Acessar "Gerenciar recursos"
Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .
Na caixa de diálogo, digite o ID do projeto e clique em Encerrar para excluí-lo.

Excluir recursos do Salesforce

Também é possível excluir a organização do Salesforce Developer Edition e a organização de rascunho associada criada para este tutorial.

Desativar a organização da Edição para desenvolvedor

Acesse a organização do Salesforce Dev Hub.
Na configuração, na caixa Pesquisa rápida, digite Company e selecione Informações da empresa.
Clique em Informações da empresa.
Clique no botão Desativar organização.

Excluir a organização de rascunho

No Cloud Shell, execute o seguinte comando para excluir a organização de rascunho do Salesforce:
```
sfdx force:org:delete -u feature-test-scratch-org
```

Excluir o repositório do GitHub

Acesse o GitHub e exclua o repositório que você criou na sua conta pessoal para este tutorial.

A seguir

Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.