Suivez votre progression
Accueil Trailhead
Accueil Trailhead

Découvrir les bases de la gestion des versions

Objectifs de formation

Une fois cette unité terminée, vous pourrez :

  • identifier les trois catégories de versions et les types de modifications relevant de chaque catégorie ;
  • décrire un ensemble de modifications ;
  • expliquer l’importance du suivi des modifications et des dépendances pour les versions d’ensembles de modifications.

Dans cette unité, Calvin et ses collègues commencent à appliquer le processus ALM. Au fil de votre lecture, réfléchissez aux choix que vous feriez pour votre équipe. Utilisez ensuite les modules énumérés à la fin de ce module pour vous familiariser avec le processus et décider de l’approche la mieux adaptée à votre cas.

Création d'un processus de gestion des versions

L’équipe de Zephyrus adapte ses pratiques de personnalisation aux étapes des meilleures pratiques ALM. Il faut un peu de temps pour s’y habituer, mais ses efforts sont récompensés. L’équipe constate une meilleure vitesse de développement et moins de perturbations des équipes de vente. L’équipe est convaincue et la direction est ravie.

En mettant en œuvre le cycle ALM, Zephyrus a adopté un processus de gestion des versions de base. L’équipe travaille cependant sur plusieurs projets de différentes tailles qui sont tous à différentes étapes du cycle ALM. Pour maîtriser les projets et les attente, Calvin ajoute une structure supplémentaire en établissant un calendrier de publication et en définissant des critères pour les différentes tailles de versions.

Il existe généralement trois catégories de versions.

Correctif
Corrections de bogues et modifications simples. Les modifications simples incluent les rapports, les tableaux de bord, les vues de liste et les modèles d’e-mail.
Mineure
Les modifications présentant un impact réduit, comme une nouvelle règle de workflow ou un déclencheur ayant une influence sur un processus commercial simple. Ces versions nécessitent généralement des tests, mais peu de formation limitée et de gestion des modifications. En règle générale, une équipe fournit les modifications pour une version mineure en quelques semaines.
Majeure
Les modifications ayant un impact significatif, notamment les modifications ayant une ou plusieurs dépendances. Étant donné que ces versions peuvent considérablement influencer l’expérience utilisateur et la qualité des données, elles doivent faire l’objet de tests approfondis, de formations et d’une gestion rigoureuse des modifications. Les versions majeures sont généralement fournies une fois par trimestre (Salesforce le fait trois fois par an).

Publiez selon un calendrier régulier. Essayez de publier à intervalles réguliers, toujours le même jour de la semaine. Par exemple, les versions mineures peuvent être produites à 20 heures, heure de l’Est, le premier mardi de chaque mois. La cohérence de la programmation permet une planification à l’échelle de l’entreprise et fixe les attentes de vos utilisateurs professionnels. Une dernière précision : essayez de ne pas publier vos versions à proximité des jours fériés ou d’autres événements importants.

Suivre un ensemble de modifications jusqu’à la production

Tout au long des étapes ALM, l’équipe de Zephyrus s’appuie sur le modèle de développement d’ensembles de modifications. Elle utilise l’interface de configuration pour créer des modifications dans un environnement de développement, puis elle migre ces modifications d’un environnement à l’autre au fil des étapes ALM.

Dans le développement des ensembles de modifications, l’artefact de version de l’équipe est un ensemble de modifications de métadonnées, comme une fusion ou un delta, en rapport avec ce qui se trouve dans l’organisation de production. Seules les métadonnées qui ont été ajoutées ou modifiées figurent dans la version ; en l’absence de modifications, elles ne figurent pas dans la version.

  • Chaque développeur suit toutes les modifications apportées à la personnalisation de la version. Le choix de l’outil de suivi est libre, d’un tableur à un système de suivi du travail.
  • Certains composants modifiés peuvent ne pas être disponibles immédiatement dans l’API de métadonnées et doivent être migrés manuellement entre les environnements. Si vous suivez ces modifications, vous n’oublierez pas de les migrer.
  • En tant que responsable de version, Calvin doit découvrir et inclure les composants dépendants dans la version. Par exemple, il est impossible de migrer un nouveau champ personnalisé vers l’environnement suivant si l’objet personnalisé auquel il appartient n’existe pas dans l’organisation cible. L’outil des ensembles de modifications permet à Calvin d’identifier ces dépendances.

Page Dépendances des composants, qui répertorie les dépendances par nom et par références.

Remarque

Remarque

La migration des profils et des ensembles d’autorisations peut être délicate. Examinez les considérations spéciales relatives au déploiement et à la récupération de profils et d’ensembles d’autorisations avant de poursuivre.

Le suivi des modifications dans chaque version nécessite du travail, mais si vous en gardez une trace, le déploiement se fera en douceur lorsque vous passerez en production.

Tous ensemble maintenant !

Votre version peut contenir plusieurs projets et chacun d’entre eux peut être développé et testé dans un environnement distinct. Mais avant la phase de compilation, vous migrez toutes les modifications de chaque projet vers le même environnement pour intégration. À partir de ce moment, les modifications et personnalisations de la version sont liées pour former un seul jeu de modifications intégré, destiné à la production. Lors de l’étape de validation qui suit la compilation, vous testez toutes les modifications ensemble.

En tant que responsable de version, Calvin suit les modifications de tous ses contributeurs. Il suit également les modifications apportées à l’étape de production qui ne sont pas encore présentes dans les environnements de développement et de test. Pourquoi ? C’est la seule manière de déployer les personnalisations sans écraser par inadvertance les modifications apportées à l’organisation de production.