Salesforce B2C Commerce & devOps

Atlassian… Salesforce… Microsoft… Trois éditeurs, trois géants et des offres produits fondamentalement différentes. Différentes oui, mais chez Madagence nous avons souhaité pousser la démarche de rapprochement technologique entre ces trois monstres au bout du bout.

Déployer un projet e-Commerce sous Salesforce Commerce Cloud B2C nécessite de l’organisation, de la rigueur mais aussi (surtout) de la scalabilité, de la visibilité et de l’agilité.

Préambule

Dans cet article, nous allons vous présenter une manière de faire pour intégrer la suite Atlassian (Jira & BitBucket principalement) et Office 365 (Teams principalement) sur un projet Salesforce Commerce Cloud B2C. Nous allons ici parler d’intégration continue, d’automatisation projet et de versioning.

Nos objectifs de conception de l’intégration entre Atlassian, Microsoft & Salesforce chez Madagence ont été les suivants :

• Faciliter le quotidien de nos collaborateurs (Développeurs, Leaders Technique et Chefs de Projet)
• Augmenter la lisibilité technique des projets (Versionning, Déploiement, etc.) pour l’ensemble des acteurs non-techniques des projets
• Arrêter de perdre du temps sur les actions à faible valeur ajoutée

Dans cet article nous parlerons de « manière de faire ». Effectivement toute méthode est potentiellement non applicable à un contexte donné ; elle est aussi très certainement critiquable. Pour finir, cette manière de faire est surement perfectible. C’est pour cela que nous rédigeons cet article ; pour avancer avec la communauté ;).

Madagence

Madagence est une agence de développement experte e-commerce. Nous sommes aujourd’hui partenaire & intégrateur de la solution Salesforce Commerce Cloud B2C. Notre expertise technologique est aujourd’hui assurée par une équipe de Makers (Collaborateurs) spécialisés & certifiés sur cette plateforme (Architectes, Leaders technique, etc.) .

Nous croyons au marché et aux innovations que Salesforce Commerce Cloud B2C propose au travers de ce Cloud dédié à la chaîne de valeur e-Commerce de nos clients.

L’ensemble des projets déployés chez Madagence sont construits avec le Framework Agile Scrum. Nous ne déployons pas le Framework Scrum de manière hybride ou partiel ; nous l’intégrons dans son état d’art le plus complet. Plus qu’une simple méthode de gestion de projet, l’agilité est un véritable mindset de l’entreprise et de nos collaborateurs.

Revue des objectifs

Objectif 1 : Faciliter le quotidien de nos collaborateurs (Développeurs, Leaders technique et Chefs de Projet)

Objectif 2 : Augmenter la lisibilité technique des projets (Versionning, Déploiement, etc.) pour l’ensemble des acteurs non-techniques des projets

Objectif 3 : Arrêter de perdre du temps sur les actions à faible valeur ajoutée

Objectif 1 : Faciliter le quotidien

Qu’est-ce qu’un Développeur n’aime pas faire ? Qu’est-ce qu’un Leader Technique n’aime pas faire ? Qu’est-ce Chef de Projet n’aime pas faire ? Trois questions bêtes, trois questions qui lorsqu’on y apporte des réponses, puis des solutions, permettent de gagner du temps.

Qu’est-ce que le Développeur n’aime pas faire :

• Mettre à jour ses tickets.
• Saisir ses temps

Qu’est-ce que le Leader Technique n’aime pas faire :

• [..] IDEM Développeur [..]
• Passer plus de temps à déployer qu’à coder
• Passer des heures à mettre à jour les jeux de données entre les environnements (IMPEX)

Qu’est-ce que le Chef de Projet n’aime pas faire :

• Premier point, le plus important, il n’aime pas faire ce que les autres auraient dû faire 😉
• Devenir archéologue pour savoir quel ticket est déployé (ou pas)
• Suivre son reste à faire de manière manuelle
• Ne pas savoir quand il peut démarrer sa recette

