Salesforce : Mes premiers pas avec Copado

Fabien Huot
Texeï
Published in
8 min readJan 25, 2021

--

Dans le cadre d’une mission dans laquelle j’occupe un poste de release-manager Salesforce, une refonte de nos outils d’intégration continue et de déploiement continu a eu lieu. C’est pourquoi je me suis lancé dans l’écriture d’un article de blog, afin de partager ma vision du CI/CD sur Salesforce et sur l’outil qui m’aide dans l’initialisation de toute cette chaîne de production à savoir, Copado.

Que veut dire “Intégration continue” et “déploiement continu” (CI/CD) ?

Aujourd’hui, dans les projets informatiques, les entreprises et les équipes projets mettent l’accent sur les nouvelles méthodes de travail et les nouveaux outils DevOps. Les méthodes Agiles (comme la méthode Scrum) sont privilégiées et les outils de CI/CD sont des “must have”.

Intégration Continue (CI) :

Avec les nouvelles méthodes de travail telles que les méthodes dites “Agile”, les équipes de développement sont confrontées à livrer de manière régulière les nouvelles fonctionnalités prévues dans le “Sprint”.

On parle d’intégration continue le fait de permettre aux développeurs de fusionner leurs développements aussi souvent que possible sur une branche commune (branche GIT). Le but étant de réunir le code de tous les développeurs afin qu’il soit testé. Ces tests sont pour la plupart du temps automatisés, afin de permettre aux équipes de développement de réagir rapidement en cas de problème.

Livraison/Déploiement Continu (CD) :

Le déploiement continu est la suite “logique” de l’intégration continue. En effet, une fois que le code a été testé et validé par tous les automatismes pendant l’intégration continue, nous rentrons dans le cycle du déploiement continu.

Ce cycle consiste à automatiser les livraisons des modifications jusqu’à la production afin de “soulager” les équipes d’exploitation. Sans outils de déploiement continu, ces tâches sont souvent manuelles et ralentissent la distribution des applications.

Par ailleurs, l’idée même d’automatiser les tâches de déploiement peut réduire les erreurs humaines 😛

Ok pour la définition…et Salesforce dans l’histoire ?

Depuis la sortie de SFDX par Salesforce, les manières de développer ont changé. La volonté de l’éditeur (et pour rejoindre les bonnes pratiques de développement) est que nous utilisions SFDX avec un outil de versionning afin de gérer les sources. In fine, le but étant de récupérer les métadonnées de vos développements et de les sauvegarder dans un outil de versionning.

Les sandbox ainsi que la production, anciennes références et sources de vérités, ne le sont plus et passent le flambeau à Git.

Voici un schéma qui résume la vision des intéractions de Git (ici GitLab) avec l’ensemble des environnements de Salesforce d’un projet simple.

Les étapes de déploiements sont :

  • Le développeur apporte des modifications et les ajoute dans sa branche GIT (ici feature/MyProject-00XX)
  • Cette branche “feature/MyProject-00XX” est fusionnée avec une branche supérieure (ici branch_UAT).
  • Les métadonnées qui se trouvent sur la branche “branch UAT” sont déployées sur la sandbox UAT.
  • etc…

Ce cycle de “3 étapes” se répète jusqu’à la mise en production.

Ces étapes et ces processus sont réalisables via SFDX et des outils tels que GitHub et GitLab, qui proposent tous deux des outils d’automatisation. Ces automatisations vous permettront de pousser les métadonnées fraîchement modifiées directement sur une sandbox ! Et tous cela, sans lever le petit doigt !

Copado késako ?

Parmi ces différents outils cités précédemment (GitHub et GitLab), un autre concurrent dans l’environnement Salesforce vient se joindre à la bataille. Celui-ci se nomme “Copado”.

Copado est un ISV (Independent Software Vendor) qui propose une solution DevOps native Salesforce. Cet ISV regroupe un ensemble de fonctionnalités permettant de déployer des développements d’environnement à environnement et d’automatiser cette chaîne de production.

Copado est payant. Il y a des coûts de licences (pour les administrateurs, et pour les développeurs). À noter que chaque développeur doit avoir sa licence, ainsi que toutes les personnes qui vont interagir durant le processus de déploiement. Contrairement à GitHub et GitLab qui proposent des solutions gratuites mais limitées (en payant un forfait, vous n’aurez plus de limites).

Je vais vous présenter une liste non-exhaustive des fonctionnalités de Copado. Je dis “non-exhaustive”, car je travaille avec Copado depuis quelques mois, et je n’ai pas encore fais le tour 😄. Néanmoins, je vais essayer de vous regrouper les fonctionnalités principales et les possibilités qu’offre Copado.

Les principales fonctionnalités de Copado

1. Gestion des User Stories

Toutes les informations se retrouve dans un record User Story. Les informations de JIRA sont remontées ainsi que les métadonnées liées à votre User Story.

Les principes Agiles continuent d’inspirer les équipes projet sur la manière de concevoir un produit fini. Copado s’appuie sur la méthode Scrum, et sur des User Stories pour mener à bien les incréments sur le produit. Avec Copado, vous pouvez synchroniser vos User Stories depuis Azure DevOps et JIRA.

Par soucis de simplicité, dans la suite de l’article, les User Stories seront appelées des “US”.

2. Git Snapshots

On peut voir ça comme la possibilité de faire des sauvegardes de métadonnées (backup) sur votre outil de versionning (GIT). Ces actions peuvent être lancées manuellement ou de manière automatisée. (tous les soirs à 22h00 par exemple…)

3. Grouper les changements par User Story

Comme Copado travaille avec des User Stories, il est possible de retrouver l’ensemble des modifications apportées dans l’US en question !

