Suivez votre progression
Accueil Trailhead
Accueil Trailhead

Gérer les changements dans des versions de plus en plus complexes

Objectifs de formation

Une fois cette unité terminée, vous pourrez :
  • expliquer les avantages de l’utilisation du contrôle de version pour une version d’ensemble de modifications ;
  • décrire les similitudes entre l’ensemble de modifications et les modèles de développement organisationnel.

Cette unité explique pourquoi Calvin et ses collègues sont passés au développement avec du code et à un logiciel de gestion de versions. En parcourant cette unité, réfléchissez aux choix que vous feriez pour votre équipe. Avancez en traitant les modules énumérés à la fin de ce module pour découvrir le processus et prendre la décision la plus éclairée possible à propos de ce qui fonctionnera pour vous.

Devant la complexité croissante, passez au modèle de développement organisationnel

Zephyrus connaît un enchaînement de trimestres réussis. L’entreprise a étendu l’utilisation de Salesforce des ventes à d’autres secteurs de l’entreprise. Après avoir consulté Calvin et les responsables du service client, le directeur des opérations accepte de passer à la version Enterprise Edition et d’acheter Service Cloud Lightning. Grâce à Service Cloud Lightning, l’entreprise peut apporter une assistance instantanée et personnalisée à ses clients. Mieux encore, certaines personnes travaillant au service client ont les compétences de codage nécessaires pour développer des applications Salesforce répondant aux besoins de leur équipe.

Pour Calvin, il est clair que la complexité de l’organisation va au-delà de ce que l’équipe peut gérer avec le processus de développement des ensembles de modifications. L’entreprise doit désormais adopter un processus de gestion des modifications plus rigoureux et un processus d’audit (il s’agit ici d’un logiciel de gestion de versions) pour pouvoir gérer autant de flux de travail.

L’équipe se heurte également aux limites des actions possibles en utilisant des ensembles de modifications. Par exemple, elle peut ajouter des champs, mais pas les supprimer (modifications destructives).

Lors d’une présentation à son directeur et au PDG de Zephyrus, Calvin propose de passer au modèle de développement organisationnel.

Calvin proposant de passer au modèle de développement organisationnel.

Comme pour le processus d’ensembles de modifications, l’artefact de version créé est un ensemble de modifications de métadonnées lié à l’organisation de production. Mais dans le modèle de développement organisationnel, l’équipe peut obtenir une amélioration majeure de la gestion des modifications en externalisant les modifications apportées. Elle peut utiliser la Salesforce CLI pour extraire les métadonnées d’un environnement de développement et les intégrer dans un logiciel de gestion de versions (VCS).

Elle peut également utiliser la Salesforce CLI pour écrire le script des tâches de routine et améliorer la productivité de tous ceux qui participent à la version. La suggestion de Calvin de commencer par créer des scripts pour exécuter des déploiements de tests et des tests Apex convainc son directeur et son PDG.

Grâce aux arguments commerciaux de Calvin, son directeur et son PDG valident le passage au développement organisationnel. En reconnaissance de sa contribution au succès de l’entreprise, Calvin est promu analyste commercial. Cette promotion offre également à Calvin la marge de manœuvre nécessaire pour gérer les versions entre les services de l’entreprise.

Nouveaux avantages et thèmes familiers

Calvin et deux membres de l’équipe du service client travaillent sur des projets différents dans des environnements de développement distincts. Les trois projets sont tous prévus pour la même version. Au fil de leur progression dans le processus de développement organisationnel, ils remarquent à la fois des ressemblances et des différences avec le processus d’ensembles de modifications.

Comme dans le développement des ensembles de modifications, les trois membres de l’équipe suivent les modifications qu’ils apportent. Pourquoi ? L’équipe doit savoir quels composants changent, s’ils ajoutent ces composants à un ensemble de modifications ou s’ils les récupèrent avec la Salesforce CLI. De plus, certaines de leurs personnalisations ne peuvent pas être déployées vers une autre organisation, car elles incluent des composants modifiés qui ne sont pas représentés dans l’API de métadonnées. De telles modifications doivent être recréées manuellement dans l’organisation cible. Il est donc important de bien les suivre.

Lorsque les membres de l’équipe terminent leurs tâches de développement respectives, l’étape suivante consiste à transférer leurs modifications dans l’environnement de compilation en vue de leur intégration. Mais à présent, ils utilisent la Salesforce CLI pour récupérer les modifications depuis leurs environnements de développement respectifs, au lieu d’utiliser des outils déclaratifs pour créer un ensemble de modifications. Ils intègrent leur travail à un VCS pour que les modifications récupérées par les membres de l’équipe puissent être validées et suivies dans le VCS.

La validation et le suivi des modifications récupérées dans le VCS offrent un avantage essentiel à l’équipe. Lors de l’utilisation du processus d’ensembles de modifications, les membres de l’équipe peuvent écraser par inadvertance les modifications de quelqu’un d’autre (le cas s’est déjà présenté) en déployant un ensemble de modifications directement sur l’ensemble de modifications précédent. En utilisant le nouveau processus de validation des modifications dans le VCS, les conflits de personnalisation peuvent être identifiés avant d’écraser une modification.

Lors de l’étape de compilation, les personnalisations de l’équipe sont déjà intégrées au projet dans le contrôle source. Depuis le VCS, ces modifications sont déployées ensemble dans l’environnement de compilation pour intégration et tests. Comme lors du processus d’ensembles de modifications, les modifications sont testées ensemble dans l’environnement de compilation. Et comme auparavant, le résultat est un artefact de version unique, qui est dans les faits un grand ensemble consolidé de modifications. Mais Calvin utilise désormais la Salesforce CLI pour récupérer l’artefact dans l’environnement de compilation. Au fil du processus de développement organisationnel, l’artefact de version poursuit sa progression depuis le VCS jusqu’au prochain environnement.

Bien qu’ils utilisent des outils supplémentaires dans le processus de développement organisationnel, les étapes ALM de base, le concept d’ensemble de modifications, et les environnements de développement et de test sont les mêmes. Tous ceux qui travaillent sur la première version du nouveau modèle de développement disposent au minimum de quelques points de repère connus. De plus, Calvin est ravi d’utiliser Trailhead et les ressources du site Web Salesforce Developers pour développer ses compétences et connaissances techniques.

Le passage au modèle de développement organisationnel donne à Zephyrus la maîtrise et l’efficacité nécessaires pour étendre son utilisation de Salesforce à l’ensemble de la société.