• Accueil / Salesforce / Un guide sur…
, Un guide sur Git (et le contrôle de version) pour les développeurs Salesforce<span class="wtr-time-wrap after-title"><span class="wtr-time-number">12</span> minutes de lecture</span>

Un guide sur Git (et le contrôle de version) pour les développeurs Salesforce12 minutes de lecture


Le contrôle de version est la clé pour débloquer les avantages d’un puissant processus DevOps pour Salesforce. Il ouvre la porte à l’automatisation, qui accélère les cycles de développement et de publication pour permettre aux équipes Salesforce de créer, tester et expédier le code et la configuration plus rapidement. Mais il existe des défis communs que les équipes doivent surmonter avant de pouvoir adopter avec succès des workflows automatisés et pilotés par la source.

Cet article explique comment surmonter deux principaux obstacles à l’adoption du contrôle de version, afin que votre équipe Salesforce puisse voir les avantages impressionnants de Salesforce DevOps (qui sont décrits dans Contrôle de version pour les administrateurs Salesforce).

, Un guide sur Git (et le contrôle de version) pour les développeurs Salesforce<span class="wtr-time-wrap after-title"><span class="wtr-time-number">12</span> minutes de lecture</span>

Les défis du contrôle de version

La flexibilité qui rend le contrôle de version si puissant est également source de complexité qui peut rendre son adoption difficile. Du plus grand jamais Enquête sur l’état de Salesforce DevOps, nous savons que les équipes sont confrontées à divers défis au départ lors de la mise en œuvre du contrôle de version. En substance, il y a deux défis initiaux :

  1. Trouver le bon processus. Les équipes ont souvent du mal à trouver la bonne stratégie de branchement Git.
  2. Embarquez votre équipe. Il existe un défi humain qui nécessite un processus de gestion du changement pour que l’équipe travaille efficacement.

Avant d’aborder chacun de ces obstacles, examinons un processus basé sur la source pour Salesforce.

Le modèle de branche de fonctionnalité

La stratégie la plus simple pour implémenter le contrôle de version en tant que source de vérité dans votre flux de travail consiste à utiliser le modèle de branche de fonctionnalité. Ce modèle Git relativement simple n’est qu’une des nombreuses stratégies de branchement que vous pouvez utiliser avec le contrôle de version. Mais il offre à votre équipe les avantages clés suivants par rapport aux stratégies de branchement plus complexes :

  • Délai d’exécution le plus court. C’est le temps entre la fin de votre travail et sa sortie en production.
  • Cycle de sortie le plus court. En libérant plus souvent des changements plus petits, vous pouvez resserrer la boucle de rétroaction.
  • Plus petit nombre de fusions. Choisissez la stratégie de branchement la plus simple possible.
, Un guide sur Git (et le contrôle de version) pour les développeurs Salesforce<span class="wtr-time-wrap after-title"><span class="wtr-time-number">12</span> minutes de lecture</span>

Dans le modèle ci-dessus, vous apportez vos modifications dans une branche de fonctionnalité qui correspond à un environnement de développement Salesforce tel qu’un bac à sable de développement. Après avoir validé votre travail, vous créez une pull request pour fusionner vos modifications dans le master – prête à être testée et mise en production.

C’est ici que vous ajoutez l’automatisation à votre processus. Pour que l’automatisation du déploiement régulier fonctionne de manière fiable, vous avez besoin de stabilité. Les organisations Salesforce sont des cibles mobiles, avec des modifications de configuration en direct, des mises à jour de plate-forme, des packages gérés et des paramètres de réglage par les utilisateurs finaux. Git, par comparaison, est de nature statique. En utilisant les branches Git, vous pouvez isoler les nouvelles fonctionnalités, afin de pouvoir contrôler, approuver et publier les modifications de la production de manière contrôlée. Ce processus basé sur la source s’éloigne fortement des pratiques de développement in-org natives de Salesforce.

En plus de la stabilité, l’autre chose dont vous avez besoin pour l’automatisation est un outil qui automatisera réellement vos processus ! Comme il n’y a pas d’automatisation de déploiement native dans Salesforce, Git vous offre un excellent cadre que d’autres outils, tels que Jenkins ou alors CercleCI, peut se connecter pour vous donner cette automatisation. À l’aide d’une solution DevOps conçue spécifiquement pour Salesforce, vous pouvez même la configurer de manière à ce que votre outil d’intégration continue commence à valider et à tester les nouvelles modifications par rapport à vos organisations en aval dès que vous validez une modification ou ouvrez une pull request – ainsi votre travail sera prêt à être publié en un rien de temps.

Malgré les avantages du modèle de branche de fonctionnalité simple, ce n’est pas toujours la bonne stratégie Git pour chaque équipe. En particulier, les grandes équipes avec une plus grande variété de rôles d’équipe et de multiples cas d’utilisation pour différents environnements peuvent bénéficier d’un modèle de branchement légèrement plus complexe.

