Serverlose DevOps-Pipeline für Salesforce mit Cloud Build erstellen

Architektur

Das folgende Diagramm veranschaulicht die Architektur des CI/CD-Workflows, die Sie in dieser Anleitung erstellen. In dieser Architektur sind Projekte als Releases organisiert. Entwickler, die an einem Feature arbeiten möchten, erstellen einen neuen Feature-Zweig aus einem Release-Zweig.

Das Diagramm veranschaulicht den folgenden Ablauf:

1. Entwickler erstellen Feature-Zweige in GitHub für die Features, die sie entwickeln.
2. Entwickler führen Entwicklungsarbeiten durch und führen Unittests in Salesforce-Scratch-Organisationen durch.
3. Entwickler übergeben ihre Entwicklungsarbeit und übertragen sie in ihr Quellcode-Repository (GitHub in dieser Anleitung).
4. Entwickler erstellen eine Pull-Anfrage, um ihre Arbeit mit dem Release-Zweig zusammenzuführen.
5. Das Erstellen einer Pull-Anfrage löst automatisch einen Cloud Build-Job aus, um Tests auszuführen.
6. Verantwortliche Mitarbeiter (in der Regel Teamleiter) überprüfen und genehmigen Pull-Anfragen, um die Entwicklungsarbeit mit dem Release-Zweig zusammenzuführen.
7. Eine Zusammenführung in den Release-Zweig löst automatisch einen Cloud Build-Job aus, um die Codebasis für die QA oder andere Salesforce-Umgebungen bereitzustellen.
8. Optional werden manuelle Tests und Überprüfungen in einer QA-Umgebung durchgeführt.
9. Verantwortliche Mitarbeiter erstellen eine Pull-Anfrage, um Code im main-Zweig zusammenzuführen.
10. Die Pull-Anfrage an den main-Zweig löst einen Cloud Build-Job aus, um Code für die Produktion bereitzustellen.

Wenn Entwickler an Projekten arbeiten möchten, klonen Sie das Projekt-Repository aus dem Versionsverwaltungstool des Unternehmens (GitHub in dieser Anleitung). Das folgende Diagramm veranschaulicht diese Strategie als Grafik.

Wie im Diagramm dargestellt, umfasst die Verzweigungsstrategie Folgendes:

1. Einen Hauptzweig. Der Code im Hauptzweig spiegelt die aktuelle Version des Codes wider, der in der Produktion ausgeführt wird.
2. Einen Release-Zweig. Ein Release-Zweig ist ein relativ langlebiger Zweig (im Vergleich zu einem Feature-Zweig), der alle Änderungen und Code koordiniert, die einen Release betreffen. Eine Organisation erstellt einen neuen Release-Zweig für jeden neuen Release.
3. Einen oder mehrere Feature-Zweige. Feature-Zweige helfen dabei, laufende Arbeiten von der aktuellsten Codeversion im Hauptzweig zu isolieren. Normalerweise bilden mehrere Feature-Zweige einen Release-Zweig. Es ist eine bewährte Vorgehensweise für Entwickler, Feature-Zweige für Fehlerkorrekturen zu erstellen.

Nachdem Entwickler ein Projekt-Repository geklont haben, entwickeln sie auf ihrem lokalen Computer oder in einer Salesforce-Scratch-Organisation. Sie können eine Scratch-Organisation verwenden, um Unittests für die vorgenommenen Änderungen durchzuführen. Wenn die Unittests bestanden werden, übergeben sie ihren Code und übertragen den Code per Push in das Quellcode-Repository. Anschließend generieren sie eine Pull-Anfrage für ihren Code, der in den übergeordneten Release-Zweig zusammengeführt werden soll.

Die Pull-Anfrage löst automatisch einen Cloud Build-Job aus, der Folgendes ausführt:

• Erstellt eine neue Scratch-Organisation zum Ausführen von Unittests.
• Aktualisiert die Pull-Anfrage mit dem Ergebnis der Tests.

Nun können Team-Leads und Produktinhaber die Pull-Anfrage prüfen. Wenn die Anfrage genehmigt wird, werden die Änderungen im Release-Zweig zusammengeführt.

