Ce tutoriel explique comment créer un pipeline d'intégration continue/de déploiement continu (CI/CD) sans serveur pour Salesforce à l'aide de Salesforce Developer Experience (SFDX) et Cloud Build. Les pipelines Cloud Build utilisent la conteneurisation. Les pipelines exécutent les compilations sous la forme d'une série d'étapes de compilation, où chaque étape est exécutée dans un conteneur Docker. Le pipeline peut évoluer à la hausse ou à la baisse en fonction de la charge, sans avoir à préprovisionner les serveurs. Il propose également des compilations rapides, cohérentes et automatisées.
Ce tutoriel s'adresse à toute personne chargée de la conception, du développement et de la maintenance des workflows DevOps au sein d'une organisation. Il peut s'agir d'architectes, d'équipes DevOps et d'ingénieurs. Les différentes sections du document illustrent les parties du pipeline en fonction des rôles. Par exemple, une partie concerne les administrateurs et les responsables DevOps, et une autre les développeurs Salesforce.
Dans le présent document, nous partons du principe que vous connaissez bien Salesforce DX, la CLI Salesforce, Git, GitHub, Docker, les produits Google Cloud tels que Cloud Build et les concepts de conteneurisation. Nous supposons également que vous possédez un compte GitHub.
Les cycles de développement des logiciels peuvent varier considérablement. Dans ce tutoriel, nous partons du principe que vous suivez une méthodologie de publication agile.
Objectifs
- Configurer Salesforce Developer Experience
- Configurer une stratégie d'embranchement Git
- Configurer Cloud Build
- Exécuter le pipeline CI/CD pour Salesforce à l'aide des outils de compilation Google Cloud et de GitHub
Coûts
Ce tutoriel utilise les composants facturables suivants de Google Cloud :
Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût.
Des frais Salesforce peuvent également s'appliquer. Dans ce tutoriel, vous utilisez une organisation Salesforce Developer Edition, qui peut être gratuite. Pour en savoir plus, consultez la page Salesforce sur Developer Edition.
Avant de commencer
-
Dans Google Cloud Console, sur la page de sélection du projet, sélectionnez ou créez un projet Google Cloud.
-
Vérifiez que la facturation est activée pour votre projet Google Cloud.
-
Activez l'API Cloud Build
-
Dans la console Google Cloud, activez Cloud Shell.
- Veillez à disposer d'un compte Salesforce pouvant assumer le rôle d'e lorganisation Dev Hub. Si vous n'avez pas d'organisation, vous pouvez créer un compte Developer Edition sur le site Salesforce pour les développeurs.
Une fois que vous avez terminé ce tutoriel, évitez de continuer à payer des frais en supprimant les ressources que vous avez créées. Consultez la page Effectuer un nettoyage pour en savoir plus.
Architecture
Le schéma suivant illustre l'architecture du workflow CI/CD que vous créez dans ce tutoriel. Dans cette architecture, les projets sont organisés sous forme de releases. Les développeurs qui souhaitent travailler sur une fonctionnalité créent une nouvelle branche de fonctionnalité à partir d'une branche de release.
Le schéma illustre le flux suivant :
- Les développeurs créent dans GitHub des branches de fonctionnalités pour les fonctionnalités qu'ils développent.
- Les développeurs terminent le travail de développement et effectuent des tests unitaires dans les organisations tests Salesforce.
- Les développeurs valident et déploient leur travail de développement dans leur dépôt de code source (GitHub dans ce tutoriel).
- Les développeurs créent une demande d'extraction pour fusionner leur travail dans la branche de release.
- La création d'une demande d'extraction déclenche automatiquement une tâche Cloud Build pour exécuter des tests.
- Le personnel responsable (généralement des responsables d'équipe) examine et approuve les demandes d'extraction pour fusionner le travail de développement dans la branche de release.
- Une fusion dans la branche de release déclenche automatiquement une tâche Cloud Build pour déployer le codebase à des fins de contrôle qualité ou dans d'autres environnements Salesforce.
- Des tests manuels et examens sont éventuellement effectués dans un environnement de contrôle qualité.
- Le personnel responsable crée une demande d'extraction pour fusionner le code dans la branche
main. - La demande d'extraction envoyée à la branche
maindéclenche une tâche Cloud Build pour déployer le code en production.
Les développeurs qui souhaitent travailler sur des projets commencent par cloner le dépôt du projet à partir de l'outil de contrôle de source de l'entreprise (GitHub dans ce tutoriel). Le schéma suivant représente cette stratégie sous forme de graphique.
Comme le montre le schéma, la stratégie d'embranchement comprend les éléments suivants :
- Une branche principale. Le code de la branche principale reflète la version actuelle du code en cours d'exécution en production.
- Une branche de release. Une branche de release est une branche de longue durée (par rapport à une branche de fonctionnalité) qui coordonne toutes les modifications et le code associés à une release. Une organisation crée une branche de release pour chaque nouvelle release.
- Une ou plusieurs branches de fonctionnalités. Les branches de fonctionnalités permettent d'isoler le travail en cours de la version la plus récente du code dans la branche principale. En règle générale, plusieurs branches de fonctionnalités forment une branche de release. Pour les développeurs, il est recommandé de créer des branches de fonctionnalités pour corriger les bugs.
Une fois que les développeurs ont cloné un dépôt de projet, ils travaillent sur leur ordinateur local ou dans une organisation test Salesforce. Ils peuvent utiliser une organisation test pour exécuter des tests unitaires sur les modifications qu'ils effectuent. Si les tests unitaires réussissent, ils valident leur code et le transmettent dans le dépôt de code source. Ils génèrent ensuite une demande d'extraction de leur code à fusionner dans la branche de release parente.
La demande d'extraction déclenche automatiquement une tâche Cloud Build qui effectue les opérations suivantes :
- Crée une organisation test afin d'exécuter des tests unitaires
- Met à jour la demande d'extraction avec le résultat des tests
À ce stade, les chefs d'équipe et les propriétaires de produits peuvent examiner la demande d'extraction. Si la demande est approuvée, les modifications sont fusionnées dans la branche de release.
Selon votre cycle de développement logiciel, des étapes automatisées supplémentaires peuvent être déclenchées en fonction d'une fusion avec la branche de release. Exemple d'étape automatisée : déployer le code validé sur un bac à sable supérieur, tel qu'un bac à sable de contrôle qualité ou de test d'intégration système.
Vous pouvez également configurer Cloud Build pour envoyer des notifications de compilation et effectuer des actions supplémentaires à l'aide de Cloud Functions, Cloud Run ou d'autres outils Google Cloud. (Ces actions supplémentaires ne sont pas abordées dans ce tutoriel.) Cette approche offre la flexibilité nécessaire pour adapter le pipeline en fonction de votre framework DevOps d'entreprise.
Pour des raisons de simplicité, dans ce tutoriel, vous déployez l'exemple de codebase sur une seule organisation Salesforce (Dev Hub). Lorsque vous créez un pipeline CI/CD pour la production, vous utilisez l'architecture illustrée plus tôt et automatisez les déploiements sur des bacs à sable appartenant à votre cycle de développement de logiciels.
Personas généralement impliqués dans le développement de logiciels
Chaque organisation est différente, et chacune dispose de son propre ensemble de rôles et d'équipes. Le tableau suivant répertorie les principaux personss (rôles) qui interagissent généralement avec les pipelines DevOps Salesforce comme celui décrit dans ce tutoriel.
Les personnes occupant différents rôles ont différentes responsabilités pour la configuration des pipelines Salesforce. Par conséquent, le tutoriel comprend deux chemins. L'un est destiné aux administrateurs et aux responsables DevOps, et l'autre aux développeurs.
| Personna | Responsabilités |
|---|---|
| Administrateur ou responsable DevOps |
|
| Développeur Salesforce |
|
| Responsable de contrôle qualité |
|
| Responsable de release |
|
Configurer des pipelines pour les administrateurs Salesforce et les responsables DevOps
Cette section décrit les tâches que les administrateurs et les équipes DevOps effectuent pour configurer le workflow CI/CD.
Activer l'organisation Dev Hub
- Connectez-vous à votre organisation de production Salesforce.
Dans l'onglet Setup (Configuration), dans la zone Quick Find (Recherche rapide), saisissez
Dev Hub, puis sélectionnez Dev Hub.
Activez Dev Hub.
Cette étape vous permet de configurer une organisation test. Utilisez l'organisation test pour déployer l'exemple de code du tutoriel dans une organisation Salesforce Developer Edition.
Créer un certificat et une paire de clés
Après avoir activé l'organisation Dev Hub, vous devez générer un certificat et une paire de clés pouvant servir à s'authentifier auprès de l'organisation Salesforce Dev Hub. Vous utiliserez ce certificat et cette paire de clés lorsque vous configurerez Cloud Build aux étapes suivantes.
Pour les pipelines CI/CD de production, vous devez générer des certificats supplémentaires pour vous authentifier auprès des bacs à sable Salesforce. (Vous ne créez pas ces certificats supplémentaires dans le cadre de ce tutoriel.) Lorsque vous générez des certificats et des paires de clés pour chaque environnement, veillez à leur donner des noms identifiables, comme dans les exemples suivants :
- Production (organisation Dev Hub) :
salesforce.keyetsalesforce.crt. Vous utiliserez ces noms dans la procédure qui suit. - Bac à sable de contrôle qualité :
salesforce_qa.keyetsalesforce_qa.crt. - Bac à sable de développement intégré :
salesforce_dev.keyetsalesforce_dev.crt.
Pour générer un certificat et une paire de clés, procédez comme suit :
Dans Cloud Shell, générez un certificat et une paire de clés afin que Cloud Build puisse s'authentifier auprès de votre organisation Salesforce Dev Hub à partir de la CLI Salesforce :
openssl req -x509 -sha256 -nodes -days 36500 -newkey \ rsa:2048 -keyout salesforce.key -out \ salesforce.crtVous êtes invité à saisir des informations pour identifier le certificat. Pour ce tutoriel, ces valeurs n'ont pas d'importance. Vous pouvez donc appuyer sur Entrée pour accepter les valeurs par défaut.
Notez que dans la commande, vous utilisez les noms
salesforce.keyetsalesforce.crt, car vous créez le certificat et la paire de clés pour l'organisation Dev Hub.Cliquez sur More (Plus), puis sélectionnez Download File (Télécharger le fichier).
Dans le champ Chemin d'accès complet au fichier, saisissez le nom de fichier suivant, puis cliquez sur Télécharger :
salesforce.crtCette étape déclenche le téléchargement en local du certificat que vous avez généré. Dans la section suivante, vous allez importer le certificat dans votre organisation Salesforce.
Créer des applications connectées dans Salesforce
Dans cette section, vous allez créer une application connectée que Cloud Build peut utiliser pour déployer votre code Salesforce. Pour ce tutoriel, vous ne déployez du code que dans l'organisation Dev Hub. Dans un environnement de production, vous déployez du code pour chaque bac à sable et pour l'organisation de production dans laquelle vous souhaitez que Cloud Build déploie votre code Salesforce pour le pipeline DevOps.
Dans le cadre de ce processus, vous utilisez le certificat et la paire de clés générés à la section précédente. Le certificat est la clé publique permettant d'authentifier le client Salesforce dans une session Cloud Shell avec l'organisation Salesforce Dev Hub (bac à sable Salesforce). Le certificat permet également d'authentifier Cloud Build pour les déploiements automatisés.
Les détails de certaines étapes de la procédure suivante varient selon l'édition de Salesforce que vous utilisez. Assurez-vous d'utiliser le certificat et les paires de clés appropriés pour l'environnement sélectionné.
Avec Salesforce Lightning Experience, utilisez le Gestionnaire d'applications pour créer des applications connectées. Dans Setup (Configuration) dans votre organisation Salesforce, procédez comme suit :
- Dans la zone Quick Find (Recherche rapide), saisissez
App. - Sélectionnez App Manager (Gestionnaire d'applications).
- Cliquez sur New Connected App (Nouvelle application connectée).
Si vous utilisez Salesforce Classic, dans Setup (Configuration) dans votre organisation Salesforce, procédez comme suit :
- Dans la zone Quick Find (Recherche rapide), saisissez
Apps. - Sous Build > Create (Compiler > Créer), sélectionnez Apps (Applications).
- Sous Connected Apps (Applications connectées), cliquez sur New (Nouveau).
- Dans la zone Quick Find (Recherche rapide), saisissez
Pour le nom de votre application, saisissez
Google Cloud DevOps.Cette valeur renseigne
Google_Cloud_DevOpsdans le champ API Name (Nom de l'API).Saisissez l'adresse e-mail du contact et toute autre information appropriée sur votre application.
Sélectionnez Enable OAuth Settings (Activer les paramètres OAuth).
Dans le champ Callback URL (URL de rappel), saisissez l'URL suivante :
http://localhost:1717/OauthRedirectPour activer l'option de signature numérique, cliquez sur Choose File (Choisir le fichier), puis sélectionnez le fichier
salesforce.crtque vous avez téléchargé précédemment.Ajoutez les niveaux d'accès OAuth suivants dans Selected OAuth Scopes (Niveaux d'accès OAuth sélectionnés) :
- Access and manage your data (api) (Accéder à vos données et les gérer – API)
- Perform requests on your behalf at any time (refresh_token, offline_access) (Effectuer des requêtes en votre nom à tout moment – refresh_token, offline_access)
- Provide access to your data via the web (web) (Fournir un accès à vos données via le Web – Web)
Cliquez sur Save (Enregistrer), puis sur Continue (Continue).
Notez la valeur de la clé client affichée dans la section d'API. Vous en aurez besoin lorsque vous configurerez le fichier manifeste Cloud Build.
Si vous travaillez dans un environnement de production, vous disposez d'une clé pour chaque environnement de déploiement.
Cliquez sur Manage (Gérer), puis pour modifier les règles OAuth, cliquez sur Edit Policies (Modifier les règles).
Définissez Permitted users (Utilisateurs autorisés) sur Admin Approved Users are Pre-Authorized (Les utilisateurs validés par l'administrateur sont pré-autorisés), puis confirmez votre choix.
Définissez la relaxe IP sur Relax IP Restrictions (Assouplir les restrictions IP).
Cliquez sur Enregistrer.
Cliquez sur Manage Profiles (Gérer les profils) et sélectionnez l'option System Administrator (Administrateur système).
Après cette étape, les utilisateurs avec ce profil peuvent se connecter à la CLI Salesforce.
Cliquez sur Enregistrer.
Initialiser l'environnement Google Cloud
Dans Cloud Shell, définissez le projet que vous avez créé ou sélectionné comme projet par défaut :
gcloud config set project PROJECT_IDRemplacez PROJECT_ID par l'ID de votre projet Google Cloud.
Attribuez des paramètres pour la région et la zone :
gcloud config set compute/region us-central1 gcloud config set compute/zone us-central1-aDans ce tutoriel, la région est
us-central1et la zone estus-central1-a.Exportez l'ID du projet Google actuel vers une variable d'environnement nommée
GCP_PROJECT_NUMBER:export GCP_PROJECT_NUMBER=$(gcloud projects describe $DEVSHELL_PROJECT_ID --format='value(projectNumber)')
Importer les clés Salesforce dans Cloud Storage
Dans Cloud Shell, créez un bucket Cloud Storage dans votre projet de compilation pour stocker les fichiers de clé privée Salesforce :
gsutil mb -p ${DEVSHELL_PROJECT_ID} -l us-central1 \ gs://salesforce-ref-${DEVSHELL_PROJECT_ID}Le bucket doit avoir un nom unique. Cette commande crée un nom de bucket comprenant votre ID de projet Google Cloud.
Copiez les clés privées Salesforce que vous avez générées dans la section Activer l'organisation Dev Hub dans le nouveau bucket Cloud Storage :
gsutil cp salesforce.key gs://salesforce-ref-${DEVSHELL_PROJECT_ID}
Créer votre dépôt GitHub
Dans Cloud Shell, clonez le dépôt associé à ce tutoriel :
git clone https://github.com/GoogleCloudPlatform/salesforce-serverless-cicd-cloudbuildCréez un dépôt GitHub nommé
DEV_REPO_NAME.Remplacez DEV_REPO_NAME par le nom que vous souhaitez attribuer localement au dépôt.
Il s'agit du dépôt à partir duquel les développeurs extraient du code ou vers lequel ils en envoient. Pour les besoins de ce tutoriel, vous allez créer ce dépôt dans votre propre compte GitHub.
Accédez au dépôt cloné :
cd salesforce-serverless-cicd-cloudbuildAjoutez le dépôt GitHub du développeur en tant que dépôt distant :
git remote add github DEV_REPO_NAME
Configurer Cloud Build
Dans cette section, vous allez effectuer les étapes de configuration requises pour déclencher des tâches Cloud Build lorsque les développeurs génèrent des demandes d'extraction pour fusionner leur travail dans une branche de release.
Vous allez configurer deux déclencheurs pour le pipeline CI/CD que vous créez dans ce tutoriel :
- Déclencheur qui exécute une tâche Cloud Build lorsqu'un développeur crée une demande d'extraction pour fusionner du code dans la branche de release. Une utilisation courante de ce déclencheur consiste à exécuter des tests unitaires.
- Déclencheur qui exécute une tâche Cloud Build lorsqu'une demande d'extraction est fusionnée dans la branche de release. Une utilisation courante de ce déclencheur consiste à déployer des modifications dans un bac à sable de destination (Dev Hub dans ce tutoriel).
Créer une image de base incluant Salesforce DX
Cloud Build exécute votre compilation sous la forme d'un ensemble d'étapes, où chaque étape s'exécute dans un conteneur Docker. Vous compilez une image de conteneur Docker de base incluant la CLI Salesforce, et Cloud Build utilise les commandes de CLI Salesforce pour exécuter la tâche.
Dans Cloud Shell, créez un Dockerfile pour l'image à compiler :
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" ] EOFExportez le nom de l'image Docker vers une variable d'environnement nommée
SFDX_BASE_IMAGE:export SFDX_BASE_IMAGE="gcr.io/${DEVSHELL_PROJECT_ID}/salesforcedx-base-image:1"Créez votre conteneur avec Cloud Build, puis publiez l'image dans Container Registry :
gcloud builds submit --tag ${SFDX_BASE_IMAGE}
Configurer la tâche Cloud Build
Pour définir une tâche Cloud Build, modifiez le fichier cloudbuild.yaml.
Dans Cloud Shell, créez un fichier
cloudbuild.yamlpour définir les étapes de la tâche à exécuter lorsque Cloud Build déploie du code dans votre organisation 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__ EOFCe fichier configure Cloud Build pour effectuer les opérations suivantes :
- Télécharger le fichier
salesforce.keypermettant à Cloud Build de s'authentifier auprès de l'organisation Dev Hub. - Démarrer un conteneur Docker sur lequel la CLI Salesforce est installée, puis se connecter à l'organisation Dev Hub à l'aide d'une autorisation JWT. Cloud Build utilise des paramètres de configuration tels que la clé client et le nom d'utilisateur Salesforce figurant dans la définition du déclencheur Cloud Build.
- Déployer le code transmis par le développeur à l'organisation Dev Hub ou à un autre bac à sable de destination dans les pipelines CI/CD de production.
- Télécharger le fichier
Créez un autre fichier nommé
cloudbuild_pr.yamlpour définir les étapes de la tâche à exécuter lorsque Cloud Build déploie le code à partir d'une demande d'extraction vers une organisation de travail ou un bac à sable Salesforce temporaire à des fins de 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__ EOFCe fichier configure Cloud Build pour effectuer les opérations suivantes :
- Télécharger le fichier
salesforce.keypermettant à Cloud Build de s'authentifier auprès de l'organisation Dev Hub. - Démarrer un conteneur Docker sur lequel la CLI Salesforce DX est installée, puis se connecter à l'organisation Dev Hub à l'aide d'une autorisation JWT. Cloud Build utilise des paramètres de configuration tels que la clé client et le nom d'utilisateur Salesforce figurant dans la définition du déclencheur Cloud Build.
- Créer une organisation test afin de déployer le code du développeur pour les tests automatisés.
- Exécuter les textes Apex dans l'organisation test.
- Générer le résultat texte Apex, qui est disponible dans le récapitulatif de la demande d'extraction GitHub.
- Supprimer l'organisation test temporaire.
- Télécharger le fichier
Transférer votre dépôt vers GitHub
Dans Cloud Shell, ajoutez le nouveau fichier
cloudbuild yamlet le Dockerfile au dépôt, puis transférez les fichiers dans la branche principale du dépôt DEV_REPO_NAME. Lorsque vous y êtes invité, connectez-vous à GitHub.git add . git commit -m "Added cloud build configuration" git push github mainCréez une branche de release à partir de laquelle les développeurs peuvent extraire du code ou vers laquelle ils peuvent en transférer. Pour ce tutoriel, nommez la branche
release-sample.git checkout -b release-sampleTransférez la branche vers GitHub :
git push github release-sample
Connecter votre dépôt GitHub à Cloud Build
- Accédez à la page Application Cloud Build sur la place de marché GitHub.
- Faites défiler la page, puis cliquez sur Setup with Google Cloud Build (Configurer avec Google Cloud Build). Si vous y êtes invité, connectez-vous à GitHub.
- Connectez votre dépôt à Cloud Build :
- Sélectionnez Sélectionner uniquement les dépôts.
- Dans la liste Select repositories (Sélectionner les dépôts), sélectionnez le dépôt.
- Cliquez sur Installer.
Connectez-vous à Google Cloud.
La page Autorisation s'affiche. Vous êtes alors invité à autoriser l'application Google Cloud Build à se connecter à Google Cloud.
Cliquez sur Autoriser Google Cloud Build par GoogleCloudBuild.
Vous êtes redirigé vers Google Cloud Console.
Sélectionnez votre projet Google Cloud.
Acceptez les conditions d'utilisation, puis cliquez sur Suivant.
Sur la page Sélectionner un dépôt, sélectionnez le dépôt GitHub DEV_REPO_NAME.
Cliquez sur Connecter un dépôt.
Cliquez sur Créer un déclencheur push.
Mettre à jour la définition du déclencheur Cloud Build
Vous définissez les détails du nouveau déclencheur qui a été créé lorsque vous avez cliqué sur Créer un déclencheur push dans la section précédente.
Dans Google Cloud Console, ouvrez la page Déclencheurs Cloud Build.
Cliquez sur Menu pour le nouveau déclencheur, puis sur Modifier.
Pour Nom, définissez
pull-request-to-release-branch.Remplacez la description par
Run unit tests when a pull request is created from a feature branch.Remplacez Événement par Demande d'extraction (application GitHub seulement).
Pour Source, dans la zone de texte Branche de base, saisissez l'expression suivante :
^release.*Dans le champ Configuration, sélectionnez Fichier de configuration Cloud Build (yaml ou json) et saisissez
cloudbuild_pr.yamldans la zone de texte.Sous Variables de substitution, créez trois variables. Pour chaque variable, procédez comme suit :
- Cliquez sur Ajouter un élément.
Définissez les champs Variable et Valeur comme indiqué dans le tableau suivant :
Variable Valeur _BUCKET_NAMENom du bucket Cloud Storage pour le fichier de clé Salesforce, au format suivant :
salesforce-ref-PROJECT_ID
Remplacez PROJECT_ID par l'ID de votre projet Google Cloud._CONSUMER_KEYClé client de l'application connectée créée dans l'organisation Salesforce Dev Hub. _SF_USERNAMENom d'utilisateur Salesforce pour l'organisation Dev Hub.
Cliquez sur Enregistrer.
Ne fermez pas cette page. Vous allez travailler sur cette page dans le cadre de la procédure suivante.
Créer un deuxième déclencheur Cloud Build
L'étape suivante consiste à créer un autre déclencheur pour démarrer des tâches Cloud Build lorsque des commits sont effectués sur la branche de release. Ce déclencheur appelle une tâche Cloud Build pour appliquer les modifications à votre organisation Dev Hub. Dans votre pipeline DevOps, vous devez vous assurer que seuls le personnel et les processus autorisés peuvent valider des modifications apportées à la branche de release.
- Sur la page Déclencheurs Cloud Build, cliquez sur Créer un déclencheur pour créer un déclencheur.
- Pour Nom, définissez
commits-to-release-branch. - Pour Type de déclencheur, sélectionnez Déployer sur une branche.
- Dans la liste Dépôt, sélectionnez votre dépôt GitHub Salesforce.
Dans la zone de texte Branche (expression régulière), saisissez l'expression suivante :
^release.*Dans le champ Configuration de la compilation, sélectionnez Fichier de configuration Cloud Build et saisissez
cloudbuild.yaml.Sous Variables de substitution, créez trois variables. Pour chaque variable, procédez comme suit :
- Cliquez sur Ajouter un élément.
Définissez les champs Variable et Valeur comme indiqué dans le tableau suivant.
Variable Valeur _BUCKET_NAMESaisissez le nom du bucket pour le fichier de clé Salesforce, au format suivant :
salesforce-ref-PROJECT_ID
Remplacez PROJECT_ID par l'ID de votre projet Google Cloud._CONSUMER_KEYClé client de l'application connectée créée dans l'organisation Salesforce Dev Hub. _SF_USERNAMENom d'utilisateur Salesforce pour l'organisation Dev Hub.
Cliquez sur Enregistrer.
Ajouter des autorisations pour permettre à Cloud Build de lire les clés Salesforce
Dans Cloud Shell, ajoutez des autorisations à votre compte de service Cloud Build pour permettre à ce compte de lire les clés Salesforce à partir du bucket Cloud Storage que vous avez créé :
gsutil iam ch serviceAccount:$GCP_PROJECT_NUMBER@cloudbuild.gserviceaccount.com:objectViewer \ gs://salesforce-ref-${DEVSHELL_PROJECT_ID}
Configurer des pipelines pour les développeurs Salesforce
Les tâches décrites dans cette section sont destinées aux développeurs Salesforce.
Si vous avez effectué les étapes décrites précédemment dans ce tutoriel dans la section destinée aux administrateurs et aux responsables, veillez à utiliser un autre ensemble d'identifiants pour exécuter les étapes de cette section.
Les étapes d'installation de la CLI Salesforce DX peuvent varier en fonction du système d'exploitation que vous utilisez. Cette section décrit les étapes pour Debian Linux. Pour obtenir des instructions sur macOS et Windows, reportez-vous à la procédure d'installation de la CLI Salesforce dans la documentation Salesforce.
Configurer la CLI Salesforce DX
Dans cette section, vous allez installer la CLI Salesforce et configurer l'autorisation correspondante.
Sur votre machine locale (pas dans Cloud Shell), accédez au répertoire d'accueil :
cd $HOMEInstallez les outils
xz-utilsetwget:sudo apt-get install --assume-yes xz-utils wgetInstallez la CLI Salesforce :
wget https://developer.salesforce.com/media/salesforce-cli/sfdx-linux-amd64.tar.xzCréez un répertoire
sfdx:mkdir sfdxExtrayez le fichier TAR téléchargé :
tar xJf sfdx-linux-amd64.tar.xz -C sfdx --strip-components 1Installez la CLI :
./sfdx/installLa CLI Salesforce est installée dans
/usr/local/bin/sfdx.Vérifiez que la CLI est correctement configurée :
sfdxLe résultat ressemble à ce qui suit :
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
Connecter votre environnement de développement local à l'organisation Salesforce Dev Hub
Depuis votre machine locale, connectez-vous à l'organisation Salesforce à l'aide d'identifiants associés à un rôle de développeur :
sfdx force:auth:web:login --setalias YOUR_HUB_ORGRemplacez YOUR_HUB_ORG par un alias approprié pour votre organisation Dev Hub.
Cette commande ouvre un navigateur Web sur votre machine locale. Vous ne pouvez donc pas l'exécuter sur une VM à laquelle vous êtes connecté.
Cloner le dépôt GitHub
Clonez le dépôt GitHub créé par votre administrateur Salesforce :
git clone DEV_REPO_NAME -o githubAccédez au répertoire du dépôt cloné :
cd DEV_REPO_NAME
Transférer le codebase et les métadonnées Salesforce vers une organisation test
Dans cette section, vous allez transférer le codebase et les métadonnées vers une organisation test afin qu'ils puissent subir des tests unitaires.
Sur votre machine locale, exportez votre nom d'utilisateur Dev Hub vers une variable d'environnement nommée
SALESFORCE_USERNAME:export SALESFORCE_USERNAME=YOUR_DEVHUB_USERNAMERemplacez YOUR_DEVHUB_USERNAME par le nom d'utilisateur que vous avez configuré précédemment.
Créez une organisation test afin de tester le dépôt que vous avez cloné dans le cadre de ce tutoriel :
sfdx force:org:create \ --setdefaultusername \ --definitionfile config/project-scratch-def.json \ --targetdevhubusername ${SALESFORCE_USERNAME} \ --setalias feature-test-scratch-orgDéployez les métadonnées et le code dans l'organisation test :
sfdx force:source:pushGénérez une URL pour l'organisation test et accédez-y dans une fenêtre de navigateur :
sfdx force:org:open
En général, l'étape suivante du cycle de vie d'un projet consiste à exécuter des tests unitaires et à valider les fonctionnalités que vous avez développées. Vous n'effectuerez pas ces opérations dans le cadre ce tutoriel, car vous travaillez avec un exemple de code pré-validé.
Transférer votre code vers un dépôt de code source
Sur votre machine locale, créez une branche nommée
feature-1:git checkout -b feature-1Transférez les modifications vers un dépôt de code source :
git add . git commit -m "Feature 1 changes" git push github feature-1Pour ce tutoriel, vous utilisez GitHub comme outil de code source.
Tester le déploiement
Cette section décrit les tests que vous pouvez exécuter pour vérifier que les déclencheurs que vous avez créés fonctionnent correctement. Le dépôt créé par votre administrateur Salesforce contient un exemple de classe de test.
Sur votre machine locale (pas dans Cloud Shell), créez une branche Git :
git checkout -b feature-1À l'aide d'un éditeur de texte, ouvrez le fichier suivant :
./force-app/main/default/classes/SampleTest.clsPour que le test échoue, dans l'instruction
System.assertEquals, remplacez la valeur101par102. Après avoir effectué la modification, enregistrez le fichier, mais gardez-le ouvert, car vous le modifierez par la suite dans cette procédure.@isTest public class SampleTest { static testmethod void testAddOne() { Test.startTest(); System.assertEquals(Sample.addOne(100), 102); // Change to 102 from 101 Test.stopTest(); } }Ajoutez et validez la modification dans la branche de fonctionnalité :
git add . git commit -m "Changed test case" git push github feature-1Créez une demande d'extraction pour fusionner votre code dans la branche de release d'exemple.
Une nouvelle tâche Cloud Build est déclenchée. Cependant, la tâche échoue car le test unitaire échoue.
Pour afficher l'état de la compilation, ouvrez la page Cloud Build.
Accédez à la section Historique de la page Cloud Build.
Le journal de compilation suivant pour la tâche indique que l'assertion de test a échoué.
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
Pour réussir le test, remplacez la valeur
102par101dans le fichier./force-app/main/default/classes/SampleTest.cls:@isTest public class SampleTest { static testmethod void testAddOne() { Test.startTest(); System.assertEquals(Sample.addOne(100), 101); //Change back to 101 from 102 Test.stopTest(); } }Ajoutez et validez la modification dans la branche de fonctionnalité :
git add . git commit -m "Changed test case to make it pass" git push github feature-1L'opération de commit déclenche une tâche Cloud Build.
Une fois la tâche terminée, examinez la demande d'extraction dans GitHub et fusionnez-la dans la branche
release-sample.Dans les workflows de production, l'autorisation de fusion des demandes d'extraction est généralement limitée aux administrateurs et aux responsables DevOps. Pour plus d'informations sur cette configuration, consultez la section sur la définition des capacités de fusion des demandes d'extraction sur le site GitHub.
Dans Google Cloud Console, examinez la tâche Cloud Build qui se déclenche automatiquement lorsque vous fusionnez la demande d'extraction dans la branche de release d'exemple.
Une fois la tâche terminée, connectez-vous à l'organisation Dev Hub. Vous pouvez vous connecter en tant que développeur ou en tant qu'administrateur.
Les modifications apportées au code du développeur sont disponibles dans cette organisation Salesforce. Pour les voir, accédez à la page Configuration et consultez la section Classes Apex/de code personnalisées.
Effectuer un nettoyage
Pour éviter que les ressources utilisées lors de ce tutoriel soient facturées sur votre compte Google Cloud, supprimez le projet contenant les ressources, ou conservez le projet et supprimez les ressources individuelles.
Supprimer le projet
- Dans la console Google Cloud, accédez à la page Gérer les ressources.
- Dans la liste des projets, sélectionnez le projet que vous souhaitez supprimer, puis cliquez sur Supprimer.
- Dans la boîte de dialogue, saisissez l'ID du projet, puis cliquez sur Arrêter pour supprimer le projet.
Supprimer les ressources Salesforce
Vous pouvez également supprimer l'organisation Salesforce Developer Edition et l'organisation test associée que vous avez créée pour ce tutoriel.
Désactiver l'organisation Developer Edition
- Accédez à l'organisation Salesforce Dev Hub.
- Dans la zone Quick Find (Recherche rapide) de configuration, saisissez
Company, puis sélectionnez Company Information (Informations sur l'entreprise). - Cliquez sur Company Information (Informations sur l'entreprise).
Cliquez sur le bouton Deactivate Org (Désactiver l'organisation).
Supprimer l'organisation test
Dans Cloud Shell, exécutez la commande suivante pour supprimer votre organisation test Salesforce :
sfdx force:org:delete -u feature-test-scratch-org
Supprimer le dépôt GitHub
Accédez à GitHub et supprimez le dépôt que vous avez créé dans votre compte personnel pour ce tutoriel.
Étapes suivantes
Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.