Salesforce CI/CD : Comment déployer uniquement le delta avec les Github actions ?

Par 

6 minutes de lecture

Dans les différents projets Salesforce sur lesquels j’ai pu travailler en tant que développeur et avec Salesforce CI/CD, le constat fut très souvent le même : le temps consacré au déploiement dans les différents environnements est très (trop) conséquent. Or, l’enjeu majeur de nos projets aujourd’hui, est l’optimisation du gain de temps et la rapidité de déploiement des metadatas.

Par ailleurs, je me suis aperçu qu’à chaque déploiement, il est très fréquent d’embarquer l’ensemble des metadatas du dépôt git, ce qui implique une durée de déploiement très importante et d’éventuels problèmes de déploiement.

Dans cet article, nous découvrirons une méthode pour déployer rapidement en se concentrant uniquement sur les metadatas modifiées grâce au plug-in SFDX Git Delta.

Salesforce CI/CD : Stratégie de branchement 

Voici un exemple de git flow.  :

Dans ce cas, nous avons pour chaque environnement Salesforce, une branche correspondante et pour chaque User Story, une feature branche correspondante.

Quand nous voudrons déployer notre user story sur les environnements supérieurs, nous allons merger notre user story sur chaque branche de l’environnement de destination, au lieu de merger la branche de l’environnement source avec l’environnement de destination.

Ainsi, si vous souhaitez déployer un ensemble de user stories, vous pourrez utiliser une branche de promotion :

  • Créer une branche de promotion à partir de la branche de l’environnement de destination en la nommant promotion/destinationbranch-XXXX
  • Merger toutes les features branches que vous souhaitez déployer sur la branche de promotion.
  • Créer un pull request pour pousser la branche de promotion vers la branche de l’environnement de destination.

Implémentation de github 

Avant de commencer, il y a certaines étapes qu’il faudra configurer sur vos environnements et sur votre dépôt github :

Pour l’implémentation, nous aurons besoin de :

  • Github actions
  • SFDX
  • Plugin SFDX Git Delta (SGD)

Enfin, voici le YAML que nous allons utiliser pour valider notre package lors du pull request vers la branche de l’environnement de destination, qui est ici la master (PROD) :

name: PROD-Validation