Je nach Softwareentwicklungszyklus können Sie zusätzliche automatisierte Schritte ausführen, die durch eine Zusammenführung im Release-Zweig ausgelöst werden. Beispiele für automatisierte Schritte sind die Implementierung des validierten Codes in einer höheren Sandbox, z. B. für die Qualitätssicherung oder für Tests zur Systemintegration.

Sie können Cloud Build auch so konfigurieren, dass Build-Benachrichtigungen gesendet und weitere Aktionen mit Cloud Functions, Cloud Run oder anderen Google Cloud-Tools ausgeführt werden. (Diese zusätzlichen Aktionen werden in dieser Anleitung nicht behandelt.) Dieser Ansatz bietet Ihnen die Flexibilität, die Pipeline an Ihr Unternehmens-DevOps-Framework anzupassen.

Der Einfachheit halber stellen Sie in dieser Anleitung die Beispielcodebasis für eine einzelne Salesforce-Organisation (Dev Hub) bereit. Wenn Sie eine CI/CD-Pipeline für die Produktion erstellen, verwenden Sie die zuvor beschriebene Architektur und automatisieren die Bereitstellungen für Sandboxes, die Teil Ihres Softwareentwicklungszyklus sind.

Identitäten, die üblicherweise an der Softwareentwicklung beteiligt sind

Jede Organisation ist anders und jede hat ihre eigene Gruppe von Rollen und Teams. In der folgenden Tabelle sind die Schlüsselidentitäten (Rollen) aufgeführt, die normalerweise mit Salesforce-DevOps-Pipelines interagieren, wie in dieser Anleitung beschrieben.

Personen in verschiedenen Rollen haben unterschiedliche Aufgaben, um Salesforce-Pipelines einzurichten. Daher hat die Anleitung zwei Pfade. Ein Pfad ist für Administratoren und DevOps-Leads und der andere für Entwickler.

Pipelines für Salesforce-Administratoren und DevOps-Leads einrichten

In diesem Abschnitt werden die Aufgaben beschrieben, mit denen Administratoren und DevOps-Teams den CI/CD-Workflow einrichten.

Dev Hub-Organisation aktivieren

1. Melden Sie sich in Ihrer Salesforce-Produktionsorganisation an.

2. Geben Sie auf dem Tab Einrichtung im Feld Schnellsuche Dev Hub ein und wählen Sie Dev Hub aus.

   

3. Dev Hub aktivieren.

   Mit diesem Schritt können Sie eine Scratch-Organisation einrichten. Sie verwenden die Scratch-Organisation, um den Beispielcode aus der Anleitung für eine Salesforce Developer Edition-Organisation bereitzustellen.

Zertifikat und Schlüsselpaar erstellen

Nachdem Sie die Dev Hub-Organisation aktiviert haben, müssen Sie ein Zertifikat und ein Schlüsselpaar generieren, mit denen die Authentifizierung bei der Salesforce Dev Hub-Organisation möglich ist. Sie verwenden dieses Zertifikat und dieses Schlüsselpaar, wenn Sie Cloud Build in späteren Schritten konfigurieren.

Für CI/CD-Produktionspipelines müssen Sie zusätzliche Zertifikate generieren, um sich bei Salesforce-Sandboxes zu authentifizieren. (Die zusätzlichen Zertifikate werden im Rahmen dieser Anleitung nicht erstellt.) Wenn Sie Zertifikate und Schlüsselpaare für jede Umgebung generieren, achten Sie darauf, dass Sie ihnen aussagekräftige Namen wie in den folgenden Beispielen geben:

• Produktion (Dev Hub-Organisation): salesforce.key und salesforce.crt. Sie verwenden diese Namen in der folgenden Prozedur.
• Sandbox zur Qualitätssicherung (QA): salesforce_qa.key und salesforce_qa.crt.
• Sandbox für integrierte Entwicklung (IDEV): salesforce_dev.key und salesforce_dev.crt.

So generieren Sie ein Zertifikat und ein Schlüsselpaar:

1. Generieren Sie in Cloud Shell ein Zertifikat und ein Schlüsselpaar, damit Cloud Build sich über die Salesforce-Befehlszeile bei Ihrer Salesforce Dev Hub-Organisation authentifizieren kann:

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

   Sie werden aufgefordert, Details zur Identifizierung des Zertifikats einzugeben. Für diese Anleitung sind diese Werte nicht wichtig. Drücken Sie die Eingabetaste, um die Standardwerte zu akzeptieren.

   Beachten Sie, dass Sie im Befehl die Namen salesforce.key und salesforce.crt verwenden, da Sie das Zertifikat und das Schlüsselpaar für die Dev Hub-Organisation erstellen.

