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

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.

O diagrama ilustra o seguinte fluxo:

1. Os desenvolvedores criam ramificações de recursos no GitHub para os recursos que estão desenvolvendo.
2. Os desenvolvedores concluem o trabalho de desenvolvimento e executam testes de unidade em organizações de rascunho do Salesforce.
3. Os desenvolvedores confirmam e enviam o trabalho de desenvolvimento para o repositório de código-fonte (GitHub neste tutorial).
4. Os desenvolvedores criam uma solicitação de envio para mesclar o trabalho deles na ramificação de versão.
5. A criação de uma solicitação de envio aciona automaticamente um job do Cloud Build para executar testes.
6. 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.
7. 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.
8. Opcionalmente, testes e avaliações manuais são realizados em um ambiente de controle de qualidade.
9. A equipe responsável cria uma solicitação de envio para mesclar o código na ramificação main.
10. 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.

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

1. 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.
2. 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.
3. 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.

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

1. Faça login na sua organização de produção do Salesforce.

2. Na guia Setup, na caixa Quick Find, digite Dev Hub e selecione Dev Hub.

   

3. 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:

1. 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.

2. Clique em Mais e selecione Fazer o download do arquivo.

3. 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.

1. 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.

2. Para o nome do seu aplicativo, insira Google Cloud DevOps.

   Isso preenche Google_Cloud_DevOps na caixa Nome da API.

3. Insira as informações do e-mail de contato e outras informações adequadas para seu aplicativo.

4. Selecione Ativar configurações do OAuth.

5. Para o valor de Callback URL, digite o seguinte URL:

   http://localhost:1717/OauthRedirect
   

6. Para ativar a opção de usar assinaturas digitais, clique em Escolher arquivo e selecione o arquivo de salesforce.crt baixado anteriormente.

7. 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)

   

8. Clique em Salvar e em Continuar.

9. 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.

10. Clique em Gerenciar e, para alterar as políticas do OAuth, clique em Editar políticas.

11. Defina Usuários permitidos como Os usuários aprovados pelo administrador são pré-autorizados e confirme.

12. Defina o relaxamento de IP como Relaxar restrições de IP.

13. Clique em Salvar.

14. 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.

15. Clique em Salvar.

Inicialize o ambiente do Google Cloud

1. 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.

2. 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.

3. 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

1. No Cloud Shell, crie um bucket do Cloud Storage no projeto de versão para criar os arquivos de chave privada do Salesforce:

   gcloud storage buckets create gs://salesforce-ref-${DEVSHELL_PROJECT_ID} \
       --project=${DEVSHELL_PROJECT_ID} --location=us-central1
   

   O nome de um bucket deve ser exclusivo globalmente. Esse comando cria um nome de bucket que inclui o ID do projeto do Cloud.

2. 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:

   gcloud storage cp salesforce.key gs://salesforce-ref-${DEVSHELL_PROJECT_ID}
   

Crie seu repositório GitHub

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

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

2. 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.

3. Acesse o repositório clonado:

   cd salesforce-serverless-cicd-cloudbuild
   

4. 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.

1. 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
   

2. 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"
   

3. 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.

1. 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.

2. 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

1. 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
   

2. 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
   

3. Envie a ramificação para o GitHub:

   git push github release-sample
   

Conecte seu repositório do GitHub ao Cloud Build

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

5. 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.

6. Clique em Authorize Google Cloud Build by GoogleCloudBuild.

   Você irá para o Console do Google Cloud.

7. Selecione seu projeto do Google Cloud.

8. Se você concordar, aceite os termos e clique em Avançar.

9. Na página Selecionar repositório, selecione o repositório DEV_REPO_NAME do GitHub.

10. Clique em Conectar repositório.

11. 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.

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

   Acesse a página de gatilhos do Cloud Build

2. Clique em more_vert Menu para o novo gatilho e em Editar.

3. Defina o Nome como pull-request-to-release-branch.

4. Altere a descrição para Run unit tests when a pull request is created from a feature branch.

5. Altere Evento para Solicitação de envio (somente para aplicativo GitHub).

6. Em Origem, na caixa de texto Ramificação de base, insira a seguinte expressão:

   ^release.*
   

7. Em Configuração, selecione Arquivo de configuração do Cloud Build (yaml ou json) e digite cloudbuild_pr.yaml na caixa de texto.

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

   1. Clique em Adicionar item.

   2. 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.

9. 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.

1. Na página Acionadores do Cloud Build, clique em Criar acionador para criar um novo acionador.
2. Defina o Nome como commits-to-release-branch.
3. Em Tipo de acionador, selecione Enviar para uma ramificação.
4. Na lista Repositório, selecione seu repositório do GitHub Salesforce.

5. Na caixa de texto Ramificação (regex), digite a seguinte expressão:

   ^release.*
   

6. Em Configuração do build, selecione o arquivo de configuração do Cloud Build e insira cloudbuild.yaml.

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

   1. Clique em Adicionar item.

   2. 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.

8. 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:

  gcloud storage buckets add-iam-policy-binding gs://salesforce-ref-${DEVSHELL_PROJECT_ID} \
      --member=serviceAccount:$GCP_PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
      --role=roles/storage.objectViewer
  
  

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.

1. Na sua máquina local (não no Cloud Shell), acesse o diretório principal:

   cd $HOME
   

2. Instale as ferramentas xz-utils e wget:

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

3. Instale a CLI do Salesforce:

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

4. Crie um diretório sfdx:

   mkdir sfdx
   

5. Extraia o arquivo tar salvo:

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

6. Instale a CLI:

   ./sfdx/install
   

   A CLI do Salesforce está instalada em /usr/local/bin/sfdx.

7. 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

1. 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

1. Clone o repositório do GitHub que foi criado pelo administrador do Salesforce:

   git clone DEV_REPO_NAME -o github
   

2. 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.

1. 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.

2. 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
   

3. Envie os metadados e o código para a organização de rascunho:

   sfdx force:source:push
   

4. 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

1. Na sua máquina local, crie uma nova ramificação chamada feature-1:

   git checkout -b feature-1
   

2. 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.

1. Na sua máquina local (não no Cloud Shell), crie uma nova ramificação do Git:

   git checkout -b feature-1
   

2. Com um editor de texto, abra o seguinte arquivo:

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

3. 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();
     }
   }
   

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

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

5. 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.

6. Para ver o status do build, abra a página Cloud Build.

   Acessar a página do Cloud Build

7. 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
   

8. 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();
     }
   }
   

9. 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.

10. 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.

11. 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.

12. 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.