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 :
- Configurer l’authentification en JWT sur vos environnements Salesforce https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_auth_jwt_flow.htm
- Créer des variables globales sur vos repository github pour chaque environnement, exemples :
- Pour la production : SF_USERNAME, SF_CONSUMER_KEY et SERVER_KEY_PASSWORD
- Pour l’UAT : SF_USERNAME_UAT, SF_CONSUMER_KEY_UAT et SERVER_KEY_PASSWORD_UAT
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.
