Creazione di una pipeline DevOps serverless per Salesforce con Cloud Build

Architettura

Il seguente diagramma illustra l'architettura del flusso di lavoro CI/CD creato in questo tutorial. In questa architettura, i progetti sono organizzati come release. Gli sviluppatori che vogliono lavorare su una funzionalità creano un nuovo ramo di funzionalità da un ramo di release.

Il diagramma illustra il seguente flusso:

1. Gli sviluppatori creano rami di funzionalità in GitHub per le funzionalità che stanno sviluppando.
2. Gli sviluppatori completano il lavoro di sviluppo ed eseguono test delle unità nelle organizzazioni temporanee di Salesforce.
3. Gli sviluppatori eseguono il commit e il push del lavoro di sviluppo nel proprio repository di codice sorgente (GitHub in questo tutorial).
4. Gli sviluppatori creano una richiesta di pull per unire il proprio lavoro nel ramo di release.
5. La creazione di una richiesta di pull attiva automaticamente un job Cloud Build per l'esecuzione di test.
6. Il personale responsabile (di solito i responsabili del team) esamina e approva le richieste di pull per unire il lavoro di sviluppo nel ramo di rilascio.
7. Un'unione nel ramo di rilascio attiva automaticamente un job Cloud Build per eseguire il deployment del codebase in QA o in altri ambienti Salesforce.
8. Facoltativamente, i test e le revisioni manuali vengono eseguiti in un ambiente di QA.
9. Il personale responsabile crea una richiesta di pull per unire il codice nel ramo main.
10. La richiesta di pull al ramo main attiva un job Cloud Build per eseguire il deployment del codice in produzione.

Gli sviluppatori che vogliono lavorare sui progetti clonano il repository dei progetti dallo strumento di controllo del codice sorgente aziendale (GitHub in questo tutorial). Il seguente schema rappresenta la strategia sotto forma di grafico.

Come illustrato nel diagramma, la strategia di diramazione prevede quanto segue:

1. Un ramo principale. Il codice nel ramo principale riflette la versione corrente del codice in esecuzione in produzione.
2. Un ramo di rilascio. Un ramo di release è un ramo di durata relativamente più lunga (rispetto a un ramo di funzionalità) che coordina tutte le modifiche e il codice pertinente per una release. Un'organizzazione crea un nuovo ramo di release per ogni nuova release.
3. Uno o più rami di funzionalità. I rami di funzionalità aiutano a isolare il lavoro in corso dalla versione più aggiornata del codice nel ramo principale. In genere, diversi rami di funzionalità costituiscono un ramo di rilascio. Per gli sviluppatori è buona norma creare rami di funzionalità per le correzioni di bug.

Dopo aver clonato un repository di progetto, gli sviluppatori sviluppano lo sviluppo sulla propria macchina locale o in un'organizzazione temporanea di Salesforce. Può utilizzare un'organizzazione temporanea per eseguire test delle unità sulle modifiche apportate. Se i test delle unità hanno esito positivo, eseguono il commit del codice ed eseguono il push del codice nel repository del codice sorgente. Generano quindi una richiesta di pull per il proprio codice da unire nel ramo di release padre.

La richiesta di pull attiva automaticamente un job Cloud Build che:

• Crea una nuova organizzazione temporanea per eseguire i test delle unità.
• Aggiorna la richiesta di pull con il risultato dei test.

A questo punto, i responsabili del team e i proprietari dei prodotti possono esaminare la richiesta di pull. Se la richiesta viene approvata, le modifiche vengono unite nel ramo di release.

A seconda del ciclo di vita dello sviluppo del software, puoi avere ulteriori passaggi automatizzati che vengono attivati in base a un'unione nel ramo di rilascio. Esempi di passaggi automatici sono il deployment del codice convalidato in una sandbox superiore, come sandbox per il controllo qualità o i test di integrazione del sistema.

Puoi anche configurare Cloud Build per inviare notifiche di build ed eseguire azioni aggiuntive utilizzando Cloud Functions, Cloud Run o altri strumenti di Google Cloud. Queste azioni aggiuntive non sono trattate in questo tutorial. Questo approccio offre la flessibilità necessaria per adattare la pipeline al framework DevOps aziendale.