2. Klicken Sie auf Mehr und wählen Sie Datei herunterladen aus.

3. Geben Sie im Feld Voll qualifizierter Dateipfad den folgenden Dateinamen ein und klicken Sie dann auf Herunterladen:

   salesforce.crt
   

   Dadurch wird das von Ihnen generierte Zertifikat auf Ihren lokalen Computer heruntergeladen. Sie laden das Zertifikat im nächsten Abschnitt in Ihre Salesforce-Organisation hoch.

Verbundene Apps in Salesforce erstellen

In diesem Abschnitt erstellen Sie eine verbundene Anwendung, die Cloud Build zur Bereitstellung Ihres Salesforce-Codes verwenden kann. In dieser Anleitung stellen Sie Code nur für die Dev Hub-Organisation bereit. In einer Produktionsumgebung stellen Sie Code für jede Sandbox und für die Produktionsorganisation bereit, in der Cloud Build Ihren Salesforce-Code für die DevOps-Pipeline bereitstellen soll.

Im Rahmen dieses Vorgangs verwenden Sie das Zertifikat und das Schlüsselpaar, das Sie im vorherigen Abschnitt generiert haben. Das Zertifikat ist der öffentliche Schlüssel zur Authentifizierung des Salesforce-Clients in einer Cloud Shell-Sitzung bei der Salesforce Dev Hub-Organisation (Salesforce-Sandbox). Das Zertifikat wird auch zur Authentifizierung von Cloud Build für automatisierte Bereitstellungen verwendet.

Die Details einiger Schritte in diesem Verfahren hängen davon ab, welche Salesforce-Version Sie verwenden. Achten Sie darauf, das richtige Zertifikat und die richtigen Schlüsselpaare für die ausgewählte Umgebung zu verwenden.

1. Wenn Sie Salesforce Lightning Experience verwenden, können Sie mit dem App-Manager verbundene Anwendungen erstellen. Führen Sie in Ihrer Salesforce-Organisation unter Einrichtung die folgenden Schritte aus:

   1. Geben Sie im Feld Schnellsuche App ein.
   2. Wählen Sie App-Manager aus.
   3. Klicken Sie auf Neue verbundene App.

   Wenn Sie Salesforce Classic verwenden, gehen Sie in Ihrer Salesforce-Organisation unter Einrichtung so vor:

   1. Geben Sie im Feld Schnellsuche Apps ein.
   2. Wählen Sie unter Build > Erstellen die Option Apps aus.
   3. Klicken Sie unter Verbundene Apps auf Neu.

2. Geben Sie als Namen Ihrer Anwendung Google Cloud DevOps ein.

   Damit wird Google_Cloud_DevOps in das Feld API-Name eingegeben.

3. Geben Sie die E-Mail-Adresse des Ansprechpartners und gegebenenfalls weitere Informationen für Ihre Anwendung ein.

4. Wählen Sie OAuth-Einstellungen aktivieren aus.

5. Geben Sie als Wert für die Callback-URL die folgende URL ein:

   http://localhost:1717/OauthRedirect
   

6. Um die Option zur Verwendung digitaler Signaturen zu aktivieren, klicken Sie auf Datei auswählen und wählen Sie dann die Zertifikatdatei salesforce.crt aus, die Sie zuvor heruntergeladen haben.

7. Fügen Sie unter Ausgewählte OAuth-Bereiche die folgenden OAuth-Bereiche hinzu:

   • Daten aufrufen und verwalten (api)
   • Anfragen jederzeit in Ihrem Namen ausführen (refresh_token, offline_access)
   • Zugriff auf Ihre Daten über das Web gewähren (web)

   

8. Klicken Sie auf Speichern und dann auf Weiter.

9. Notieren Sie sich den Wert von Consumer-Key, der im API-Abschnitt angezeigt wird. Sie benötigen ihn später, wenn Sie das Cloud Build-Manifest einrichten.

   Wenn Sie in einer Produktionsumgebung arbeiten, haben Sie für jede Bereitstellungsumgebung einen eigenen Schlüssel.