Objectif 2 : Augmenter la lisibilité

Faire vivre un projet e-Commerce et l’ensemble de ses composantes n’est pas chose aisée. Effectivement les couches nécessaires à la mise en oeuvre d’un projet de ce type sont nombreuses.

La roadmap du client, le backlog fonctionnel, le découpage technique, le suivi des temps, le management des priorités, la gestion des sources, l’administration des environnements; toutes ses couches invitent à la multiplicité des outils.

Il n’est pas rare aujourd’hui de trouver la roadmap d’un client sur un fichier Excel, le backlog fonctionnel dans un Word, le découpage technique dans un outil de gestion de projet (Redmine, Mentis, Jira, etc.) et pour finir un système de versioning couplé à un moteur d’intégration continue qui vivent en autarcie.

La multiplicité des outils et le manque d’intégration de ces derniers apportent un manque de lisibilité sur les projets. La manière de faire présentée dans cet article devra répondre à ce problème.

Objectif 3 : Arrêter de perdre du temps

Même si la restructuration de certains grands groupes apportent un vent nouveau sur les organisation des entreprises. Même si l’agilité commence à se déployer dans les esprits. La France reste un pays où l’on aime les choses complexes ; où l’on aime les organisations complexes ; où l’on construit les processus bien faits et répondant à l’ensemble des cas.

Chez Madagence nous croyons en la proximité, la flexibilité & la simplicité. Ce sont les axes à suivre partout ; aussi bien sur l’organisation des entreprises, que le management des projets et que la structuration des outils.

Revenons en à nos projets Salesforce Commerce Cloud B2C ; voilà les éléments sur lesquels nous considérons perdre du temps, sans réel valeur ajoutée. Ceci n’est bien-sur par propre à Salesforce B2C Commerce.

• Saisir, voir ressaisir, manuellement nos temps
• Savoir quand les déploiements ont lieu
• Savoir où les tickets sont déployés
• Mettre à jour les statuts des tickets
• Construire manuellement des reportings
  • Burn-Down, Sprint Load, etc.
  • Avancement des releases
  • Calcul de la vélocité
• Déployer manuellement les tickets
• Déployer manuellement les releases
• Déployer manuellement les données (IMPEX)
• Estimer les tâches de manière rapide & efficace
• Identification instantanée de DownTime
• Identification instantanée de demandes en priorité 1

La manière de faire devra permettre à limiter la déperdition de temps sur les éléments ci-dessus.

Architecture globale

Afin de comprendre de manière globale l’architecture des échanges entre les différents éditeurs. Voici le schéma des interactions entre ces derniers.

Attention cela semble être un projet de 70 jours. Ne vous inquiétez pas ! Nous l’avons mis en oeuvre en 20 jours ouvrés grâce aux intégrations déjà existantes entre les différents outils.

La clé de la réussite ; avoir les bons outils : Teams, Jira, BitBucket, SFCC-CI. Avec l’utilisation de ces 4 outils ; peu de problèmes risquent de venir se mettre au milieu de votre chemin.

Le déploiement d’une architecture de ce type est simple à mettre en oeuvre lorsque l’on a pas ou peu d’historique. Migrer plusieurs dizaines de projets sous cette architecture se verra être une autre paire de manches.

Keys features

Nous n’allons pas évoquer dans cet article la manière de mettre en oeuvre une architecture de ce type (c’est notre petit secret ;)).  Nous allons parler du plus important et donc des fonctionnalités qu’offre cette manière de faire.

Smart Commit

Lors de la création d’une branche associée à un ticket ou lors du premier commit. Plusieurs actions se lance dans Jira.

• Le passage du ticket de « To Do » à « In Progress »
• L’affichage des informations de « Commit » s’affiche sur le ticket

Sur l’ensemble des commits, nous obligeons une normalisation des commentaires sous le format suivant : ISSUE_KEY #time [Some amount in Jira time syntax] <Your worklog comment text>.