Per semplicità, in questo tutorial eseguirai il deployment del codebase di esempio in una singola organizzazione Salesforce (Dev Hub). Quando crei una pipeline CI/CD per la produzione, utilizzi l'architettura illustrata in precedenza e automatizza i deployment nelle sandbox che fanno parte del ciclo di vita dello sviluppo del software.

Utenti tipo solitamente coinvolti nello sviluppo di software

Ogni organizzazione è diversa e ognuna ha la propria gamma di ruoli e team. La seguente tabella elenca gli utenti tipo (ruoli) chiave che in genere interagiscono con le pipeline DevOps di Salesforce come quella descritta in questo tutorial.

Chi ricopre ruoli diversi ha responsabilità diverse nella configurazione delle pipeline di Salesforce. Di conseguenza, il tutorial ha due percorsi. Un percorso è riservato agli amministratori e ai lead DevOps, l'altro agli sviluppatori.

Configurazione delle pipeline per gli amministratori di Salesforce e i responsabili DevOps

Questa sezione descrive le attività che gli amministratori e i team DevOps seguono per configurare il flusso di lavoro CI/CD.

Abilita l'organizzazione dell'hub di sviluppo

1. Accedi all'organizzazione di produzione di Salesforce.

2. Nella casella Ricerca rapida della scheda Configurazione, inserisci Dev Hub e seleziona Dev Hub.

   

3. Abilita l'hub di sviluppo.

   Questo passaggio consente di configurare un'organizzazione scratchpad. Puoi utilizzare l'organizzazione temporanea per eseguire il deployment del codice campione del tutorial su un'organizzazione Salesforce Developer Edition.

Crea un certificato e una coppia di chiavi

Dopo aver abilitato l'organizzazione Dev Hub, devi generare un certificato e una coppia di chiavi che possano essere utilizzati per l'autenticazione nell'organizzazione dell'hub dei sviluppatori di Salesforce. Utilizza questo certificato e questa coppia di chiavi durante la configurazione di Cloud Build nei passaggi successivi.

Per le pipeline CI/CD di produzione, devi generare certificati aggiuntivi per l'autenticazione nelle sandbox di Salesforce. Non devi creare questi certificati aggiuntivi nell'ambito di questo tutorial. Quando generi certificati e coppie di chiavi per ogni ambiente, assicurati di assegnare loro nomi identificabili, come indicato nei seguenti esempi:

• Produzione (organizzazione dell'hub di sviluppo): salesforce.key e salesforce.crt. Questi nomi vengono utilizzati nella procedura che segue.
• Sandbox del controllo qualità (QA): salesforce_qa.key e salesforce_qa.crt.
• Sandbox per lo sviluppo integrato (IDEV): salesforce_dev.key e salesforce_dev.crt.

Per generare un certificato e una coppia di chiavi:

1. In Cloud Shell, genera un certificato e una coppia di chiavi in modo che Cloud Build possa eseguire l'autenticazione nella tua organizzazione Salesforce Dev Hub dall'interfaccia a riga di comando di Salesforce:

   openssl req -x509 -sha256 -nodes -days 36500 -newkey \
   rsa:2048 -keyout salesforce.key -out \
   salesforce.crt
   

   Ti viene chiesto di inserire i dettagli per identificare il certificato. Per questo tutorial, questi valori non sono importanti, quindi premi Invio per accettare i valori predefiniti.

   Tieni presente che nel comando utilizzi i nomi salesforce.key e salesforce.crt, perché stai creando il certificato e la coppia di chiavi per l'organizzazione dell'hub Dev.

2. Fai clic su Altro e seleziona Scarica file.

3. Nella casella Percorso file completo, inserisci il seguente nome file e fai clic su Scarica:

   salesforce.crt
   

   Questo passaggio consente di scaricare sul computer locale il certificato che hai generato. Potrai caricare il certificato nella tua organizzazione Salesforce nella sezione successiva.

Creare app collegate in Salesforce

In questa sezione creerai un'applicazione connessa che Cloud Build può utilizzare per eseguire il deployment del tuo codice Salesforce. Per questo tutorial, eseguirai il deployment del codice solo nell'organizzazione dell'hub di sviluppo. In un ambiente di produzione, esegui il deployment del codice per ogni sandbox e per l'organizzazione di produzione in cui vuoi che Cloud Build esegua il deployment del tuo codice Salesforce per la pipeline DevOps.

Nell'ambito di questo processo, utilizzerai il certificato e la coppia di chiavi generati nella sezione precedente. Il certificato è la chiave pubblica per l'autenticazione del client Salesforce in una sessione Cloud Shell nell'organizzazione di Salesforce Dev Hub (sandbox di Salesforce). Il certificato viene utilizzato anche per autenticare Cloud Build per i deployment automatici.

I dettagli di alcuni passaggi della procedura seguente dipendono dalla versione di Salesforce in uso. Assicurati di utilizzare le coppie di certificati e chiavi corrette per l'ambiente selezionato.

1. Se usi Salesforce Lightning Experience, usa Gestione app per creare app collegate. Da Configurazione nella tua organizzazione Salesforce, procedi nel seguente modo:

   1. Nella casella Ricerca rapida, inserisci App.
   2. Seleziona Gestione app.
   3. Fai clic su Nuova app collegata.

   Se utilizzi Salesforce Classic, da Impostazione nella tua organizzazione Salesforce, procedi nel seguente modo:

   1. Nella casella Ricerca rapida, inserisci Apps.
   2. In Build > Crea, seleziona App.
   3. In App collegate, fai clic su Nuova.

2. Come nome della tua applicazione, inserisci Google Cloud DevOps.

   Inserisci Google_Cloud_DevOps nella casella Nome API.

3. Inserisci i dati dell'email di contatto e qualsiasi altra informazione appropriata per la tua applicazione.

4. Seleziona Abilita impostazioni OAuth.

5. Per il valore URL di callback, inserisci il seguente URL:

   http://localhost:1717/OauthRedirect
   

6. Per attivare l'opzione per l'utilizzo delle firme digitali, fai clic su Scegli file e seleziona il file salesforce.crt che hai scaricato in precedenza.

7. Aggiungi i seguenti ambiti OAuth agli ambiti OAuth selezionati:

   • Accedere ai dati e gestirli (API)
   • Esegui le richieste per tuo conto in qualsiasi momento (refresh_token, offline_access)
   • Fornire l'accesso ai dati tramite il web (web)

   

8. Fai clic su Salva e poi su Continua.

9. Prendi nota del valore Chiave utente visualizzato nella sezione API. Ti servirà in un secondo momento, durante la configurazione del manifest di Cloud Build.

   Se lavori in un ambiente di produzione, hai a disposizione una chiave per ogni ambiente di deployment.

10. Fai clic su Gestisci, quindi fai clic su Modifica criteri per modificare i criteri OAuth.

11. Imposta Utenti consentiti su Gli utenti approvati dall'amministratore sono pre-autorizzati e conferma la scelta.

12. Imposta l'rilassamento IP su Relax IP Restrizioni.

13. Fai clic su Salva.

14. Fai clic su Gestisci profili e seleziona l'opzione Amministratore di sistema.

    Dopo questo passaggio, gli utenti che presuppongono questo profilo possono accedere all'interfaccia a riga di comando di Salesforce.

15. Fai clic su Salva.

Inizializzare l'ambiente Google Cloud

1. In Cloud Shell, imposta il progetto che hai creato o selezionato come progetto predefinito:

   gcloud config set project PROJECT_ID
   

   Sostituisci PROJECT_ID con l'ID del tuo progetto Google Cloud.

2. Assegna impostazioni per regione e zona:

   gcloud config set compute/region us-central1
   gcloud config set compute/zone us-central1-a
   

   In questo tutorial, utilizzerai us-central1 come regione e us-central1-a come zona.

3. Esporta l'ID progetto Google corrente in una variabile di ambiente denominata GCP_PROJECT_NUMBER:

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

Carica le chiavi Salesforce in Cloud Storage

1. In Cloud Shell, crea un bucket Cloud Storage nel progetto di build per archiviare i file delle chiavi private di Salesforce:

   gsutil mb -p ${DEVSHELL_PROJECT_ID} -l us-central1 \
       gs://salesforce-ref-${DEVSHELL_PROJECT_ID}
   

   Il bucket deve avere un nome globalmente univoco. Questo comando crea un nome bucket che include l'ID progetto Google Cloud.

2. Copia le chiavi private di Salesforce generate nella sezione Abilitazione dell'organizzazione dell'hub degli sviluppatori nel nuovo bucket Cloud Storage:

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

Crea il tuo repository GitHub

1. In Cloud Shell, clona il repository associato a questo tutorial:

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

2. Crea un nuovo repository GitHub denominato DEV_REPO_NAME.

   Sostituisci DEV_REPO_NAME con il nome che vuoi assegnare al repository in locale.

   Si tratta del repository da cui gli sviluppatori recuperano il codice o in cui esegue il push del codice. Ai fini di questo tutorial, dovrai creare il repository nel tuo account GitHub.

3. Vai al repository clonato:

   cd salesforce-serverless-cicd-cloudbuild
   

4. Aggiungi il repository GitHub dello sviluppatore come repository remoto:

   git remote add github DEV_REPO_NAME
   

Configura Cloud Build

In questa sezione completerai i passaggi di configurazione necessari per attivare job Cloud Build quando gli sviluppatori generano richieste di pull per unire il lavoro in un ramo di rilascio.

Configuri due trigger per la pipeline CI/CD che crei in questo tutorial:

• Un trigger che esegue un job di Cloud Build quando uno sviluppatore crea una richiesta di pull per unire il codice nel ramo di rilascio. In genere, questo trigger esegue test delle unità.
• Un trigger che esegue un job Cloud Build quando una richiesta di pull viene unita nel ramo di rilascio. In genere questo trigger esegue il deployment delle modifiche in una sandbox di destinazione (Dev Hub in questo tutorial).

Crea un'immagine di base che includa Salesforce DX

Cloud Build esegue la build come un insieme di passi, dove ogni passaggio viene eseguito in un container Docker. Creerai un'immagine container Docker di base che includa l'interfaccia a riga di comando di Salesforce e Cloud Build utilizza i comandi dell'interfaccia a riga di comando di Salesforce per eseguire il job.

1. In Cloud Shell, crea un Dockerfile per l'immagine che devi creare:

   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. Esporta il nome dell'immagine Docker in una variabile di ambiente denominata SFDX_BASE_IMAGE:

   export SFDX_BASE_IMAGE="gcr.io/${DEVSHELL_PROJECT_ID}/salesforcedx-base-image:1"
   

3. Crea il tuo container con Cloud Build e pubblica l'immagine in Container Registry:

   gcloud builds submit --tag ${SFDX_BASE_IMAGE}
   

Configura il job di Cloud Build

Puoi definire un job Cloud Build modificando un file cloudbuild.yaml.

1. In Cloud Shell, crea un file cloudbuild.yaml per definire i passaggi del job da eseguire quando Cloud Build esegue il deployment del codice nella tua organizzazione 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
   

   Il file configura Cloud Build in modo che:

   1. Scarica il file salesforce.key che Cloud Build utilizza per l'autenticazione nell'organizzazione dell'hub di sviluppo.
   2. Avvia un container Docker in cui è installata l'interfaccia a riga di comando di Salesforce, quindi connettiti all'organizzazione dell'hub di sviluppo utilizzando una concessione JWT. Cloud Build utilizza parametri di configurazione come la chiave utente e il nome utente Salesforce presente nella definizione del trigger di Cloud Build.
   3. Esegui il deployment del codice inviato dallo sviluppatore all'organizzazione dell'hub di sviluppo o a un'altra sandbox di destinazione nelle pipeline CI/CD di produzione.

2. Crea un altro file denominato cloudbuild_pr.yaml per definire i passaggi del job da eseguire quando Cloud Build esegue il deployment del codice da una richiesta di pull a un'organizzazione temporanea o una sandbox temporanea di Salesforce per i test:

   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
   

   Il file configura Cloud Build in modo che:

   1. Scarica il file salesforce.key che Cloud Build utilizza per l'autenticazione nell'organizzazione dell'hub di sviluppo.
   2. Avvia un container Docker in cui è installata l'interfaccia a riga di comando DX di Salesforce e connettiti all'organizzazione dell'hub di sviluppo utilizzando una concessione JWT. Cloud Build utilizza parametri di configurazione come la chiave utente e il nome utente Salesforce nella definizione del trigger di Cloud Build.
   3. Crea una nuova organizzazione temporanea per eseguire il deployment del codice dello sviluppatore per i test automatici.
   4. Esegui testi Apex nell'organizzazione scratchpad.
   5. Visualizza il risultato del testo Apex, che diventa disponibile nel riepilogo della richiesta di pull di GitHub.
   6. Elimina l'organizzazione temporanea.

Esegui il push del repository a GitHub

1. In Cloud Shell, aggiungi il nuovo file cloudbuild yaml e il Dockerfile al repository ed esegui il push dei file nel ramo principale del repository DEV_REPO_NAME. Quando ti viene richiesto, accedi a GitHub.

   git add .
   git commit -m "Added cloud build configuration"
   git push github main
   

2. Crea un ramo di rilascio da cui gli sviluppatori possono eseguire il pull o il push del codice. Per questo tutorial, assegna al ramo il nome release-sample.

   git checkout -b release-sample
   

3. Esegui il push del ramo a GitHub:

   git push github release-sample
   

Connetti il tuo repository GitHub a Cloud Build

1. Vai alla pagina Applicazione Cloud Build su GitHub Marketplace.
2. Scorri verso il basso e fai clic su Setup with Google Cloud Build (Configura con Google Cloud Build). Se ti viene richiesto, accedi a GitHub.
3. Connetti il tuo repository a Cloud Build:
   1. Seleziona Seleziona solo i repository.
   2. Nell'elenco Seleziona repository, seleziona repository.
4. Fai clic su Installa.

5. Accedi a Google Cloud.

   Viene visualizzata la pagina Autorizzazione, in cui ti viene richiesto di autorizzare l'applicazione Google Cloud Build a connettersi a Google Cloud.

6. Fai clic su Autorizza Google Cloud Build by GoogleCloud Build.

   Il sistema ti reindirizzerà alla console Google Cloud.

7. Selezionare il tuo progetto Google Cloud.

8. Se accetti, accetta i termini e fai clic su Avanti.

9. Nella pagina Seleziona repository, seleziona il repository GitHub di DEV_REPO_NAME.

10. Fai clic su Connetti repository.

11. Fai clic su Crea attivatore push.

Aggiorna la definizione del trigger di Cloud Build

Sei tu a definire i dettagli del nuovo trigger che è stato creato quando hai fatto clic su Crea trigger push nella sezione precedente.

1. Nella console Google Cloud, apri la pagina Trigger di Cloud Build.

   Vai alla pagina Trigger di Cloud Build

2. Fai clic su more_vert Menu per il nuovo attivatore e poi su Modifica.

3. Imposta Nome su pull-request-to-release-branch.

4. Cambia la descrizione in Run unit tests when a pull request is created from a feature branch.

5. Modifica Evento in Richiesta di pull (solo app GitHub).

6. In Origine, nella casella di testo Ramo base inserisci la seguente espressione:

   ^release.*
   

7. In Configurazione, seleziona File di configurazione di Cloud Build (yaml o json) e inserisci cloudbuild_pr.yaml nella casella di testo.

8. In Variabili di sostituzione, crea tre variabili. Per ogni variabile, segui questi passaggi:

   1. Fai clic su Aggiungi elemento.

   2. Imposta i campi Variabile e Valore come elencato nella seguente tabella:

      Variabile	Valore
      _BUCKET_NAME	Il nome del bucket Cloud Storage per il file delle chiavi Salesforce, nel seguente formato: salesforce-ref-PROJECT_ID Sostituisci PROJECT_ID con l'ID del tuo progetto Google Cloud.
      _CONSUMER_KEY	La chiave utente nell'applicazione connessa che hai creato nell'organizzazione Salesforce Dev Hub.
      _SF_USERNAME	Il nome utente Salesforce dell'organizzazione Dev Hub.

9. Fai clic su Salva.

   Non chiudere questa pagina. Nella prossima procedura svolgerai ulteriore lavoro su questa pagina.

Crea un secondo trigger di Cloud Build

Il passaggio successivo consiste nel creare un altro trigger per avviare i job di Cloud Build quando vengono effettuati i commit nel ramo di rilascio. Questo trigger richiama un job Cloud Build per eseguire il push delle modifiche all'organizzazione dell'hub di sviluppo. Nella tua pipeline DevOps, devi assicurarti che solo il personale e i processi autorizzati siano in grado di eseguire il commit delle modifiche nel ramo di rilascio.

1. Nella pagina Trigger di Cloud Build, fai clic su Crea trigger per crearne uno nuovo.
2. Imposta Nome su commits-to-release-branch.
3. In Tipo di attivatore, seleziona Push a un ramo.
4. Nell'elenco Repository, seleziona il repository Salesforce GitHub.

5. Nella casella di testo Ramo (regex), inserisci la seguente espressione:

   ^release.*
   

6. In Configurazione build, seleziona File di configurazione Cloud Build e inserisci cloudbuild.yaml.

7. In Variabili di sostituzione, crea tre variabili. Per ogni variabile, segui questi passaggi:

   1. Fai clic su Aggiungi elemento.

   2. Imposta i campi Variabile e Valore come elencato nella tabella seguente.

      Variabile	Valore
      _BUCKET_NAME	Inserisci il nome del bucket per il file delle chiavi Salesforce nel seguente formato: salesforce-ref-PROJECT_ID Sostituisci PROJECT_ID con l'ID del tuo progetto Google Cloud.
      _CONSUMER_KEY	La chiave utente nell'applicazione connessa che hai creato nell'organizzazione Salesforce Dev Hub.
      _SF_USERNAME	Il nome utente Salesforce dell'organizzazione Dev Hub.

8. Fai clic su Salva.

Aggiungi autorizzazioni per consentire a Cloud Build di leggere le chiavi Salesforce

• In Cloud Shell, aggiungi le autorizzazioni all'account di servizio Cloud Build per consentirgli di leggere le chiavi Salesforce dal bucket Cloud Storage che hai creato:

  gsutil iam ch serviceAccount:[email protected]:objectViewer \
      gs://salesforce-ref-${DEVSHELL_PROJECT_ID}
  

Configurazione delle pipeline per gli sviluppatori Salesforce

Le attività descritte in questa sezione sono rivolte agli sviluppatori Salesforce.

Se hai eseguito i passaggi della parte precedente di questo tutorial presenti nella sezione per amministratori e lead, assicurati di utilizzare un set di credenziali diverso per eseguire i passaggi di questa sezione.

I passaggi di installazione dell'interfaccia a riga di comando DX di Salesforce possono variare in base al sistema operativo in uso. I passaggi in questa sezione descrivono i passaggi per Debian Linux. Per istruzioni per macOS e Windows, consulta Installare l'interfaccia a riga di comando di Salesforce nella documentazione di Salesforce.

Configurazione dell'interfaccia a riga di comando DX di Salesforce

In questa sezione installerai l'interfaccia a riga di comando di Salesforce e ne configurerai l'autorizzazione.

1. Sulla macchina locale (non in Cloud Shell), vai alla home directory:

   cd $HOME
   

2. Installa gli strumenti xz-utils e wget:

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

3. Installa l'interfaccia a riga di comando di Salesforce:

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

4. Crea una directory sfdx:

   mkdir sfdx
   

5. Estrai il file tar scaricato:

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

6. Installa l'interfaccia a riga di comando:

   ./sfdx/install
   

   L'interfaccia a riga di comando di Salesforce è installata in /usr/local/bin/sfdx.

7. Verifica che l'interfaccia a riga di comando sia stata configurata correttamente:

   sfdx
   

   L'output è simile al seguente:

   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
   

Collega l'ambiente di sviluppo locale alla tua organizzazione Salesforce Dev Hub

1. Dal computer locale, accedi alla tua organizzazione Salesforce utilizzando le credenziali per un ruolo sviluppatore:

   sfdx force:auth:web:login --setalias YOUR_HUB_ORG
   

   Sostituisci YOUR_HUB_ORG con un alias appropriato per la tua organizzazione dell'hub di sviluppo.

   Questo comando apre un browser web sulla tua macchina locale, quindi non puoi eseguirlo su una VM a cui hai effettuato la connessione.

Clona il repository GitHub

1. Clona il repository GitHub creato dall'amministratore Salesforce:

   git clone DEV_REPO_NAME -o github
   

2. Vai alla directory del repository clonato:

   cd DEV_REPO_NAME
   

Esegui il push del codebase e dei metadati di Salesforce a un'organizzazione temporanea

In questa sezione, eseguirai il push del codebase e dei metadati in un'organizzazione temporanea, in modo che possa essere eseguito il test delle unità.

1. Sulla macchina locale, esporta il tuo nome utente dell'hub Dev Hub in una variabile di ambiente denominata SALESFORCE_USERNAME:

   export SALESFORCE_USERNAME=YOUR_DEVHUB_USERNAME
   

   Sostituisci YOUR_DEVHUB_USERNAME con il nome utente che hai configurato in precedenza.

2. Crea un'organizzazione temporanea per testare il repository che hai clonato per questo tutorial:

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

3. Esegui il push dei metadati e del codice all'organizzazione temporanea:

   sfdx force:source:push
   

4. Genera un URL per l'organizzazione temporanea e aprilo in una finestra del browser:

   sfdx force:org:open
   

In genere, il passaggio successivo del ciclo di vita di un progetto consiste nell'eseguire i test delle unità e convalidare le caratteristiche sviluppate. Non è possibile farlo in questo tutorial perché stai utilizzando codice campione preconvalidato.

Esegui il push del codice a un repository di codice sorgente

1. Sulla macchina locale, crea un nuovo ramo denominato feature-1:

   git checkout -b feature-1
   

2. Esegui il push delle modifiche a un repository di codice sorgente:

   git add .
   git commit -m "Feature 1 changes"
   git push github feature-1
   

   Per questo tutorial, utilizzerai GitHub come strumento del codice sorgente.

Testa il deployment

Questa sezione descrive i test che puoi eseguire per verificare che i trigger che hai creato funzionino. Il repository creato dall'amministratore Salesforce contiene una classe di test di esempio.

1. Sulla tua macchina locale (non in Cloud Shell), crea un nuovo ramo Git:

   git checkout -b feature-1
   

2. Utilizzando un editor di testo, apri il seguente file:

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

3. Per fare in modo che il test non vada a buon fine, nell'istruzione System.assertEquals modifica il valore 101 in 102. Dopo aver apportato la modifica, salva il file, ma tienilo aperto perché lo modifichi di nuovo in una fase successiva della procedura.

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

4. Aggiungi ed esegui il commit della modifica al ramo delle caratteristiche:

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

5. Crea una richiesta di pull per unire il codice nel ramo release-campione.

   Viene attivato un nuovo job di Cloud Build. Tuttavia, il job non riesce perché il test delle unità non va a buon fine.

6. Per visualizzare lo stato della build, apri la pagina Cloud Build.

   Vai alla pagina di Cloud Build

7. Vai alla sezione Cronologia della pagina Cloud Build.

   Viene visualizzato il seguente log di build per il job, che indica che l'asserzione di test non è riuscita.

   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. Per superare il test, nel file ./force-app/main/default/classes/SampleTest.cls reimposta il valore 102 in 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. Aggiungi ed esegui il commit della modifica al ramo delle caratteristiche:

   git add .
   git commit -m "Changed test case to make it pass"
   git push github feature-1
   

   L'operazione di commit attiva un job Cloud Build.

10. Al termine del job, esamina la richiesta di pull in GitHub e uniscila al ramo release-sample.

    Nei flussi di lavoro di produzione, l'autorità di unire le richieste di pull è in genere limitata ai lead e agli amministratori DevOps. Per maggiori informazioni su come eseguire la configurazione, consulta Definizione dell'unione delle richieste di pull sul sito GitHub.

11. Nella console Google Cloud, esamina il job di Cloud Build che viene attivato automaticamente quando unisci la richiesta di pull al ramo release-campione.

12. Al termine del job, accedi alla tua organizzazione Dev Hub. Puoi accedere come sviluppatore o amministratore.

    Le modifiche al codice dello sviluppatore sono disponibili in questa organizzazione Salesforce. Per consultarle, vai alla pagina Configurazione e consulta la sezione Classi Apex/Codice personalizzato.