10. Klicken Sie auf Verwalten und ändern Sie dann die OAuth-Richtlinien. Klicken Sie dazu auf Richtlinien bearbeiten.

11. Setzen Sie Berechtigte Nutzer auf Vom Administrator genehmigte Nutzer sind vorautorisiert und bestätigen Sie die Auswahl.

12. Setzen Sie die IP-Lockerung auf IP-Einschränkungen lockern.

13. Klicken Sie auf Speichern.

14. Klicken Sie auf Profile verwalten und wählen Sie die Option Systemadministrator aus.

    Nach diesem Schritt können sich Nutzer, die dieses Profil annehmen, in der Salesforce-Befehlszeile anmelden.

15. Klicken Sie auf Speichern.

Google Cloud-Umgebung initialisieren

1. Legen Sie in Cloud Shell das Projekt fest, das Sie erstellt oder als Standardprojekt ausgewählt haben:

   gcloud config set project PROJECT_ID
   

   Ersetzen Sie PROJECT_ID durch die ID Ihres Google Cloud-Projekts.

2. Weisen Sie Einstellungen für Region und Zone zu:

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

   In dieser Anleitung verwenden Sie us-central1 als Region und us-central1-a als Zone.

3. Exportieren Sie die aktuelle Google-Projekt-ID in eine Umgebungsvariable namens GCP_PROJECT_NUMBER:

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

Salesforce-Schlüssel in Cloud Storage hochladen

1. Erstellen Sie in Cloud Shell einen Cloud Storage-Bucket in Ihrem Build-Projekt, um die privaten Salesforce-Schlüsseldateien zu speichern:

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

   Der Bucket muss einen global eindeutigen Namen haben. Dieser Befehl erstellt einen Bucket-Namen, der Ihre Google Cloud-Projekt-ID enthält.

2. Kopieren Sie die privaten Salesforce-Schlüssel, die Sie im Abschnitt Dev Hub-Organisation aktivieren erstellt haben, in den neuen Cloud Storage-Bucket:

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

GitHub-Repository erstellen

1. Klonen Sie in Cloud Shell das mit dieser Anleitung verknüpfte Repository:

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

2. Erstellen Sie ein neues GitHub-Repository mit dem Namen DEV_REPO_NAME.

   Ersetzen Sie DEV_REPO_NAME durch den Namen, den Sie dem Repository lokal zuweisen möchten.

   Dies ist das Repository, aus dem Entwickler Code abrufen oder in das sie Code per Push übertragen. Zum Zweck dieser Anleitung erstellen Sie dieses Repository in Ihrem eigenen GitHub-Konto.

3. Rufen Sie das geklonte Repository auf:

   cd salesforce-serverless-cicd-cloudbuild
   

4. Fügen Sie Ihr Entwickler-GitHub-Repository als Remote-Repository hinzu:

   git remote add github DEV_REPO_NAME
   

Cloud Build konfigurieren

In diesem Abschnitt führen Sie die erforderlichen Einrichtungsschritte aus, damit Cloud Build-Jobs ausgelöst werden, wenn Entwickler Pull-Anfragen erstellen, um ihre Arbeit in einem Release-Zweig zusammenzuführen.

Sie richten zwei Trigger für die CI/CD-Pipeline ein, die Sie in dieser Anleitung erstellen:

• Einen Trigger, der einen Cloud Build-Job ausführt, wenn ein Entwickler eine Pull-Anfrage erstellt, um Code im Release-Zweig zusammenzuführen. Eine typische Verwendung dieses Triggers ist die Ausführung von Unittests.
• Einen Trigger, der einen Cloud Build-Job ausführt, wenn eine Pull-Anfrage mit dem Release-Zweig zusammengeführt wird. Ein typischer Anwendungsfall für diesen Trigger ist die Bereitstellung von Änderungen in einer Ziel-Sandbox (Dev Hub in dieser Anleitung).

Basis-Image mit Salesforce DX erstellen

Cloud Build führt Ihren Build als eine Reihe von Schritten aus, wobei jeder Schritt in einem Docker-Container ausgeführt wird. Sie erstellen ein Basis-Docker-Container-Image, das die Salesforce-Befehlszeile enthält, und Cloud Build verwendet Salesforce-Befehlszeilen-Befehle, um den Job auszuführen.