Choisir la meilleure stratégie de branchement Git

Le choix d’une stratégie de branchement détermine la manière dont votre équipe travaillera avec Git. Une mauvaise stratégie peut vraiment entraver l’adoption du contrôle de version par votre équipe, il est donc important d’y réfléchir. Il y a cinq choses à considérer lors du choix d’une stratégie de branchement :

Complexité

Les stratégies de branchement varient en complexité. Plus votre stratégie de branchement est complexe, plus elle est susceptible de représenter fidèlement votre flux de travail actuel. Mais les modèles plus complexes prendront plus de temps pour que les membres de l’équipe les plus récents et moins techniques s’y mettent et auront souvent une charge de maintenance plus élevée. Au pire, ils peuvent même entraîner des versions plus lentes qu’auparavant, car les gens sont pris dans la complexité du processus. Donc, en général, moins de complexité est généralement mieux.

Taille de l’équipe

La taille de votre équipe peut déterminer la stratégie qui vous convient le mieux. Les grandes équipes, par exemple, sont plus susceptibles d’avoir une plus grande variété de rôles qui doivent interagir avec le flux de travail. Ils peuvent également avoir de nombreux environnements à gérer, avec des cas d’utilisation différents pour chacun, ce qui nécessite un peu plus de complexité dans la stratégie de branchement. Inversement, les petites équipes peuvent souvent bénéficier de l’approche la plus simple, de la mise en route rapide et de l’adaptation du modèle à l’avenir selon leurs besoins.

Cadence de sortie

Comme déjà mentionné, l’un des avantages les plus importants de l’utilisation du contrôle de version est que vous pouvez augmenter votre cadence de publication. Mais il peut y avoir des raisons commerciales qui dictent un cycle de publication particulier – par exemple, une approbation réglementaire ou des fenêtres de maintenance limitées. Si tel est le cas, vous devrez peut-être modifier votre stratégie de branchement pour répondre à ces exigences et passer à quelque chose de plus complexe pouvant accueillir les étapes d’approbation requises.

Flux de travail actuel

Le passage au contrôle de version est également l’occasion de remodeler votre workflow actuel. Obtenir l’adhésion de votre équipe est crucial. Mais la façon dont vos environnements sont actuellement configurés peut également avoir un impact sur votre choix de stratégie de branchement. Par exemple, vous pouvez avoir un ensemble complet d’environnements de test et de développement qui doivent être inclus dans votre nouveau flux de travail, ou un projet parallèle de longue durée qui doit être tenu à jour. Ou vous voudrez peut-être profiter de l’occasion pour changer les choses et essayer quelque chose de nouveau.

Ambition

Enfin, tout le monde n’a pas besoin ou ne veut pas viser le même objectif. Ce qui fonctionne bien pour une équipe de trois personnes peut ne pas fonctionner pour 300. Vous devez donc bien comprendre les défis que vous essayez de résoudre et à quoi ressemble une bonne solution pour vous lorsque vous choisissez votre stratégie.

Branchement pour plusieurs environnements de test et de transfert

Bien qu’il n’y ait pas de stratégie de branchement Git unique, à Engrenage, nous avons constaté qu’après avoir parlé à des milliers d’équipes Salesforce, ce qui suit est un modèle qui fonctionne bien pour beaucoup.

, Un guide sur Git (et le contrôle de version) pour les développeurs Salesforce<span class="wtr-time-wrap after-title"><span class="wtr-time-number">12</span> minutes de lecture</span>

Le modèle ci-dessus est largement similaire au modèle de branche de fonctionnalité, mais il est légèrement plus complexe car il comprend un certain nombre d’environnements de test et de mise en scène différents (dans ce cas, QA et Stage) avec chaque organisation ayant une branche de longue durée dans Git mappée à il. Maintenant, alors que nous avançons dans le processus de ce modèle, supposons que votre équipe travaille en sprints.

  1. Au début du sprint, vous créez une branche de version à partir de la branche master/main.
  2. Les branches de fonctionnalités sont créées par chaque membre de votre équipe lorsqu’ils commencent à travailler sur chaque user story.
  3. Vous créez ensuite vos modifications dans des bacs à sable de développement individuels (et/ou IDE) et les validez périodiquement dans la branche de fonctionnalité.
  4. Lorsque votre fonctionnalité est prête pour le contrôle qualité, vous ouvrez une demande d’extraction et fusionnez la branche de fonctionnalité dans la branche d’intégration du contrôle qualité.
  5. Après avoir fusionné toute modification apportée à l’intégration QA, votre branche est déployée dans le bac à sable QA, où elle peut être testée et approuvée par votre équipe QA.
  6. Une fois cette opération terminée, un PR est ouvert pour fusionner la branche de fonctionnalité dans la branche d’intégration Stage.
  7. Après avoir fusionné toute modification apportée à l’intégration de Stage, la branche est déployée dans le bac à sable Stage, où elle peut être testée et approuvée pour la mise en production finale. Selon votre flux de travail, vous pouvez également avoir UAT par les utilisateurs finaux pour faire bonne mesure.
  8. Une fois la modification approuvée dans Stage, la branche de fonctionnalité est fusionnée dans la branche de version. Ce processus se répète ensuite pour chaque modification apportée au cours du sprint, chaque fonctionnalité approuvée étant collectée dans la branche de publication.
  9. À la fin du sprint, toutes les modifications de la branche de publication sont déployées en production et mises en ligne pour vos utilisateurs finaux.
  10. Une fois que vous avez vérifié le nouveau travail en production, vous fusionnez la branche de publication dans master, de sorte que master soit à nouveau à jour avec la production.
  11. Vous voudrez alors également fusionner le master dans les branches d’intégration, afin que vos branches restent synchronisées si des modifications indésirables n’ont pas suivi ce processus principal.