Cela permet d’ajouter une fonctionnalité de Time Tracking directement dans les tickets JIRA.

La fonctionnalité de Suivi Temporel dans JIRA permet de piloter la notion de « Reste à faire ». Ainsi d’un simple coup d’œil il est facile d’observer les tâches prenant plus/moins de temps que prévu. Cette fonctionnalité permet aussi de gérer facilement l’atterrissage planning du fait que le « Reste à faire » est dissocié de l’estimation initiale.

Cela nous permet d’extraire automatiquement une gestion des atterrissages de nos releases.  Exemple sur une release de test qui sera très certainement impossible à produire 😉

Pull Request in JIRA

Durant l’ensemble de son développement, le développeur n’a pas à aller dans JIRA pour mettre à jour l’avancement de son ticket. L’intégration BitBucket / Jira s’occupe d’indexer l’évolution du ticket sur base de l’avancement technique.

Lors de la création de la Pull Request :

• Changement de statut du ticket : « In Progress » vers « Developed »
• Assignation de la tâche automatique à la personne en charge de la PR

Lors du refus de la Pull Request :

• Changement de statut du ticket : « Developed » vers « To Do »
• Assignation à la personne ayant créé la Pull Request
• Notification Teams à la personne ayant créé la Pull Request

Lors de l’acceptation de la Pull Request :

• Changement de statut du ticket : « Developed » vers « Reviewed »
• Déploiement automatique vers l’environnement de « Demo »
• Une notification Teams est envoyé au Chef de Projet Madagence pour qu’il puisse démarrer la recette

L’ensemble des informations sur les Pull Request associées à un ticket sont visibles directement dans JIRA.

Release Done in JIRA

Dans JIRA la gestion des sprints au travers des versions offre une vue très claire de l’avancement projet & technique des tickets présents dans le release.

Lors que l’ensemble des tickets d’une version sont dans le statut « Tested », autrement dit que l’ensemble des tickets ont été recettés par nos Chefs de Projet Madagence ; un déploiement packagée de l’ensemble de la Release (Code Source + différentiel DATA) est effectif sur l’environnement « Development ».

Nous avons pour cela mis en oeuvre un Bitbucket Pipeline utilisant SFCC-CI. Nous passons dans un premier temps par le staging sans activer les versions, ni importer la donnée. Puis nous déploiement sur « Development » en activant la version de code & en important les données déposées.

SFCC-CI et les Builds

Nous avons tordu deux solutions de Build mises à disposition pour la plateforme Salesforce Commerce Cloud B2C. La fameuse et ancienne « Build Suite » et la petite nouvelle « SFCC-CI ».

Sans l’ombre d’une hésitation ; nous recommandons « SFCC-CI ». La prise en main est plus simple, la compréhension de la suite plus aisée, des gains de performance sur les builds constatés allant jusqu’à 70% de rapidité supplémentaire et pour finir une mise en oeuvre 3 à 4 fois plus rapide.

Via la solution BitBucket Pipelines nous avons donc implémenté la suite « SFCC-CI ». La lecture de l’interface de BitBucket Pipelines est claire, simple, efficace. Les fonctions essentielles sont présentes, pas de bling-bling ça répond à 100% des besoins.

La gestion des successions de build entre les différents environnements est normée et les déploiements entre demo, development, staging/prod sont interdépendants.

Chez Madagence nous avons arrêté le « Continious Delivery » à l’environnement de « Development » du fait que nos clients ne sont pas prêt à travailler de cette manière sur les environnement de Production (Staging & Production). Mais en quelques clics la solution serait en place.

Une fois de plus on retrouve dans JIRA, les informations sur les Builds.

Une fois de plus dans Jira on automatise :

• Lors du déploiement de la release en « Development » > Changement du statut de la version JIRA. Le client peut maintenant démarrer sa recette.

Environments management

