Salesforce Release Train : une approche pratique de la gestion des versions
Publié: 2022-03-11La gestion des versions, comme son nom l'indique, est le processus de gestion, de planification, de planification et de contrôle d'une construction logicielle à travers différentes étapes et environnements ; y compris les tests et le déploiement des versions logicielles (Humble & Farley, 2011).
C'est un sujet assez important en soi et ne peut être perfectionné qu'au fil du temps en essayant différentes itérations avec les équipes de développement et en faisant correspondre les besoins de l'entreprise ou les versions de fonctionnalités. Nous essaierons de couvrir les pratiques de l'industrie en matière de gestion des métadonnées, de construction de CI et de gestion de sandbox pour gérer le train de versions d'une organisation.
Mais qu'est-ce qu'un train de libération?
Un train de versions est une technique de livraison de fonctionnalités incrémentielle et prévisible. Cela nécessite que le développeur mette en place un processus formel pour prendre en compte toutes les modifications apportées à l'environnement de développement et les déployer en production.
Un train de lancement peut être divisé en trois segments :
- Gestion des métadonnées
- Construction d'intégration continue
- Gestion du bac à sable
Gestion des métadonnées
Les métadonnées sont des données qui fournissent des informations sur d'autres données. Salesforce fournit un modèle de métadonnées riche et puissant via son API de métadonnées . Les métadonnées de votre application décrivent et englobent un ensemble de méthodes qui fournissent un accès par programme au code source et à la configuration de votre organisation.
L'API de métadonnées est le meilleur moyen de gérer les personnalisations dans Salesforce. Il prend en charge les méthodes create , read , update et delete . Vous pouvez utiliser les ensembles de modifications, l'IDE Force.com et l'outil de migration Ant pour migrer les métadonnées d'une organisation à une autre, car ils fournissent tous des migrations via l'API.
Chaque outil a ses propres avantages, et il y a plusieurs choses à considérer lors du choix d'un :
Tableau 1 : Comparaison des outils pour la migration des métadonnées
| Ensembles de modifications | EDI Force.com | Outil de migration des fourmis |
|---|---|---|
| Les ensembles de modifications permettent de déployer des composants via l'interface utilisateur standard de Salesforce. | Force.com IDE (Eclipse) est principalement destiné au développement Apex, mais peut être utilisé à des fins de déploiement. | Ant Migration est un puissant outil de ligne de commande, dédié à la migration des modifications/métadonnées entre les environnements. |
| Habituellement utilisé pour un petit nombre de migration de composants. | Les développeurs utilisent généralement l'IDE pour migrer les modifications vers l'environnement de test ou de staging. | Ant Migration est utilisé pour la migration de charges utiles volumineuses et nécessite une connaissance approfondie de l'API Salesforce Metadata. |
| La connexion entre les organisations doit être établie manuellement, elle n'est donc pas adaptée aux déploiements automatisés. | Il peut être utilisé pour se déployer dans n'importe quelle organisation, mais nécessite certaines étapes manuelles, qui sont sujettes aux erreurs. | Les déploiements automatiques peuvent être programmés très facilement. |
| Destiné à être utilisé par les administrateurs. | Destiné aux développeurs de force de vente, puisque le développement du code est son utilisation principale. | Destiné aux ingénieurs DevOps. |
| L'ajout de dépendances est très simple et convivial. | L'ajout de dépendances est assez facile, car il fournit une interface utilisateur pointer-cliquer. | Le déploiement échoue généralement en raison de dépendances manquantes. |
| N'autorise pas les modifications destructives. | Permet des ensembles de modifications destructrices, mais le processus est assez fastidieux. | Autorise les ensembles de modifications destructives. |
L'API de métadonnées est idéale pour remplir son objectif lors du développement et de la migration des modifications sur la plate-forme Force.com. Mais il y a un petit hic : toutes les métadonnées de Salesforce ne sont pas prises en charge par l'API de métadonnées. La documentation officielle fournit une liste des composants non pris en charge.
Si votre organisation apporte des modifications qui ne sont pas prises en charge par l'API de métadonnées, vous devez vous assurer de répliquer ces modifications manuellement dans l'organisation de destination. La meilleure façon de suivre ces changements est une feuille de calcul. Si vous devez recourir à cette approche, il est toujours conseillé qu'une seule personne effectue ces changements et en fasse le suivi.
Ce serait une bonne liste générale de colonnes que l'on pourrait utiliser pour suivre ces changements dans une feuille de calcul :
- Nom du composant
- Type de composant
- Changer de propriétaire
- Description de la fonctionnalité
- Cartographie des capacités
- Dépendance avec d'autres composants
- Évalué/nom de l'évaluateur
- URL
- Nom/ID de l'organisation
- Autres commentaires
Contrôle de version et intégration continue
La migration des modifications vers la production doit être un processus fluide, car il ne s'agit que d'une répétition de l'application des modifications dans l'environnement de test et de préproduction. Pourtant, il y a toujours une chance que les choses tournent mal, et vous avez alors besoin d'un plan de repli. Il est très important de conserver une sauvegarde des métadonnées de votre organisation, et c'est à cela que servent le contrôle de version et la construction CI .
Le contrôle de version est un must absolu pour toute organisation. Il permet aux développeurs de travailler de manière collaborative, efficace et sécurisée. La gestion du développement et de la migration de code multi-développeurs et multi-sandbox est un défi dans Salesforce. Salesforce a également son propre calendrier pour les versions et la maintenance. Ces mises à jour offrent de nouvelles fonctionnalités, mais elles pourraient introduire un changement dans l'API de métadonnées qui pourrait casser votre build CI. Ainsi, en dehors des situations où les développeurs écrasent les modifications des autres, le contrôle de version vous aide à élaborer une stratégie de restauration. Avoir une stratégie de restauration est indispensable lorsque votre application s'exécute sur Force.com.
L'organigramme suivant décrit une structure pratique pour le contrôle de version et CI. Nous allons essayer de vous donner une description rapide de ce que représente le diagramme.
- Un développeur enregistrerait sa modification dans le système de contrôle de version.
- Le serveur CI/Jenkins déploierait la dernière version dans le bac à sable CI et exécuterait des classes de test.
- Si le déploiement à l'étape 2 réussit, les modifications sont fusionnées dans la branche QA.
- CI déploierait ensuite le dernier commit de la branche QA vers le bac à sable QA.
- Si QA rejette les modifications en raison d'échecs de test, les étapes 1 à 3 doivent être répétées jusqu'à ce que QA efface les modifications.
- Une fois que les modifications ont passé les tests dans QA, les modifications sont fusionnées dans la branche Master.
- Les dernières modifications de la branche Master sont déployées dans le bac à sable Master.
On peut choisir d'ajouter plus de succursales en fonction des besoins de l'organisation. Mais la structure ci-dessus fonctionne très bien pour les structures de développement de niveau moyen à entreprise.
Gestion du bac à sable
Pour tirer le meilleur parti du processus DevOps de votre organisation, il est très important de configurer la structure du bac à sable. Avant de nous plonger plus profondément dans le sujet, discutons des différents types de bacs à sable que Salesforce nous propose.
Un bac à sable est une copie presque exacte de vos métadonnées de production. Les bacs à sable sont généralement utilisés à des fins de développement, de test, de préproduction et de formation. Il existe quatre types de bacs à sable, et il faut en tenir compte lors du choix d'un bac à sable. Les bacs à sable Full Copy pourraient coûter très cher !
Vous trouverez ci-dessous le tableau des limites appliquées par Salesforce pour différents bacs à sable.
Tableau 2 : Comparaison des limites
| Développeur | Développeur Pro | Copie partielle | Copie complète | |
|---|---|---|---|---|
| Données de production | Non | Non | Oui | Oui |
| Stockage de données | 200 Mo | 1 Go | 5 Go (10 000 enregistrements par objet) | Données complètes |
| Période d'actualisation | Un jour | Un jour | 5 jours | 29 jours |
Nous pouvons voir que le prix n'est pas la seule différence entre les bacs à sable.
Le bac à sable du développeur a une période d'actualisation d'un jour, ce qui le rend adapté au développement, mais ne peut accueillir que 200 Mo de données et aucune donnée de production. À l'opposé, les bacs à sable à copie complète ont une copie exacte des données de production ; même les ID d'enregistrement sont les mêmes. Cela pourrait le rendre idéal pour les tests et la mise en scène, mais la période d'actualisation de 29 jours rend difficile l'obtention des dernières métadonnées et données de production dans le sandbox de copie complète.
Le tableau ci-dessous sert de règle empirique pour la sélection des bacs à sable :
Tableau 3 : Cas d'utilisation pour la sélection de sandbox
| Développeur | Développeur Pro | Copie partielle | Copie complète | |
|---|---|---|---|---|
| Développement | Oui | Oui | Non | Non |
| AQ | Oui | Oui | Oui | Non |
| Test d'intégration | Non | Non | Oui | Oui |
| Test de données par lots | Non | Non | Oui | Oui |
| Formation | Non | Non | Oui | Oui |
| UAT | Non | Non | Oui | Oui |
| Test de chargement | Non | Non | Non | Oui |
| Mise en scène | Non | Non | Non | Oui |
| Formation des utilisateurs | Non | Non | Non | Oui |
Vous trouverez ci-dessous la structure organisationnelle typique adoptée pour les projets de taille moyenne. Pour les clients au niveau de l'entreprise, la structure organisationnelle devient plus complexe mais suit globalement le modèle ci-dessous.
Le développement de Salesforce est généralement effectué dans le bac à sable du développeur (rouge) et les modifications sont déplacées vers le bac à sable d'intégration (vert) qui est généralement un développeur pro ou un bac à sable de copie partielle. Ensuite, les modifications provenant de plusieurs bacs à sable d'intégration sont déplacées vers le bac à sable cumulatif (jaune) qui doit être un bac à sable de copie partielle.
Si votre organisation a des intégrations avec le système tiers nécessitant des tests d'intégration et des tests de charge, vous devez disposer d'un ensemble stable de données qui ne changent pas d'une version à l'autre. Il est donc préférable d'avoir une copie complète ou une copie partielle du bac à sable.
Ces modifications sont ensuite déplacées vers le bac à sable de test d'intégration, où les tests sont effectués. Ensuite, les modifications sont déplacées vers le bac à sable intermédiaire, qui doit être un bac à sable de copie complète. Toutes les classes de test sont exécutées avant le déploiement. Une validation de déploiement doit être effectuée pour s'assurer que le déploiement se déroule sans aucun problème.
Ce processus nous aide à nous assurer que les modifications passent par plusieurs séries de tests et paires d'yeux. Il présente l'inconvénient de nécessiter beaucoup de temps pour développer, tester et déployer les modifications.
Très souvent, il y a un besoin urgent d'effectuer des corrections de bogues ou des correctifs. Pour les gérer rapidement, il convient de conserver un sandbox développeur, qui pousserait de petits correctifs directement vers le sandbox rollup.
Comme mentionné précédemment, un bac à sable est une réplique presque exacte des métadonnées de production, mais pas complètement. Il existe une liste officielle des composants/fonctionnalités qui sont désactivés dans un bac à sable.
Une autre chose à considérer lors de l'actualisation d'un bac à sable est qu'il ne copie que les métadonnées et les données de production. Il n'y a aucun moyen de copier les métadonnées d'un bac à sable à un autre, ou même de créer un bac à sable vide sans aucune configuration de métadonnées (comme les organisations de développeurs gratuites). Cela devient parfois un défi dans des situations réelles. Salesforce prévoit de résoudre ce problème, et cette fonctionnalité pourrait bientôt devenir disponible pour tous.
De plus, si vous avez des données sensibles en production, auxquelles vous pensez que votre équipe de développement ou de test ne devrait pas avoir accès, vous pouvez créer des modèles de bac à sable pour les bacs à sable entièrement et partiellement copiés.
Éléments à prendre en compte lors du déploiement
Nous avons couvert les pratiques du secteur en matière de gestion du cycle de vie des applications dans l'écosystème Salesforce. La gestion des métadonnées et du bac à sable joue un rôle très important dans la création des packages de déploiement et des charges utiles. Pour les applications Salesforce volumineuses et complexes, le contrôle de version permet de s'assurer que les modifications de métadonnées sont suivies tout en aidant à la création d'une stratégie de restauration.
La gestion du bac à sable est essentielle pour les projets volumineux ou complexes. Mais les Sandbox sont coûteuses dans l'écosystème Salesforce, à la fois en termes de ressources financières et de temps. La formulation d'une stratégie de gestion du bac à sable est toujours essentielle pour le processus de gestion des versions.
Nous vous laissons quelques points supplémentaires qu'il serait bon de garder à l'esprit lors de votre prochain déploiement :
- Seuls 10 000 fichiers, soit un fichier ZIP de 39 Mo, peuvent être déployés en une seule fois. Naturellement, si la charge utile est trop importante, vous devez diviser le package en plusieurs parties, puis effectuer le déploiement.
- Si le déploiement échoue en raison d'une erreur de
request timeout, essayez de supprimer des objets, des champs personnalisés et des profils du package. Ces composants prennent plus de temps à se déployer. - Si un type de champ est modifié ou s'il y a eu des changements dans la hiérarchie des rôles, il peut y avoir de longs retards dus au recalcul des données, nécessitant un certain temps.
- Salesforce verrouille tout composant actuellement utilisé par un utilisateur dans le système. Si nous essayons de déployer alors que c'est le cas, le déploiement échouera.
J'espère que cet aperçu vous aidera lors de votre prochaine version de Salesforce.