# Controls when the action will run.
on:
  # Triggers the workflow on push or pull request events but only for the master branch
  pull_request:
    branches: [ master ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
      with:
          ref: ${{ github.event.pull_request.head.sha }}
          # Fetch all history commit
          fetch-depth: 0
    - uses: actions/setup-node@v1
      with:
        node-version: '14.6.0'

    - name: Install SFDX & SFDX Git Delta
      run: |
        npm install sfdx-cli
        echo y | node_modules/sfdx-cli/bin/run plugins:install sfdx-git-delta
    - name: Generate package.xml
      run: |
        #Generate package.xml between the current branch & 
        node_modules/sfdx-cli/bin/run sgd:source:delta --to "HEAD" --from $(git merge-base HEAD origin/master) --output . -i .gitignore
        echo "--- package.xml generated with added and modified metadata ---"
        cat package/package.xml
    - name: Authentication to PROD
      run: |
        echo "${SERVER_KEY_PASSWORD}" > server.key
        node_modules/sfdx-cli/bin/run auth:jwt:grant --clientid ${{ secrets.SF_CONSUMER_KEY }} --jwtkeyfile server.key --username ${{ secrets.SF_USERNAME }} --setdefaultdevhubusername --setalias prod
      env:
        SERVER_KEY_PASSWORD: ${{ secrets.SERVER_KEY_PASSWORD }}

    - name: Validation in PROD
      run: |
        node_modules/sfdx-cli/bin/run force:source:deploy -x package/package.xml -l RunLocalTests -u prod -c

 

YAML pour déployer notre package après avoir mergé notre pull request avec la branche de l’environnement de destination master (PROD) :

name: PROD-Deployment

# Controls when the action will run. 
on:
  # Triggers the workflow on push or pull request events but only for the master branch
  push:
    branches: [ master ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
      with:
        ref: master
        # Fetch all history commit
        fetch-depth: 0
    - uses: actions/setup-node@v1
      with:
        node-version: '14.6.0'

    - name: Install SFDX & SFDX Git Delta
      run: |
        npm install sfdx-cli
        echo y | node_modules/sfdx-cli/bin/run plugins:install sfdx-git-delta

    - name: Generate package.xml
      run: |
        #Generate package.xml between the current branch & 
        node_modules/sfdx-cli/bin/run sgd:source:delta --to "HEAD" --from "HEAD^" --output .
        echo "--- package.xml generated with added and modified metadata ---"
        cat package/package.xml

    - name: Authentication to Production
      run: |
        echo "${SERVER_KEY_PASSWORD}" > server.key
        node_modules/sfdx-cli/bin/run auth:jwt:grant --clientid ${{ secrets.SF_CONSUMER_KEY }} --jwtkeyfile server.key --username ${{ secrets.SF_USERNAME }} --setdefaultdevhubusername --setalias prod
      env:
        SERVER_KEY_PASSWORD: ${{ secrets.SERVER_KEY_PASSWORD }}

    - name: Deployement to PROD
      run: |
        node_modules/sfdx-cli/bin/run force:source:deploy -x package/package.xml -l RunLocalTests -u prod

Nous pouvons voir qu’au niveau de la ligne suivante :

node_modules/sfdx-cli/bin/run sgd:source:delta --to "HEAD" --from "HEAD^" --output .

 

Nous générons notre package.xml avec le delta des metadatas en comparant le HEAD et le HEAD-1 . Ce package.xml est ensuite utilisé par SFDX pour déployer seulement les metadatas qui ont été modifiées.

Démo

D’autre part, j’ai un projet existant avec des metadatas.

Dans un premier temps, j’ai créé une feature branche feature/JIRA-00001 à partir de la branche master. Puis, j’ai fait des modifications sur mon champ Account.Customer_ID__c sur mon environnement et j’ai commité la modification sur ma branche feature.

Dans un second temps, je crée un pull request pour pousser ma branche feature sur la branche master.

Nous pouvons voir l’exécution de notre YAML de validation sur github actions et voir les logs avec la génération de notre package.xml

Tous les checks sont OK, nous pouvons maintenant confirmer le merge de notre pull request.

Ainsi, en mergeant le pull request, nous verrons le lancement de l’action PROD-Deployment qu’on a configuré sur un autre YAML et qui cette fois va lancer le déploiement sur l’environnement.

Pour en savoir plus : 

Repo SFDX Git Delta : https://github.com/scolladon/sfdx-git-delta

Documentation Github Actions : https://docs.github.com/en/actions

La version anglaise de cet article est dispo ici : Day 13 : CI/CD Salesforce deploys only delta with github actions.

A lire également sur le blog

Comment utiliser le pré-header ?

Comment utiliser le pré-header ? Dans le paysage en constante évolution du marketing numérique, la création d’emails captivants est devenue un véritable art. Chaque élément joue un rôle crucial …
mars 2024
Conseils
Avantages de Salesforce pour les PME

Pourquoi faire de la conduite du changement ? 

D’abord, qu’est-ce que la conduite du changement ? La conduite du changement (aussi appelée change management ou change) sert à accompagner les différentes parties prenantes lors d’une transformation dans …
mars 2024
Conseils

Portrait de Texiens : Zoé Cadiou, Responsable Marketing Opérationnel

👋 Découvrez le portrait de Zoé Cadiou, Responsable Marketing Opérationnel chez Texeï ! 🚀 Arrivée chez Texeï en tant que Responsable de Communication, Zoé endosse désormais la casquette de Responsable …
février 2024
Interviews

Portrait de Texiens : Virgile Paré, Senior Business Analyst

👋 Découvrez le portrait de Virgile Paré, Senior Business Analyst, Spécialiste CRM-Analytics, et Manager chez Texeï ! 🚀 Arrivé il y a deux ans maintenant, Virgile a apporté son …
février 2024
Interviews
Salesforce aide les entreprises à améliorer leur service client

Organiser ses contenus et données dans Marketing Cloud

Comment organiser ses contenus et données dans Marketing Cloud ? Bien organiser ses contenus et données est crucial pour assurer des flux de travail fluides. Un aspect fondamental pour …
février 2024
Conseils

Comment bien configurer Omni-Channel dans Salesforce Lightning ?

Bienvenue dans cet article dédié à la configuration optimale d’Omni-Channel dans Salesforce Lightning. Si vous n’êtes pas encore familier avec Omni-Channel, je vous invite à consulter mon précédent article …
janvier 2024
Conseils