1. Erstellen Sie in Cloud Shell ein Dockerfile für das zu erstellende Image:

   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. Exportieren Sie den Namen des Docker-Images in eine Umgebungsvariable mit dem Namen SFDX_BASE_IMAGE:

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

3. Erstellen Sie den Container mit Cloud Build und veröffentlichen Sie das Image in Container Registry:

   gcloud builds submit --tag ${SFDX_BASE_IMAGE}
   

Cloud Build-Job konfigurieren

Sie definieren einen Cloud Build-Job, indem Sie die Datei cloudbuild.yaml bearbeiten.

1. Erstellen Sie in Cloud Shell die Datei cloudbuild.yaml, um die Jobschritte zu definieren, die ausgeführt werden, wenn Cloud Build Code in Ihrer Salesforce Dev Hub-Organisation bereitstellt:

   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
   

   Mit der Datei wird Cloud Build für Folgendes konfiguriert:

   1. Herunterladen der Datei salesforce.key, die von Cloud Build zur Authentifizierung bei der Dev Hub-Organisation verwendet wird.
   2. Starten eines Docker-Containers, in dem die Salesforce-Befehlszeile installiert ist, und Herstellen einer Verbindung zur Dev Hub-Organisation mithilfe einer JWT-Zuweisung her. Cloud Build verwendet Konfigurationsparameter wie den Consumer-Key und den Salesforce-Nutzernamen, der in der Cloud Build-Trigger-Definition enthalten ist.
   3. Stellen Sie den Code bereit, der vom Entwickler an die Dev Hub-Organisation oder in eine andere Ziel-Sandbox in CI/CD-Pipelines gesendet wird.

2. Erstellen Sie eine weitere Datei mit dem Namen cloudbuild_pr.yaml, um die Jobschritte zu definieren, die ausgeführt werden, wenn Cloud Build Code aus einer Pull-Anfrage an eine temporäre Salesforce-Scratch-Organisation oder eine Sandbox für Testzwecke bereitstellt:

   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
   

   Mit der Datei wird Cloud Build für Folgendes konfiguriert:

   1. Laden Sie die Datei salesforce.key herunter, die von Cloud Build zur Authentifizierung bei der Dev Hub-Organisation verwendet wird.
   2. Starten Sie einen Docker-Container, in dem die Salesforce DX-Befehlszeile installiert ist, und stellen Sie mithilfe einer JWT-Zuweisung eine Verbindung zur Dev Hub-Organisation her. Cloud Build verwendet in der Cloud Build-Triggerdefinition Konfigurationsparameter wie den Consumer-Key und den Salesforce-Nutzernamen.
   3. Erstellen Sie eine neue Scratch-Organisation, um den Entwicklercode für automatisierte Tests bereitzustellen.
   4. Führen Sie Apex-Texte in der Scratch-Organisation aus.
   5. Geben Sie das Apex-Textergebnis aus, das in der Zusammenfassung der GitHub-Pull-Anfrage verfügbar ist.
   6. Löschen Sie die temporäre Scratch-Organisation.

Repository auf GitHub übertragen

1. Fügen Sie in Cloud Shell die neue Datei cloudbuild yaml und das Dockerfile dem Repository hinzu und übertragen Sie die Dateien per Push in den Hauptzweig des Repositorys DEV_REPO_NAME. Wenn Sie dazu aufgefordert werden, melden Sie sich bei GitHub an.

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

2. Erstellen Sie einen Release-Zweig, aus dem Entwickler Code abrufen oder in den sie Code per Push übertragen können. Geben Sie für diese Anleitung den Zweig release-sample ein.

   git checkout -b release-sample
   

3. Übertragen Sie den Zweig an GitHub:

   git push github release-sample
   

GitHub-Repository mit Cloud Build verbinden

1. Rufen Sie auf dem GitHub Marketplace die Seite Cloud Build-Anwendung auf.
2. Scrollen Sie nach unten und klicken Sie auf Mit Google Cloud Build einrichten. Wenn Sie dazu aufgefordert werden, melden Sie sich bei GitHub an.
3. Verbinden Sie Ihr Repository mit Cloud Build:
   1. Wählen Sie Nur Repositories auswählen aus.
   2. Wählen Sie in der Liste Repositories auswählen die Option Repository aus.