Obtenir une représentation graphique de ce que contient ou non un environnement à un moment donné est un gain de lisibilité significatif.

Une fois de plus JIRA nous offre cette possibilité. Directement sur le ticket il est possible de savoir où se trouve (techniquement) une demande.

Il est aussi possible de récupérer l’historique des déploiements.

Il est même possible de visualiser le cycle de vie inter-environnements d’un ticket au travers de la vue ci-dessous présente dans BitBucket.

Pour avoir une vue à l’environnement & non plus au ticket. Une autre interface est existante au sein de BitBucket.

DATA Deployment

La gestion des données entre les environnements est toujours un casse-tête. Nous avons tous vécu des événements comme ceux-ci  :

• Mise à jour d’une base de données sur un environnement de dev, non répliqué en demo.
• Mise à jour d’un contenu de test en demo, non présent en développement.

Nous avons mis en place via SFCC-CI, un upload des modifications apportées sur les données vers les environnements cibles. Cet upload se base sur des données provenant de l’environnement sources & attachés au commit associé. Le différentiel des modifications effectuées par le développeur sur les données est construit automatiquement ! Il est juste nécessaire de lancer une ligne de commande en début & fin de développement et le différentiel de données s’accroche automatiquement au code source.

Le gain de temps & la gestion des effets de bords est significative sur ce point. Même si difficilement quantifiable nous estimons entre 5% et 10% le gain de temps sur une équipe projet en phase de BUILD. 

Prority « Highest »

Nous possédons 5 niveaux de priorité chez Madagence ; sur lesquelles tournent nos SLAs. Via le Project Automation de Jira ; nous avons créé des cheminements simples qui permettent de remonter efficacement des alertes sur les demandes prioritaires.

Par exemple, nous notifions dans Teams les demandes de priorité 1 ou « Highest ».

Automation ROI

Nous planifions les sprints avec nos clients sur base d’un seul & unique indicateur. Le R.O.I. Cet indicateur permet en quelques secondes de savoir les tâches qui possèdent le rapport effort/effet le plus élevé.

Cet indicateur est calculé automatiquement selon une recette savante & sécrète de Madagence. Cette recette nous l’avons implémenté dans Jira via un Script Listener (Script Runner). Ce script s’exécute à chaque mise à jour des tâches pour recalculer le ROI en live.

Push up / down on Issue

Nous avons conçu dans JIRA plusieurs script permettant de gérer la dépendance entre les tâches parentes & les tâches enfants.

Ainsi lorsque nous estimons la complexité des tâches durant le planning poker, les estimations remontent automatiquement dans les Stories puis dans les Epics.

De la même manière un script de gestion des statuts entre les tâches est présent. Lorsqu’une mise à jour d’un ticket à lieu :

• Si le ticket est une Story ; alors l’ensemble des sous tickets s’indexent automatiquement sur le statut de la Story
• Si le ticket est une Tâches ; alors la Story contenant la Tâches s’indexe sur le plus petit statut de ses sous tâches

Des choses bêtes qui chaque jour permettent de gagner quelques minutes ; chaque semaine quelques heures et à la fin d’une année plusieurs dizaine de jours.

Conclusion

Nous n’allons pas faire une conclusion à rallonge. Nous avons listé ci-dessous les objectifs que nous nous étions fixés et quelles sont les fonctionnalités qui adressent cet objectif.

Une chose est sûre. Chez Madagence nous voyons l’intégration continue & le Project Automation comme un juste équilibre qui a pour unique et seul objectif : une augmentation de la productivité & de la qualité de nos prestations.

Les possibilités sont infinies lors que les bons outils sont en places ; il faut donc toujours garder en tête que l’intégration continue & le Project Automation sont au service du projet et non l’inverse. Pour être au service du projet, ces outils doivent être simples à la compréhension, à la maintenance.

Notre conclusion : La simplicité est la clé de l’adhésion, l’adhésion la clé du succès.