Playbook DevOps Salesforce pour les equipes mid-market en croissance

Le probleme DevOps du mid-market

Votre org Salesforce est trop complexe pour les change sets, mais vous n'avez ni le budget ni l'effectif pour de l'outillage DevOps de niveau entreprise. Vous avez 3 a 20 developpeurs Salesforce, plusieurs sandboxes, et des cycles de release de plus en plus difficiles a gerer a mesure que l'equipe grandit.

C'est le probleme DevOps du mid-market. C'est la que la plupart des equipes Salesforce en croissance restent bloquees.

Ce playbook couvre ce qui fonctionne vraiment pour des equipes de cette taille - base sur des schemas observes dans des dizaines d'implementations Salesforce mid-market.

La bonne strategie d'org pour la taille de votre equipe

3 a 8 developpeurs

A cette taille, la simplicite est votre alliee. Vous n'avez pas besoin de 6 environnements.

• Sandbox de dev - chaque developpeur travaille dans la sienne, OU un sandbox de dev partage si les limites d'org sont serrees
• Sandbox QA - pour tester avant la production
• Production

Flux de deploiement : Dev → QA → Production, automatise par pipeline.

8 a 20 developpeurs

A cette taille, vous avez besoin d'isolation des fonctionnalites pour eviter que les developpeurs ne se bloquent entre eux.

• Sandboxes de fonctionnalites (1 par epic actif ou binome de developpeurs)
• Sandbox d'integration - fusionne depuis tous les sandboxes de fonctionnalites
• Sandbox UAT - pour la validation metier
• Production

Le sandbox d'integration est l'ajout cle - c'est la que les conflits de fusion remontent avant d'atteindre la production.

Cadence de release : ce qui fonctionne vraiment

Les equipes qui livrent selon une cadence fixe livrent plus fiablement que celles qui livrent "quand c'est pret". La cadence force la priorisation et empeche l'accumulation de risque qui cause des casses en production.

• Releases hebdomadaires : Ideal pour les equipes au developpement Salesforce actif. Force une coupure hebdomadaire qui garde le travail petit et le rollback facile.
• Releases bihebdomadaires : Courant a cette taille d'equipe. Correspond a la longueur de sprint typique. Assez long pour accomplir un travail significatif, assez court pour limiter le risque.
• Releases mensuelles : Ne fonctionne que si votre org est relativement stable. Chaque release mensuelle devient a fort enjeu, ce qui est stressant pour l'equipe et augmente le risque de casse.

Recommandation pour les equipes de 5 a 15 developpeurs : releases bihebdomadaires a jour fixe (par exemple un mercredi sur deux). Mettez en place le pipeline une fois, faites-le tourner a chaque sprint.

Les roles qui doivent exister (meme dans les petites equipes)

Vous n'avez pas besoin d'ingenieurs DevOps a temps plein. Vous avez besoin d'une propriete claire.

• Coordinateur de release - possede le calendrier de release et les decisions go/no-go. Peut etre un developpeur senior ou un lead technique. 2-3 heures par cycle de release.
• Reviewer de deploiement - revoit ce qui entre dans chaque deploiement, verifie la couverture de tests. Doit etre different de la personne qui a ecrit le code.
• Proprietaire du rollback - sait comment annuler chaque changement de la release. Avec Serpent, c'est un clic - mais quelqu'un doit posseder la decision de l'utiliser.

Les indicateurs qui montrent que votre DevOps fonctionne

• Frequence de deploiement : A quelle frequence deployez-vous avec succes en production ? Objectif : au moins une fois par sprint.
• Delai pour les changements : Du premier commit a la production. Objectif : moins de 2 semaines pour les changements standards.
• Taux d'echec des changements : % de deploiements causant un incident en production. Objectif : moins de 5 %.
• Delai moyen de restauration : Du temps entre la casse en production et le correctif deploye. Objectif : moins de 4 heures.

Ce sont les quatre indicateurs DORA. Mesurez-les mensuellement. Si la frequence de deploiement baisse ou le taux d'echec augmente, votre processus a un goulot d'etranglement a corriger avant que cela n'empire.

Erreurs courantes a cette taille d'equipe

• Sauter l'UAT sur les "petits" changements. Les casses en production viennent presque toujours de changements qui semblaient trop petits pour necessiter une UAT.
• Laisser le sandbox d'integration devenir obsolete. S'il a plus de 2 semaines de retard sur la production, il n'est plus utile. Rafraichissez-le selon un planning.
• Traiter les releases comme des exploits. Si chaque release exige que quelqu'un reste tard, c'est votre processus qui est casse, pas votre equipe.
• Pas de documentation de ce qui est dans chaque release. Les notes de release n'ont pas besoin d'etre formelles - un message Slack avec 5 puces suffit. Faites-le a chaque fois.

FAQ

Combien de sandboxes une equipe Salesforce mid-market a-t-elle besoin ?

Avec 3 a 8 developpeurs, un sandbox de dev, un sandbox QA et la production suffisent. Au-dela de 8 developpeurs, ajoutez des sandboxes de fonctionnalites, un sandbox d'integration ou les conflits de fusion remontent, et un sandbox UAT pour la validation metier.

Quelle cadence de release fonctionne le mieux pour une equipe Salesforce en croissance ?

Une cadence fixe bat le "quand c'est pret", car elle force la priorisation et empeche l'accumulation de risque. Le bihebdomadaire a jour fixe convient a la plupart des equipes de cette taille, l'hebdomadaire convient au developpement tres actif, et le mensuel ne fonctionne que si l'org est stable.

Faut-il un ingenieur DevOps dedie pour Salesforce ?

Pas a cette taille. Ce qu'il faut, c'est une propriete claire : un coordinateur de release pour le calendrier et la decision go/no-go, un reviewer de deploiement qui n'a pas ecrit le code, et quelqu'un qui possede la decision de revenir en arriere.

Quels indicateurs montrent que votre DevOps Salesforce fonctionne ?

Les quatre indicateurs DORA : frequence de deploiement, delai pour les changements, taux d'echec des changements et delai moyen de restauration. Mesurez-les mensuellement, et traitez une frequence de deploiement en baisse ou un taux d'echec en hausse comme un goulot d'etranglement a corriger tot.

Prendre la decision d'outillage

Pour une entreprise de 50 a 200 personnes avec 5 a 20 developpeurs Salesforce, vous avez besoin d'un outil qui soit :

• Rapide a mettre en place - vous ne pouvez pas passer 6 mois sur l'implementation
• Pas facture par utilisateur - votre equipe grandit et vous ne voulez pas de mauvaises surprises de cout
• Assez cadre pour gerer vos sandboxes - pas une toile vierge qui vous oblige a construire le pipeline depuis zero

Serpent est construit specifiquement pour cette taille d'equipe. Voir les tarifs ou essayer gratuitement.