4. Klicken Sie auf Installieren.

5. Melden Sie sich in Google Cloud an.

   Auf der Seite Autorisierung werden Sie aufgefordert, die Google Cloud Build-Anwendung für die Verbindung mit Google Cloud zu autorisieren.

6. Klicken Sie auf Google Cloud Build durch GoogleCloudBuild autorisieren.

   Sie werden zur Google Cloud Console weitergeleitet.

7. Wählen Sie Ihr Google Cloud-Projekt aus.

8. Wenn Sie einverstanden sind, akzeptieren Sie die Bedingungen und klicken Sie dann auf Weiter.

9. Wählen Sie auf der Seite Repository auswählen das GitHub-Repository DEV_REPO_NAME aus.

10. Klicken Sie auf Repository verbinden.

11. Klicken Sie auf Push-Trigger erstellen.

Cloud Build-Triggerdefinition aktualisieren

Sie definieren die Details für den neuen Trigger, der erstellt wurde, als Sie im vorherigen Abschnitt auf Push-Trigger erstellen geklickt haben.

1. Öffnen Sie in der Google Cloud Console die Seite Cloud Build-Trigger.

   Zur Seite „Cloud Build-Trigger“

2. Klicken Sie beim neuen Trigger auf more_vert Menü und dann auf Bearbeiten.

3. Legen Sie Name auf pull-request-to-release-branch fest.

4. Ändern Sie die Beschreibung in Run unit tests when a pull request is created from a feature branch.

5. Ändern Sie Ereignis in Pull-Anfrage (nur GitHub-App).

6. Geben Sie unter Quelle im Textfeld Basis-Zweig den folgenden Ausdruck ein:

   ^release.*
   

7. Wählen Sie unter Konfiguration die Option Cloud Build-Konfigurationsdatei (YAML oder JSON) aus und geben Sie cloudbuild_pr.yaml in das Textfeld ein.

8. Erstellen Sie unter Substitutionsvariablen drei Variablen. Gehen Sie für jede Variable so vor:

   1. Klicken Sie auf Zeile hinzufügen.

   2. Legen Sie die Felder Variable und Wert wie in der folgenden Tabelle angegeben fest:

      Variable	Wert
      _BUCKET_NAME	Der Name des Cloud Storage-Buckets für die Salesforce-Schlüsseldatei im folgenden Format: salesforce-ref-PROJECT_ID Ersetzen Sie PROJECT_ID durch die ID Ihres Google Cloud-Projekts.
      _CONSUMER_KEY	Der Consumer-Key in der verbundenen Anwendung, die Sie in der Salesforce Dev Hub-Organisation erstellt haben.
      _SF_USERNAME	Der Salesforce-Nutzername für die Dev Hub-Organisation.

9. Klicken Sie auf Speichern.

   Schließen Sie diese Seite nicht. Auf dieser Seite arbeiten Sie dann beim nächsten Verfahren weiter.

Zweiten Cloud Build-Trigger erstellen

Im nächsten Schritt erstellen Sie einen weiteren Trigger, um Cloud Build-Jobs zu starten, wenn Commits im Release-Zweig durchgeführt werden. Dieser Trigger ruft einen Cloud Build-Job auf, um die Änderungen an Ihre Dev Hub-Organisation zu übertragen. In Ihrer DevOps-Pipeline müssen Sie dafür sorgen, dass nur autorisierte Mitarbeiter und Prozesse Änderungen im Release-Zweige übernehmen können.

1. Klicken Sie auf der Seite Cloud Build-Trigger auf Trigger erstellen, um einen neuen Trigger zu erstellen.
2. Legen Sie Name auf commits-to-release-branch fest.
3. Wählen Sie für Triggertyp die Option Push zu Zweig aus.
4. Wählen Sie in der Liste Repository Ihr GitHub-Salesforce-Repository aus.

5. Geben Sie im Textfeld Zweig (regulärer Ausdruck) folgenden Ausdruck ein:

   ^release.*
   

6. Wählen Sie unter Build-Konfiguration die Option Cloud Build-Konfigurationsdatei aus und geben Sie cloudbuild.yaml ein.

