Gestion du cycle de vie d’une application

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 rationalisée. Elle permet de limiter au maximum l’introduction de régressions. L’ALM définit également un cadre itératif, rendant au final la création d’application plus rapide et plus sûre. Elle s’applique bien évidemment aussi dans Salesforce.

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

Plan Release, Develop, Test

• Plan Release : Le contenu de la version à livrer est planifié (spécifications, priorités, …). Les projets Salesforce s’appuient généralement sur une méthode Agile. 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. Celui-ci contient les métadonnées de la production mais sans les données de cette dernière. 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. Ils vont ainsi pouvoir valider que la fonctionnalité réalisée fonctionne conformément aux besoins.

Build Release, Test Release, Release

• 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. Il convient parfaitement aux petites et moyennes structures disposant de peu de ressources :

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. Celle-ci 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.

Inbound et Outbound change sets

Tous les échanges entre environnement s’effectuent au travers de change set (Inbound & Outbound Change Sets). On les paramétre dans le menu Setup | Deployment Settings depuis chaque environnement cible. Le but est 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.

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.
Il est possible de déployer des changements à la main, surtout si ceux-ci sont limités. Toutefois, 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 ou cycle de vie d’une application. 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.
Pour déterminer votre modèle ALM, n’hésitez pas à consulter le parcours Trailhead :
Determine Which Application Lifecycle Management Model Is Right for You.