Playbook DevOps Salesforce pour les équipes mid-market en croissance

Le problème 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 à 20 développeurs Salesforce, plusieurs sandboxes, et des cycles de release de plus en plus difficiles à gérer à mesure que l'équipe grandit.

C'est le problème DevOps du mid-market. C'est là que la plupart des équipes Salesforce en croissance restent bloquées.

Ce playbook couvre ce qui fonctionne vraiment pour des équipes de cette taille - basé sur des schémas observés dans des dizaines d'implémentations Salesforce mid-market.

La bonne stratégie d'org pour la taille de votre équipe

3 à 8 développeurs

À cette taille, la simplicité est votre alliée. Vous n'avez pas besoin de 6 environnements.

• Sandbox de dev - chaque développeur travaille dans la sienne, OU un sandbox de dev partagé si les limites d'org sont serrées
• Sandbox QA - pour tester avant la production
• Production

Flux de déploiement : Dev → QA → Production, automatisé par pipeline.

8 à 20 développeurs

À cette taille, vous avez besoin d'isolation des fonctionnalités pour éviter que les développeurs ne se bloquent entre eux.

• Sandboxes de fonctionnalités (1 par epic actif ou binôme de développeurs)
• Sandbox d'intégration - fusionne depuis tous les sandboxes de fonctionnalités
• Sandbox UAT - pour la validation métier
• Production

Le sandbox d'intégration est l'ajout clé - c'est là que les conflits de fusion remontent avant d'atteindre la production.

Cadence de release : ce qui fonctionne vraiment

Les équipes qui livrent selon une cadence fixe livrent plus fiablement que celles qui livrent "quand c'est prêt". La cadence force la priorisation et empêche l'accumulation de risque qui cause des casses en production.

• Releases hebdomadaires : Idéal pour les équipes au développement Salesforce actif. Force une coupure hebdomadaire qui garde le travail petit et le rollback facile.
• Releases bihebdomadaires : Courant à cette taille d'équipe. Correspond à 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 à fort enjeu, ce qui est stressant pour l'équipe et augmente le risque de casse.

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

Les rôles qui doivent exister (même dans les petites équipes)

Vous n'avez pas besoin d'ingénieurs DevOps à temps plein. Vous avez besoin d'une propriété claire.

• Coordinateur de release - possède le calendrier de release et les décisions go/no-go. Peut être un développeur senior ou un lead technique. 2-3 heures par cycle de release.
• Reviewer de déploiement - revoit ce qui entre dans chaque déploiement, vérifie la couverture de tests. Doit être différent de la personne qui a écrit le code.
• Propriétaire du rollback - sait comment annuler chaque changement de la release. Avec Serpent, c'est un clic - mais quelqu'un doit posséder la décision de l'utiliser.

Les indicateurs qui montrent que votre DevOps fonctionne

• Fréquence de déploiement : À quelle fréquence déployez-vous avec succès en production ? Objectif : au moins une fois par sprint.
• Délai pour les changements : Du premier commit à la production. Objectif : moins de 2 semaines pour les changements standards.
• Taux d'échec des changements : % de déploiements causant un incident en production. Objectif : moins de 5 %.
• Délai moyen de restauration : Du temps entre la casse en production et le correctif déployé. Objectif : moins de 4 heures.

Ce sont les quatre indicateurs DORA. Mesurez-les mensuellement. Si la fréquence de déploiement baisse ou le taux d'échec augmente, votre processus a un goulot d'étranglement à corriger avant que cela n'empire.

Erreurs courantes à cette taille d'équipe

• Sauter l'UAT sur les "petits" changements. Les casses en production viennent presque toujours de changements qui semblaient trop petits pour nécessiter une UAT.
• Laisser le sandbox d'intégration devenir obsolète. S'il a plus de 2 semaines de retard sur la production, il n'est plus utile. Rafraîchissez-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 cassé, pas votre équipe.
• Pas de documentation de ce qui est dans chaque release. Les notes de release n'ont pas besoin d'être formelles - un message Slack avec 5 puces suffit. Faites-le à chaque fois.

FAQ

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

Avec 3 à 8 développeurs, un sandbox de dev, un sandbox QA et la production suffisent. Au-delà de 8 développeurs, ajoutez des sandboxes de fonctionnalités, un sandbox d'intégration où les conflits de fusion remontent, et un sandbox UAT pour la validation métier.

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

Une cadence fixe bat le "quand c'est prêt", car elle force la priorisation et empêche l'accumulation de risque. Le bihebdomadaire à jour fixe convient à la plupart des équipes de cette taille, l'hebdomadaire convient au développement très actif, et le mensuel ne fonctionne que si l'org est stable.

Faut-il un ingénieur DevOps dédié pour Salesforce ?

Pas à cette taille. Ce qu'il faut, c'est une propriété claire : un coordinateur de release pour le calendrier et la décision go/no-go, un reviewer de déploiement qui n'a pas écrit le code, et quelqu'un qui possède la décision de revenir en arrière.

Quels indicateurs montrent que votre DevOps Salesforce fonctionne ?

Les quatre indicateurs DORA : fréquence de déploiement, délai pour les changements, taux d'échec des changements et délai moyen de restauration. Mesurez-les mensuellement, et traitez une fréquence de déploiement en baisse ou un taux d'échec en hausse comme un goulot d'étranglement à corriger tôt.

Prendre la décision d'outillage

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

• Rapide à mettre en place - vous ne pouvez pas passer 6 mois sur l'implémentation
• Pas facturé par utilisateur - votre équipe grandit et vous ne voulez pas de mauvaises surprises de coût
• Assez cadré pour gérer vos sandboxes - pas une toile vierge qui vous oblige à construire le pipeline depuis zéro

Serpent est construit spécifiquement pour cette taille d'équipe. Voir les tarifs ou essayer gratuitement.