7. Erstellen Sie unter Substitutionsvariablen drei Variablen. Gehen Sie für jede Variable so vor:

   1. Klicken Sie auf Zeile hinzufügen.

   2. Legen Sie die Felder Variable und Wert wie in der folgenden Tabelle angegeben fest.

      Variable	Wert
      _BUCKET_NAME	Geben Sie den Namen des Buckets für die Salesforce-Schlüsseldatei im folgenden Format ein: salesforce-ref-PROJECT_ID Ersetzen Sie PROJECT_ID durch die ID Ihres Google Cloud-Projekts.
      _CONSUMER_KEY	Der Consumer-Key in der verbundenen Anwendung, die Sie in der Salesforce Dev Hub-Organisation erstellt haben.
      _SF_USERNAME	Der Salesforce-Nutzername für die Dev Hub-Organisation.

8. Klicken Sie auf Speichern.

Berechtigungen zum Lesen von Salesforce-Schlüsseln durch Cloud Build hinzufügen

• Fügen Sie in Cloud Shell Ihrem Cloud Build-Dienstkonto Berechtigungen hinzu, damit das Konto Salesforce-Schlüssel aus dem von Ihnen erstellten Cloud Storage-Bucket lesen kann:

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

Pipelines für Salesforce-Entwickler einrichten

Die in diesem Abschnitt beschriebenen Aufgaben richten sich an Salesforce-Entwickler.

Wenn Sie die Schritte im vorherigen Teil dieser Anleitung ausgeführt haben, die im Abschnitt für Administratoren und Leads enthalten sind, verwenden Sie andere Anmeldedaten, um die Schritte in diesem Abschnitt auszuführen.

Die Installationsschritte der Salesforce DX-Befehlszeile können je nach verwendetem Betriebssystem variieren. Die Schritte in diesem Abschnitt beschreiben die Schritte für Debian Linux. Eine Anleitung für macOS und Windows finden Sie in der Salesforce-Dokumentation unter Salesforce-Befehlszeile installieren.

Salesforce DX-Befehlszeile einrichten

In diesem Abschnitt installieren Sie die Salesforce-Befehlszeile und richten die Autorisierung dafür ein.

1. Wechseln Sie auf Ihrem lokalen Rechner (nicht in Cloud Shell) zum Basisverzeichnis:

   cd $HOME
   

2. Installieren Sie die Tools xz-utils und wget.

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

3. Salesforce-Befehlszeile installieren:

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

4. Erstellen Sie ein sfdx-Verzeichnis:

   mkdir sfdx
   

5. Extrahieren Sie die heruntergeladene TAR-Datei:

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

6. Installieren Sie die Befehlszeile:

   ./sfdx/install
   

   Die Salesforce-Befehlszeile wird in /usr/local/bin/sfdx installiert.

7. Die Befehlszeile muss korrekt eingerichtet sein:

   sfdx
   

   Die Ausgabe sieht etwa so aus:

   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
   

Lokale Entwicklungsumgebung mit Ihrer Salesforce Dev Hub-Organisation verbinden

1. Melden Sie sich vom lokalen Computer aus mit den Anmeldedaten für eine Entwicklerrolle in Ihrer Salesforce-Organisation an:

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

   Ersetzen Sie YOUR_HUB_ORG durch einen geeigneten Alias für Ihre Dev Hub-Organisation.

   Mit diesem Befehl wird ein Webbrowser auf Ihrem lokalen Computer geöffnet, sodass Sie ihn nicht auf einer VM ausführen können, mit der Sie verbunden sind.

GitHub-Repository klonen

1. Klonen Sie das GitHub-Repository, das von Ihrem Salesforce-Administrator erstellt wurde:

   git clone DEV_REPO_NAME -o github
   

2. Wechseln Sie zum Verzeichnis des geklonten Repositorys:

   cd DEV_REPO_NAME
   

Salesforce-Codebasis und Metadaten in eine Scratch-Organisation verschieben

In diesem Abschnitt übertragen Sie die Codebasis und die Metadaten in eine Scratch-Organisation, sodass für sie Unittests durchgeführt werden können.

