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 baseada na projeção de uso.
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
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Verifique se a cobrança está ativada para o seu projeto do Google Cloud.
-
Enable the Cloud Build API.
-
In the Google Cloud console, activate 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.
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.
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 |
|
Desenvolvedor do Salesforce |
|
Lead de controle de qualidade |
|
Lead de versã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
esalesforce.crt
. Você usa esses nomes no procedimento a seguir. - Sandbox de controle de qualidade (QA, na sigla em inglês):
salesforce_qa.key
esalesforce_qa.crt
. - Sandbox de desenvolvimento integrado (IDEV, na sigla em inglês):
salesforce_dev.key
esalesforce_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
esalesforce.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:
- Na caixa Quick Find, digite
App
. - Selecione App Manager.
- 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:
- Na caixa Quick Find, digite
Apps
. - Em Build > Create, selecione Apps.
- Em Connected Apps, clique em New.
- Na caixa Quick Find, digite
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 eus-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:
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.
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
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:
- Fazer o download do arquivo
salesforce.key
que o Cloud Build usa para se autenticar na organização do Dev Hub. - 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.
- 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.
- Fazer o download do arquivo
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:
- Fazer o download do arquivo
salesforce.key
que o Cloud Build usa para se autenticar na organização do Dev Hub. - 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.
- Criar uma nova organização de rascunho para implantar o código do desenvolvedor para testes automatizados.
- Exibir textos do Apex na organização de rascunho.
- Gerar o resultado do texto Apex, que fica disponível no resumo da solicitação de envio do GitHub.
- Excluir a organização de rascunho temporária.
- Fazer o download do arquivo
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:
- Selecione Somente repositórios selecionados.
- 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.
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:
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.
Na sua máquina local (não no Cloud Shell), acesse o diretório principal:
cd $HOME
Instale as ferramentas
xz-utils
ewget
: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 valor101
para102
. 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.
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 valor102
de volta para101
:@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
- 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.
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.