Logo de l’article 9 Salesforce

La Gestion du cycle de vie d’une application, connue sous ALM (Application Lifecycle Management), fournit des processus et des règles permettant de développer des applications de manière fluide et rationnalisée. Elle permet de limiter au maximum l’introduction de régressions et définir un cadre itératif, rendant au final la création d’application plus rapide et plus sûre.

Gestion du cycle de vie d’une application

Plusieurs représentations existent mais nous pouvons modéliser le cycle ALM ainsi :

ALM Processus
Processus ALM
  • Plan Release : Le contenu de la version à livrer est planifié (spécifications, priorités, …) généralement en s’appuyant sur une méthode Agile pour les projets Salesforce. Les différents environnements (Développement, Intégration, UAT, Production, …) nécessaires à l’équipe de développement, la maitrise d’ouvrage et divers acteurs du projet sont également mis en place.
  • Develop : les développeurs disposent chacun de leur propre environnement de développement qui contient les métadonnées de la production mais sans les données de celle-ci. Ils vont utiliser une combinaison d’outils déclaratifs (Process Builder, Flow Builder, …) et de programmation (Apex, Visualforce, Composants Lightning) pour répondre aux besoins des utilisateurs.
  • Test : une fois l’étape précédente terminée, les développeurs vont conduire des tests unitaires afin de valider que la fonctionnalité réalisée fonctionne conformément aux besoins.
  • Build Release : chaque développeur va déployer ses développements dans un environnement d’intégration rassemblant le travail des différents membres de l’équipe. Cela va permettre d’identifier des éventuels conflits et de constituer la version en un seul ensemble.
  • Test Release : afin de valider ces développements, des utilisateurs chevronnés vont conduire des tests fonctionnels. L’idée est de mener des tests de bout en bout qui représenteront des cas d’utilisation réelle de l’application. Cet environnement d’UAT (User Acceptance Tests) contient à minima un jeu de données partiel des données de production.
  • Release : si les différents tests fonctionnels s’avèrent concluants, la version est déployée en production ainsi que dans les environnements de formation. Cela permettra aux utilisateurs de se former aux nouvelles fonctionnalités avec des données réelles.

Développement d’ensemble de modifications (Change Set Development)

Il s’agit du modèle de développement de base qui convient parfaitement aux petites et moyennes structures disposant de peu de ressources :

Change Set Model
Change Set Development Model

Le nombre d’environnements dépend du nombre de développeurs. A minima, il faut 2 environnements : la production et un autre qui fait office d’environnement de développement et de tests.

Les développeurs disposent chacun d’une Dev Sandbox qui contient toutes les métadonnées de la production mais sans aucune de ses données. Ils y effectuent leurs développements (ainsi que leurs tests unitaires) avant de les déployer en environnement d’intégration. Cet environnement mutualise tous les développements dans une Dev Pro Sandbox. Si celle-ci ne contient pas non plus de données de production, on y injecte généralement des données de tests.

La phase de tests fonctionnels (UAT) se déroule ensuite de préférence dans une Full Sandbox. Cet environnement peut également faire office d’environnement de formation car similaire aux données de la production sans toucher à celles-ci.

Tous les échanges entre environnement s’effectuent au travers de change set (Inbound & Outbound Change Sets). Ceux-ci sont paramétrés dans le menu Setup | Deployment Settings depuis chaque environnement cible afin de définir quels environnements peuvent communiquer entre eux et dans quel sens. Attention, seuls les environnements d’une même organisation peuvent communiquer au travers de change set.

Deploy Settings
Deployment Settings

Ce fonctionnement nécessite de tracer l’ensemble des changements dans une liste de modification afin de pouvoir les propager d’un environnement à l’autre.
S’il est possible de déployer des changements à la main, surtout si ceux-ci sont limités, on ne peut pas déployer du code en production sans passer par un change set ou d’autres outils de déploiement (Ant, SFDX, …).

Nous évoquerons dans des articles dédiés comment utiliser Ant ou SFDX et sa ligne de commande (CLI) pour déployer des métadonnées.

Au cours de cet article, nous avons décrit les différentes étapes constituant le processus d’ALM. Nous avons également étudié le premier des 3 modèles de développement les plus communs pour créer des applications Salesforce :
Change Set Development
– Org Development
– Package Development

Les deux derniers modèles seront étudiés dans le cadre d’un second article à venir.