1. Exportieren Sie auf Ihrem lokalen Computer den Dev Hub-Nutzernamen in eine Umgebungsvariable mit dem Namen SALESFORCE_USERNAME:

   export SALESFORCE_USERNAME=YOUR_DEVHUB_USERNAME
   

   Ersetzen Sie YOUR_DEVHUB_USERNAME durch den zuvor eingerichteten Nutzernamen.

2. Erstellen Sie eine Scratch-Organisation, um das Repository zu testen, das Sie für diese Anleitung geklont haben:

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

3. Übertragen Sie die Metadaten und den Code per Push an die Scratch-Organisation:

   sfdx force:source:push
   

4. Erstellen Sie eine URL für die Scratch-Organisation und rufen Sie sie in einem Browserfenster auf:

   sfdx force:org:open
   

Der nächste Schritt im Lebenszyklus eines Projekts besteht normalerweise darin, Unittests auszuführen und von Ihnen entwickelte Features zu prüfen. Dies wird in dieser Anleitung nicht erläutert, da Sie mit bereits validiertem Beispielcode arbeiten.

Code per Push in ein Quellcode-Repository übertragen

1. Erstellen Sie auf Ihrem lokalen Computer einen neuen Zweig namens feature-1:

   git checkout -b feature-1
   

2. Übertragen Sie die Änderungen per Push in ein Quellcode-Repository:

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

   In dieser Anleitung verwenden Sie GitHub als Quellcode-Tool.

Deployment testen

In diesem Abschnitt werden Tests beschrieben, mit denen Sie prüfen können, ob die von Ihnen erstellten Trigger funktionieren. Das von Ihrem Salesforce-Administrator erstellte Repository enthält eine Beispieltestklasse.

1. Erstellen Sie auf Ihrem lokalen Computer (nicht in Cloud Shell) einen neuen Git-Zweig:

   git checkout -b feature-1
   

2. Öffnen Sie in einem Texteditor die folgende Datei:

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

3. Ändern Sie in der Anweisung System.assertEquals den Wert 101 in 102, damit der Test fehlschlägt. Nachdem Sie die Änderung vorgenommen haben, speichern Sie die Datei, aber lassen Sie sie geöffnet, da Sie sie später wieder ändern.

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

4. Fügen Sie dem Feature-Zweig die Änderung hinzu und führen Sie einen Commit durch:

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

5. Erstellen Sie eine Pull-Anfrage, um Ihren Code mit dem Release-Beispiel-Zweig zu verknüpfen.

   Ein neuer Cloud Build-Job wird ausgelöst. Der Job schlägt jedoch fehl, weil der Unittest fehlschlägt.

6. Rufen Sie die Seite Cloud Build auf, um sich den Status des Builds anzeigen zu lassen.

   Zur Cloud Build-Seite

7. Gehen Sie auf der Seite Cloud Build zum Abschnitt Verlauf.

   Sie sehen für den Job das folgende Build-Log, das darauf hinweist, dass die Test-Assertion fehlgeschlagen ist.

   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. Ändern Sie in der Datei ./force-app/main/default/classes/SampleTest.cls den Wert 102 zurück zu 101, damit der Test erfolgreich ist:

   @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. Fügen Sie dem Feature-Zweig die Änderung hinzu und führen Sie einen Commit durch:

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

   Der Commit-Vorgang löst einen Cloud Build-Job aus.

10. Wenn der Job abgeschlossen ist, prüfen Sie die Pull-Anfrage in GitHub und führen Sie sie im Zweig release-sample zusammen.

    In Produktionsworkflows ist die Berechtigung zum Zusammenführen von Pull-Anfragen in der Regel auf DevOps-Leads und Administratoren beschränkt. Weitere Informationen zur Einrichtung finden Sie auf der GitHub-Website unter Zusammenführbarkeit von Pull-Anfragen definieren.

11. Überprüfen Sie in der Google Cloud Console den Cloud Build-Job, der automatisch ausgelöst wird, wenn Sie die Pull-Anfrage mit dem Release-Beispiel-Zweig zusammenführen.

12. Wenn der Job abgeschlossen ist, melden Sie sich in Ihrer Dev Hub-Organisation an. Sie können sich als Entwickler oder Administrator anmelden.

    In dieser Salesforce-Organisation sind die Codeänderungen des Entwicklers verfügbar. Sie finden sie auf der Seite Einrichtung unter Benutzerdefinierter Code/Apex-Klassen.