En quelques clics, vous avez l’aperçu de ce qui a été modifié et de ce qui va être livré. Par qui, où, et quand.

Exemple : Ma User Story me demandait de créer un champ sur l’objet compte, alors je vais lier cette métadonnée à mon US.

Voyez ça comme une interface de “changeset”, mais qui passe par GIT.

4. Hiérarchiser les User Stories

Il se peut que, dans un contexte précis, vous ayez besoin de lier plusieurs US entre elles, et de définir une hierarchie.

Si une US doit être livrée avant une autre vous pouvez définir une relation parent-enfant entre deux US. L’US “Parent” sera toujours livrée avant l’US “Enfant”.

5. Intégration continue & Pipeline

Vous pouvez voir les environnements Salesforce qui constituent votre pipeline. De plus, vous avez un aperçu des US qui sont à livrer dans les environnements supérieurs, et celles qui sont à descendre dans les environnements inférieurs de votre pipeline.

Les US qui montent dans le pipeline sont appelées des “Promotions” tandis que les US qui descendent dans les environnements inférieurs (pour remettre toutes les sandbox à jour), sont appelées des “Back-Promotions”.

Avec Copado, vous avez une vue d’ensemble de votre “Pipeline” (chaîne de production).

6. Gestion des conflits de merge

Une fois que vos User Stories sont prêtes, elles peuvent être déployées sur les environnements supérieurs.

Dans ce cas, Copado prend les modifications que vous avez apportées sur votre “branche”, pour les comparer avec la branche de l’environnement de destination.

Il se peut donc qu’il y ait des conflits lors du merge de métadonnées dans “GIT”. Afin d’éviter de naviguer entre vos différents outils, Copado vous propose de faire la résolution de conflits directement dans celui-ci. Nul besoin d’aller dans GIT 😃

Comparer les différences GIT au travers de l’interface Copado

7. Définir des “Quality Gates”

Vous voulez mettre en place un lancement automatique de toutes vos classes de tests lorsque vous déployez d’un environnement à l’autre ? Ou faire une analyse du code qui va être déployée et ce, de manière automatique ? C’est là que les Quality Gates de Copado rentrent en jeu !

A chaque connexion entre deux environnements, il vous est possible de définir des automatismes. Utiliser PMD pour faire de la revue de code, ou alors définir un lancement de vos classes de tests… ou pas.

Définir des “quality gates” vous permet à la fois de contrôler ce qui va être déployé et ce, de manière automatique !

On peut voir ici que deux “Quality Gates” sont définies lors du passage de l’environnement Dev4 à UAT

8. Les “Destructive Packages”

Vous avez besoin de supprimer de la métadonnée ? Des classes Apex sont obselètes et vous souhaitez les supprimer de votre environnement ? Pas de problème, Copado gère aussi les “destructive packages” !

Les plus et les moins

Ce qui me plaît 😃 :

  • Un outils assez complet en terme de CI/CD
  • Copado automatise nativement toutes les actions sur Git. Normalement, vous n’avez rien à toucher sur votre outil de versionning. Les creations, suppressions de branches, les merges… tout est automatisé !
  • Natif Salesforce qui comprend les problématiques de déploiement Salesforce
  • Un application “User Friendly”
  • Un support réactif (si vous avez acheté l’option…).
  • Une documentation en ligne très complète.
  • Des mises à jour de Copado suivent les mises à jour de Salesforce (système de release Spring, Winter etc…)
  • Bonne intégration avec Vlocity

Ce qui me plaît moins 😞 :

  • De bonnes connaissances GIT et de déploiement sur Salesforce sont nécessaires à la compréhension de Copado. Des profils administrateurs, “App Builder” peuvent être très vite perdus au début. Si vous n’avez toujours fait que des changes sets… Alors, il va vous falloir un peu de temps 😃.
  • Beaucoup de clics ! Même si l’interface est efficace, le fait que Copado s’appuie sur des objets Salesforce, il faut naviguer entre les objets, cliquer sur des listes associées etc… Bref, beaucoup de clics ! Une raison de plus pour tout automatiser !
  • Beaucoup de “tricks”. En effet, il se peut que vous soyez “bloqué” lors d’un déploiement ou autres… et les seuls moyens pour vous débloquer sont de passer outre les mécaniques de standards de Copado, et de contourner le système.
  • Intégrer une solution telle que Copado en cours de projet n’est pas facile.

Comment débuter avec Copado ?

Si vous avez envie d’en savoir plus, et d’en apprendre plus sur Copado. Un module Trailhead est disponible via ce lien : https://trailhead.salesforce.com/fr/content/learn/modules/salesforce-devops-with-copado

Dans ce module, vous trouverez les principales fonctionnalités de Copado, ainsi que la vision DevOps par Copado.

Par ailleurs, vous pouvez aussi trouver des informations sur le site de l’éditeur : https://www.copado.com/

Conclusion

Après mes quelques mois d’utilisation, je peux dire que Copado est un outil assez complet en termes d’intégration continue et de déploiement continu. Les principales fonctionnalités pour faire du CI/CD sont présentes.

L’intégration Copado — JIRA (ou Azure DevOps) est un réel avantage pour faire de Copado l’outil central de votre usine logicielle.

De part le fait que Copado est un “unmanaged package”, il est possible d’améliorer la solution et de rajouter des fonctionnalités qui correspondent à votre besoin.

Une nouvelle version Winter’21 est sortie et permet l’utilisation du format “source” sfdx.

Cette solution reste néanmoins assez longue à maitriser et des profils “non-techniques” peuvent très vite se heurter à des problèmes. Des profils plus techniques seront privilégiés pour comprendre et mettre en place Copado.

Sources:

Trailhead.com / Redhat.com/ Copado.com /Google.com

--

--