Introduction
Dans tout projet informatique, nous sommes amenés à travailler en amont avec plusieurs collaborateurs, souvent il s’agit d’ajouter ou de modifier des fonctionnalités en parallèle sur des sujets communs.
En effet, que nous ayons un profil technique ou fonctionnel, nous livrons nos développements sur les mêmes environnements et parfois nous les réalisons également au même endroit, sur des sandbox ou des scratch orgs. Ce contexte nous oblige à réfléchir avant de développer et avant de déployer nos composants. Nous rencontrons au moins une fois dans notre vie de développeur ou de consultant Salesforce un problème lié à la livraison de nos développements. Ainsi notre travail soigneusement effectué se voit perdre en qualité à la dernière étape. Dans ce cas, pourquoi ces bugs et ces problèmes ne sont pas identifiés plus tôt dans le cycle de vie de notre fonctionnalité ?
Il est donc important que l’équipe de développement s’assure du bon déroulement des déploiements dans les différents environnements. De même elle doit garantir la fiabilité ainsi que la sécurité des éléments ajoutés ou modifiés.
Avant de commencer, de quoi parlons-nous ?
L’intégration continue (CI) est une pratique de développement logiciel pour automatiser les suites de test. Toutes les modifications du code ou de la plateforme sont intégrées à chaque commit de tous les développeurs. Elles sont ensuite compilées automatiquement pour vérifier chaque ajout et détecter les éventuels problèmes.
Chaque changement qui réussit les tests automatisés est automatiquement déployé sur l’environnement de production de manière rapide et en toute sécurité.
En somme si les défauts sont détectés tôt, ils seront moins chers à corriger. Il est évident que lorsqu’un défaut est détecté immédiatement, après que le développeur l’a codé, il faut beaucoup moins de temps pour le réparer. Ce qui n’est pas le cas quand il faut le trouver et le corriger un mois plus tard.
Le temps de mise sur le marché est un des avantages principaux d’un tel process. Le logiciel est toujours testé ! Ainsi, il est toujours prêt à passer à d’autres environnements.
Comment ça fonctionne ?
Qui dit intégration continue dit également outil CI. Ces outils nous facilitent la vie et nous permettent de mettre en place notre système. Nous utilisons principalement un outil de CI et un système de contrôle de version (VCS).
Il existe une multitude d’outils d’intégration sur le marché, à l’image de Jenkins qui est le plus populaire et en open source. Il y a aussi Bamboo créé par Atlassian, ainsi que CircleCi basé, quant à lui, sur le cloud et multiplateforme.
Du côté des VCS, les plus utilisés sont git, Mercurial, SVN et CVS. Plusieurs plateformes collaboratives nous permettent d’héberger nos projets, collaborer avec d’autres développeurs, vérifier notre code, créer une documentation, etc.
Salesforce nous offre un excellent outil (SFDX) pour évoluer vers un modèle centré sur la source avec le VCS qui devient notre source de vérité pour nos projets. Grâce à cet outil nous avons accès à la puissance de git et nous pouvons manipuler nos organisations Salesforce plus aisément.
L’intégration continue est donc réalisée par un outil CI qui communique avec le système de contrôle de version. Une fois l’outil de CI choisi, nous devons le configurer afin de définir le moment où notre suite de tests ainsi que nos déploiements s’exécutent.
Dès que ces règles sont mises en place et à chaque fois que nous effectuons une modification sur notre projet archivé sur le VCS, l’outil CI exécute un script en arrière-plan qui configure notre environnement, déploie les modifications et exécute la suite de tests.
Mon quotidien avec l’intégration continue ?
Pour bien comprendre l’utilité d’un système d’intégration de livraison continue, nous allons imaginer une équipe de développement, constituée à la fois de développeurs mais aussi d’administrateurs Salesforce.
Parmi le choix des différents outils CI nous choisissons CircleCI. Comme de nombreux outils CI, CircleCI est configuré via un config.yml. Ce dernier est déjà configuré pour se connecter à nos différents environnements et applications.
Cependant afin de l’utiliser nous devons d’abord nous connecter à notre compte CircleCI. Celui-ci contient déjà notre projet archivé sur notre plateforme de collaboration Github.
Soulevons, éventuellement, plusieurs questions. Voici certains exemples ci-dessous.
1. J’ai oublié de formater mon code, CircleCI va-t-il corriger mon code avant le déployer ?
Le CI vous avertit lorsque des problèmes sont détectés. Par contre il ne peut pas les réparer pour vous. Le CI ne sera pas en mesure de résoudre vos problèmes d’architecture ou d’écrire des tests unitaires plus significatifs.
Néanmoins il vous dira quand un test est interrompu ou bien lorsque vous avez fait quelque chose de stupide.
2. Mon CI peut-il détecter les régressions au moment des livraisons ?
Le CI ne détecte pas les éventuelles régressions dues à l’écrasement de développements plus anciens. Si les metadatas sont correctes et les tests sont concluants, alors tous les composants existant sur l’org sont écrasés.
3. A quel moment ma fonctionnalité est testée ?
Une fois que mon développement est effectué en local (ou sur mon organisation développement) puis récupéré grâce à SFDX, je dois envoyer grâce aux commandes Git ma modification sur la branche correspondante à mon développement.
Cette étape effectuée, CircleCI va automatiquement détecter ce changement dans le projet. Il valide alors ces changements en lançant un déploiement de validation et ensuite exécute les tests sur mon environnement de test ou en créant une scratch org temporaire.
À la fin, il nous informe du succès ou de l’échec de la validation avec un message qui retrace l’ensemble des erreurs détectées.
4. Comment livrer mes modifications sur mon environnement de production ?
Mes changements sont validés et testés grâce à l’étape précédente : je peux déployer sur mon environnement de pré-production ou de test métier en fusionnant ma branche de développement avec la branche de pré-production (ou UAT).
Les tests métier sont effectués et validés : je peux fusionner cette branche sur la branche Master. CircleCI lance alors un déploiement avec les tests en production.
5. Combien de temps faut-il pour qu’une seule ligne de code passe de Développement à la Production ?
Précédemment nous avons vu que le déploiement en production passe par plusieurs étapes de manière continue et automatique. En utilisant SFDX, à chaque étape, l’ensemble des métadonnées présentes dans le projet est compilé, déployé et l’ensemble des tests exécuté.
La durée du déploiement dépend donc du nombre de fonctionnalités à déployer, nombre de commit, de corrections affectées sur la branche et la taille du projet.
6. Combien de temps consacré à l’intégration dois-je ajouter en plus à mon développement ?
Comme nous l’avons expliqué, l’intégration nécessite plus de temps. Mais cela en vaut vraiment la peine. Il est certain que vous gagnerez beaucoup de temps in fine.
Terminées les longues recherches et les corrections chronophages quelques semaines ou mois après les développements !
Pour conclure : quels sont les vrais plus de l’intégration continue ?
- L’intégration continue est comme un mur de qualité que le code doit franchir systématiquement avant d’être déployé en production.
- Cette pratique garantit un code de qualité, des utilisateurs finaux satisfaits et des développeurs plus efficaces.
- De nombreux logiciels, parfois gratuits, permettent sa mise en place.
- C’est un vrai gain de temps sur le long terme !
Pour en savoir plus sur l’intégration continue, retrouvez l’article de Fabien Huot “Salesforce : mes premiers pas avec Copado”