Le sprint se termine alors et un nouveau cycle commence.

Embarquer les équipes

Passons maintenant au deuxième obstacle principal à l’adoption du contrôle de version. Pour que tout changement soit efficace, la nouvelle approche doit avoir des avantages démontrables, sinon les membres de votre équipe retourneront à leur façon de travailler habituelle. Pour cette raison, l’adoption du contrôle de version peut souvent être un défi pour les personnes pour les raisons suivantes.

Les membres de l’équipe sont habitués à leur flux de travail actuel

Pour les équipes qui ont travaillé uniquement avec Salesforce, Git peut être un grand changement. C’est un tout nouvel outil avec sa propre terminologie et son propre processus. Cela vous oblige également à vous rapprocher du XML sous-jacent qui définit vos organisations, bien plus que de nombreuses personnes de votre équipe ne l’ont peut-être fait auparavant. En conséquence, les membres de l’équipe qui ne sont pas familiers avec Git pourraient avoir du mal avec la courbe d’apprentissage au début. Mais maîtriser le contrôle de version ne signifie pas que les administrateurs de votre équipe doivent se familiariser avec une interface de ligne de commande, et vous n’avez pas besoin de passer du temps à apprendre des commandes Git délicates.

Manque de familiarité avec Git et perception d’une barrière à l’entrée

La plupart des fournisseurs Git proposent des outils basés sur l’interface utilisateur pour effectuer les actions les plus courantes, et vous pouvez déployer des organisations Salesforce vers le contrôle de version et vice versa sans la CLI, grâce à des outils tels que Engrenage. Réduire cette barrière à l’entrée est un élément clé pour obtenir l’adhésion de l’équipe.

Des stratégies de branchement trop complexes peuvent décourager les gens

Passer à un tout nouveau flux de travail en une seule fois peut s’avérer difficile. Par conséquent, lancer un projet pilote ou créer un centre d’excellence pour défendre le nouveau processus peut être un excellent moyen de relever ce défi.

Il est également important de garder les choses aussi simples que possible. Il peut être tentant de commencer par reproduire votre workflow de version actuel dans Git ou d’essayer de penser à chaque cas limite. Mais si vous ne faites pas attention, cela peut conduire à un processus incroyablement complexe avec lequel les gens ont du mal à se familiariser.

Quel que soit le flux de travail que vous choisissez, il est important de vous assurer que votre équipe commence à voir les avantages dès le départ. De cette façon, votre équipe peut renforcer la confiance que l’amélioration vaut la perturbation initiale.

Vous voulez plus de conseils sur la mise en œuvre du contrôle de version ?

Pour en savoir plus sur les principes fondamentaux du contrôle de version et d’autres stratégies de branchement recommandées pour les équipes Salesforce, rendez-vous sur Barre de lancement DevOps – une plateforme de formation gratuite avec des cours amusants pour vous aider à maîtriser Salesforce DevOps et obtenir des certifications. L’expertise DevOps est très recherchée, car de plus en plus d’équipes Salesforce adoptent des processus rationalisés, il est donc temps d’acquérir ces précieuses certifications.

Pour en savoir plus comment les administrateurs et les développeurs peuvent partager des flux de travail basés sur la source, consultez Contrôle de version pour les administrateurs Salesforce.



Source de l’article traduit automatiquement en Français

Besoin d'aide ?
Vous utilisez Pardot depuis un certain temps mais vous n'êtes pas sûr d'en
exploiter tout le potentiel

Notre analyse de votre Pardot offerte dès aujourd'hui
Merci, vous pouvez compléter notre questionnaire
Nous allons revenir vers vous rapidement !

Fermer