Excellence opérationnelle - Modèles DevOps
En savoir plus sur l’excellence opérationnelle bien archivée → Pratiques DevOps
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Configuration du contrôle de version | ✅ Toutes les métadonnées stockées sous le format source Git en utilisant la structure du projet Salesforce DX avec .forceignore configuré pour exclure les fichiers non pertinents; tous les membres de l’équipe clonent à partir du référentiel central |
| Utilisation de l’organisation test | ✅ Les développeurs créent des organisations tests éphémères à partir de la source pour le travail sur les fonctionnalités, appliquent de nouveau les modifications au contrôle de version et abandonnent les organisations tests une fois la fonctionnalité terminée |
| Messages d’engagement | ✅ Chaque engagement inclut un message clair et concis expliquant ce qui a changé et pourquoi; les messages respectent la convention de l’équipe (par exemple, “feat:”, “fix:”, “docs:“) |
| Suivi des modifications | ✅ Chaque modification des métadonnées capturée dans le contrôle de version avec l’identité de l’auteur, l’horodatage et le diff montrant les modifications exactes |
| Processus de révision du code | ✅ Toutes les modifications liées à la production transitent par des demandes d’extraction nécessitant une approbation d’examen avant la fusion; la configuration déclarative reçoit le même examen que le code |
| Procédures de restauration | ✅ Versions antérieures récupérables à partir de l’historique Git via des opérations Checkout ou d’annulation; l’équipe a documenté les procédures de restauration testées en non production |
| Journal d’audit | ✅ Historique complet des modifications conservé dans le contrôle de version prenant en charge les exigences de conformité et les enquêtes de sécurité |
| Stratégie de branchement | ✅ Modèle de branchement Git cohérent (GitFlow, GitHub Flow ou basé sur le tronc) adapté à la taille de l’équipe et à la fréquence de publication; documenté et appliqué |
| Migration depuis l’organisation | ✅ La transition vers le développement piloté par la source est terminée tôt dans le cycle de vie de la solution avant que les habitudes se solidifient autour du développement basé sur l’organisation |
| Configuration .gitignore | ✅ Le référentiel exclut les fichiers générés, les paramètres spécifiques à l’utilisateur et les identifiants. Il inclut uniquement les fichiers sources que les équipes envisagent de mettre en version |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| L’organisation comme source de vérité | ⚠️ Le développement se fait directement dans des sandbox partagées avec des métadonnées exportées vers le contrôle de version après coup ; les organisations et le contrôle de version divergent créant des échecs de déploiement |
| Inadapté .gitignore | ⚠️ Référentiel comprend les fichiers générés, les paramètres spécifiques à l’utilisateur, les binaires volumineux ou les identifiants; Référentiel ballonne et risque l’exposition à la sécurité |
| Messages d’engagement vagues | ⚠️ Les commits du type « corriger bogue » ou « mises à jour » ne fournissent aucun contexte pour ce qui a changé ou pourquoi ; entravent les enquêtes d’audit et la maintenance future |
| Engagements peu fréquents importants | ⚠️ Les développeurs commettent de grands jeux de modifications chaque semaine plutôt que de petits engagements incrémentiels plusieurs fois par jour ; difficile à réviser, difficile d’isoler les échecs |
| Engager directement dans Main | ⚠️ Les développeurs envoient automatiquement les modifications directement à la branche principale/production en contournant l’examen et la validation; élimine les barrières de qualité |
| Aucune stratégie de branchement | ⚠️ L’équipe manque de modèle de branchement cohérent ; les développeurs créent des noms de branche arbitraires et des schémas de fusion ; créent de la confusion et des conflits de fusion |
| Fichiers binaires dans Git | ⚠️ Les fichiers binaires volumineux (PDF, vidéos, archives) engagés dans la taille du référentiel Git ballonnement et ralentissement des opérations de clonage |
| Engagement des identifiants | ⚠️ Clés d’API, mots de passe, identifiants d’intégration ou jetons de sécurité engagés dans le contrôle de version ; crée une faille de sécurité même après le retrait des engagements ultérieurs |
| Ignorer les conflits de fusion | ⚠️ Fusionner les conflits résolus en acceptant un côté sans analyse ; perd les modifications ou introduit des bogues |
| Vérification sans validation | ⚠️ L’équipe ne vérifie jamais que les métadonnées engagées représentent réellement les modifications prévues ; les erreurs de format des métadonnées ou les modifications involontaires sont transmises |
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Sandbox Developer | ✅ Les développeurs individuels utilisent des sandbox Developer pour le travail de fonctionnalité, les tests unitaires et l’itération rapide. Chaque développeur a un environnement dédié |
| Sandbox Developer Pro | ✅ Les équipes qui développent des packages gérés ou qui nécessitent des limites de stockage plus élevées utilisent des sandbox Developer Pro pour le travail collaboratif |
| Sandbox Partial Copy | ✅ Le test d’intégration utilise des sandbox Partial Copy avec des échantillons de données représentatifs (10 000 enregistrements par objet) configurés via des modèles de données |
| Sandbox Full Copy | ✅ Test des performances, mise en scène de type production et validation de la migration des données utilisent des sandbox Full Copy contenant des données de production complètes et une configuration |
| Contrôles de confidentialité des données | ✅ Accès sandbox Full Copy restreint aux rôles nécessitant des données de production; masquage des données Shield Platform Encryption appliqué pour une utilisation hors production lorsque approprié |
| Configuration du point de terminaison d’intégration | ✅ Chaque niveau sandbox se connecte aux points de terminaison de test correspondants pour les intégrations externes ; les intégrations de production ne se connectent jamais à partir de sandbox |
| Configuration spécifique à l’environnement | ✅ L’architecture d’intégration utilise des types de métadonnées personnalisées ou des paramètres personnalisés pour externaliser les URL de point de terminaison, les identifiants et les indicateurs de fonctionnalité par environnement |
| Automatisation après actualisation | ✅ Les actualisations sandbox déclenchent des scripts Salesforce CLI automatisés qui restaurent les paramètres spécifiques à la sandbox, notamment les identifiants d’intégration, l’amorçage des données test, les états d’indicateur de fonctionnalité et la délivrabilité des e-mails |
| Actualiser la planification | ✅ Planification d’actualisation de sandbox documentée et communiquée; actualisations planifiées pendant les périodes de faible activité afin de minimiser les perturbations de l’équipe |
| Modèles de données | ✅ Les sandbox Partial Copy utilisent des modèles de données bien conçus sélectionnant des données représentatives entre les objets en préservant l’intégrité référentielle |
| Conventions de nommage | ✅ Les sandbox suivent une convention de nommage claire indiquant l’objet, le propriétaire et le cycle d’actualisation (par exemple, “dev-integration-q2”, “uat-release-2-4”) |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Sandbox de développement partagé | ⚠️ Tous les développeurs travaillent en sandbox partagée unique en remplaçant les modifications des autres; crée une confusion sur ce qui est l’état déployable |
| Sandbox Stale | ⚠️ Sandbox non actualisées pendant des mois s’écartant significativement de la configuration de production ; les tests dans un environnement non représentatif entraînent des échecs de déploiement |
| Aucune gouvernance des données en copie complète | ⚠️ Des sandbox Full Copy contenant des informations d’identification personnelle en production, des données financières, des données HIPAA accessibles à toute l’équipe de développement sans contrôle d’accès ni masquage des données |
| Intégrations en production depuis une organisation sandbox | ⚠️ Les sandbox se connectent directement aux points de terminaison d’intégration de production créant un risque de transactions tests affectant les données de production ou les systèmes externes |
| Configuration après actualisation manuelle | ⚠️ Les actualisations de sandbox nécessitent des heures de restauration manuelle des paramètres de reconfiguration ; les frais généraux découragent l’actualisation des sandbox aussi souvent que nécessaire |
| Aucune documentation sandbox | ⚠️ L’équipe manque de documentation sur les objectifs de l’organisation sandbox, les planifications d’actualisation, le contenu des données ou les procédures d’accès ; les développeurs devinent l’environnement à utiliser dans quel but |
| Type d’environnement unique | ⚠️ L’équipe utilise un seul type de sandbox (généralement Developer ou Full Copy) à toutes fins utiles; manque les avantages d’une stratégie sandbox appropriée par activité |
| Thésaurisation sandbox | ⚠️ Sandbox allouées à des individus ou à des projets et jamais sorties lorsqu’elles n’étaient plus nécessaires ; rareté artificielle malgré les licences disponibles |
| Données de test inadéquates | ⚠️ Les données de test dans les organisations sandbox ne représentent pas les caractéristiques des données de production (volumes, relations, cas périphériques) ; le test dans un environnement irréaliste passe à côté des problèmes de production |
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Étape de validation source | ✅ Les développeurs engagent les modifications dans les branches de fonctionnalité dans Git avec des messages d’engagement clairs expliquant le contexte et la justification |
| Étape d’analyse statique | ✅ Salesforce Code Analyzer analyse Apex pour détecter les failles de sécurité (OWASP Top 10), les anti-patterns de performance (SOQL dans les boucles, DML dans les boucles), les problèmes de qualité de code (complexité, duplication), et les risques de limitation du gouverneur; s’exécute en quelques secondes en fournissant un feedback immédiat |
| Étape de test unitaire | ✅ Les tests Apex exécutent la logique métier validatrice et la conformité de limite du gouverneur dans l’organisation test éphémère ou sandbox d’intégration dédiée; les tests correctement isolés se terminent en moins de 5 minutes |
| Étape de déploiement de la validation | ✅ Déploiement des métadonnées dans une sandbox d’intégration en utilisant Salesforce CLI avec l’indicateur –checkonly pour le déploiement de validation uniquement en exécutant des tests sans engager de modifications |
| Étape de test d’intégration | ✅ Les tests automatisés valident les workflows à composants multiples, les contrats d’intégration externe, les flux d’événements de plate-forme et les chaînes de traitement asynchrones par rapport à un environnement d’intégration partagé avec la gestion des données de test |
| Étape d’analyse de sécurité | ✅ Des outils de sécurité supplémentaires analysent les identifiants codés en dur, les dépendances vulnérables, les infractions CRUD/FLS et les infractions à la politique de conformité. |
| Étape de déploiement UAT | ✅ Les modifications passant toutes les portes automatisées sont déployées dans l’environnement de test d’acceptation utilisateur pour la validation métier. Le déploiement peut être automatisé ou nécessiter une approbation manuelle en fonction du risque de modification |
| Étape de déploiement en production | ✅ Après l’approbation UAT, les modifications sont déployées en production avec l’exécution automatisée en un clic, la consignation complète et la capacité de restauration immédiate |
| Temps d’exécution du pipeline | ✅ Le pipeline de bout en bout est terminé en moins de 15 minutes pour les modifications typiques, ce qui permet une rétroaction rapide; plus long pour les déploiements importants ou les séries de tests étendues |
| Élaboration d’artefacts | ✅ Pipeline conserve les packages de déploiement, les résultats de test, les rapports d’analyse de sécurité et les journaux d’exécution pour la conformité et le dépannage |
| Outillage du pipeline | ✅ Les équipes utilisent Salesforce DevOps Center pour la CI/CD native de la plate-forme, ou s’intègrent à des plates-formes externes (Actions GitHub, GitLab CI, Azure DevOps, CircleCI, Jenkins, Copado, Gearset, AutoRABIT) |
| Notifications d’échec | ✅ Les pannes de pipeline déclenchent des notifications pour engager l’auteur et les canaux appropriés avec un contexte de diagnostic permettant une résolution rapide |
| Protection de branche | ✅ Branches principales/de production protégées nécessitant de passer les contrôles CI et les examens approuvés avant la fusion; engagements directs empêchés |
| Promotion de l’environnement | ✅ Le flux des modifications à travers le parcours de promotion défini (dev → intégration → UAT → production) avec validation à chaque étape |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Déploiements manuels | ⚠️ Modifications déployées manuellement via des ensembles de modifications ou des commandes Salesforce CLI avec des étapes incohérentes ; erreurs humaines, étapes manquées, absence de piste d’audit |
| Aucune analyse statique | ⚠️ Les pipelines ignorent Salesforce Code Analyzer ou des outils similaires; les failles de sécurité, les anti-modèles de performance, les problèmes de qualité de code atteignent la production |
| Test insuffisant | ⚠️ Le pipeline valide seulement une couverture minimale de 75 % sans exécuter de tests d’intégration ni valider les flux utilisateur clés ; les régressions passent à travers |
| Aucune analyse de sécurité | ⚠️ Les pipelines ne scannent jamais les identifiants codés en dur, les dépendances vulnérables ou les infractions CRUD/FLS ; les problèmes de sécurité découverts lors des contrôles de production ou de sécurité |
| Exécution lente du pipeline | ⚠️ Le pipeline de bout en bout prend 45 à 60 minutes et plus, ce qui décourage les engagements fréquents et ralentit les boucles de rétroaction ; les développeurs s’engagent moins souvent en accumulant des modifications plus importantes |
| Échecs de pipeline ignorés | ⚠️ Les équipes ignorent ou remplacent les échecs de pipeline pour respecter les délais ; les barrières de qualité deviennent un théâtre plutôt que de véritables contrôles |
| Aucune parité d’environnement de test | ⚠️ CI/CD valide dans un environnement avec une configuration, des limites ou des caractéristiques de données différentes de celles de la production ; réussir la validation ne garantit pas le succès de la production |
| Capacité de restauration manquante | ⚠️ Le pipeline automatise le déploiement, mais n’automatise aucune restauration ; la reprise après un mauvais déploiement nécessite des procédures d’urgence manuelles |
| Aucun journal de déploiement | ⚠️ Déploiements exécutés sans consignation complète ; dépannage des échecs ou audit des déploiements devient difficile |
| Tests tout ou rien | ⚠️ Pipeline exécute tous les tests pour chaque modification, quelle que soit la modification ; la suite de tests de 30 minutes est exécutée même pour les mises à jour de la documentation |
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Indicateurs de fonctionnalité | ✅ Déploiement des modifications à haut risque avec des fonctionnalités désactivées derrière la configuration du type de métadonnées personnalisées ou des paramètres personnalisés. Active les tests en production sans exposition de l’utilisateur, le déploiement progressif dans les segments, les tests A/B et l’annulation instantanée via un changement de configuration |
| Étendue de l’indicateur de fonctionnalité | ✅ Indicateurs de fonctionnalité réservés aux changements à haut risque affectant des processus métiers critiques, des opérations sensibles aux performances ou de nouveaux modèles d’intégration ; toutes les fonctionnalités n’ont pas besoin d’indicateurs |
| Déploiements Canary | ✅ Modifications critiques pour l’entreprise en commençant par un petit sous-ensemble d’utilisateurs (5 à 10 % via des ensembles d’autorisations ou le filtrage des attributs utilisateur) ; cohorte Canary suivie intensivement 24 à 48 heures mesurant les taux de réussite, les performances, les taux d’erreur avant d’étendre le déploiement |
| Fenêtres de déploiement | ✅ Déploiements planifiés pendant les périodes de faible utilisation informés par les journaux d’utilisation de l’API Event Monitoring montrant les modèles de trafic réels; évite les pics d’utilisation, la fermeture du mois, la fermeture du trimestre, les événements commerciaux majeurs |
| Communication de déploiement | ✅ Les parties prenantes reçoivent une notification préalable des fenêtres de déploiement, notamment la durée prévue, les fonctionnalités affectées et le calendrier de décision d’annulation |
| Procédures de restauration | ✅ Procédures de restauration documentées et testées pour chaque type de déploiement; l’équipe peut exécuter la restauration en moins de 30 minutes si nécessaire |
| Tests d’annulation | ✅ Procédures de restauration validées dans un environnement non-production avant des déploiements importants garantissant l’existence d’une capacité de récupération |
| Validation du déploiement | ✅ Les tests de fumée post-déploiement valident les flux utilisateur critiques, les points de terminaison d’intégration et les fonctionnalités clés immédiatement après la publication |
| Coordination des changements | ✅ Stratégie de déploiement coordonnée lorsque les modifications couvrent plusieurs systèmes ou nécessitent des versions synchronisées entre Salesforce et des plates-formes externes |
| Surveillance pendant le déploiement | ✅ Surveillance avancée active pendant la période de déploiement et la période d’observation post-déploiement (24 à 48 heures) en surveillant les pics de taux d’erreur, la dégradation des performances ou les échecs de flux utilisateur |
| Modèle bleu-vert pour les intégrations | ✅ Les services externes frontaux de Salesforce utilisent des déploiements bleu-vert en maintenant deux environnements de production, en déployant d’abord sur inactif, puis en basculant le trafic après validation |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Déploiements Big Bang | ⚠️ Versions volumineuses contenant de nombreuses fonctionnalités, refactorisations et modifications déployées simultanément sans déploiement progressif ; l’échec impacte immédiatement tous les utilisateurs |
| Déploiements en heures de pointe | ⚠️ Sorties planifiées pendant les heures ouvrables de pointe (mi-journée, fin de mois, fin de trimestre) lorsque l’utilisation est la plus élevée et l’impact des problèmes sur les utilisateurs maximisé |
| Aucun plan de restauration | ⚠️ Les déploiements se déroulent sans procédures de restauration documentées et testées ; lorsque des problèmes apparaissent, l’équipe se démène pour trouver la reprise |
| Commutateurs de fonctionnalité après coup | ⚠️ Indicateurs de fonctionnalité ajoutés de façon réactive en cas de problème plutôt que conçus de façon proactive pour les changements à haut risque; limite les options de restauration à l’inversion complète du déploiement |
| Aucune validation de déploiement | ⚠️ Changements déployés en production sans tests de fumée post-déploiement ; l’équipe considère que le déploiement a réussi et passe à autre chose ; problèmes découverts quelques heures plus tard par les utilisateurs |
| Procédures de restauration non testées | ⚠️ Procédures de restauration documentées, mais jamais testées en non-production; lors d’un incident réel, la procédure échoue ou s’avère inadéquate |
| Modifications simultanées de systèmes multiples | ⚠️ Modifications coordonnées entre Salesforce et les systèmes externes déployés sans synchronisation ni test de compatibilité ; crée des échecs d’intégration |
| Aucune amélioration de la surveillance | ⚠️ Les déploiements se déroulent sans surveillance renforcée pendant la période de déploiement ; problèmes détectés par des plaintes des utilisateurs plutôt que par des alertes proactives |
| Déploiements le week-end | ⚠️ Versions majeures déployées le vendredi soir ou le week-end lorsque la couverture des astreintes est réduite et la disponibilité du support fournisseur limitée |
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Couverture de test unitaire | ✅ Couverture de test significative validant les règles métiers, les requêtes périphériques, les chemins d’erreur et l’approche de limite du gouverneur; dépasse significativement 75 % d’exigence minimale |
| Qualité du test unitaire | ✅ Les tests valident la logique métier, pas la fonctionnalité de la plate-forme ; les tests unitaires bien écrits sont rapides (millisecondes), isolés (pas d’état partagé) et ciblés (chaque test valide un comportement) |
| Tester la stratégie des données | ✅ Les tests utilisent des méthodes @TestSetup pour les données de test courantes ; évitez les requêtes SOQL dans les tests si possible ; utilisez Test.loadData() pour charger des ressources statiques |
| Dépendances externes fictives | ✅ Les tests unitaires simulent des appels externes en utilisant des stubs de test et l’injection de dépendance, ce qui permet une exécution rapide sans requêtes HTTP réelles |
| Tests d’intégration | ✅ Valider les interactions entre les déclencheurs, les flux, les événements de plate-forme, les tâches par lot et les appels externes exécutés dans des organisations sandbox avec des données de test représentatives |
| Fiabilité du test d’intégration | ✅ Les tests d’intégration sont répétitifs et déterministes; les échecs sporadiques corrigés par des mécanismes de synchronisation tels que les ID de relecture d’événements de plate-forme et les interrogations de tâches par lot |
| Tests de bout en bout | ✅ Test de navigateur automatisé (Selenium, Playwright, Provar) valide les parcours utilisateur complets pour les flux critiques de l’entreprise en exerçant le système à travers l’interface utilisateur exactement comme les utilisateurs interagissent |
| Focus du test E2E | ✅ Les tests E2E se concentrent sur les parcours utilisateur les plus intéressants en raison du ralentissement de l’exécution (minutes par test) et de la charge de maintenance plus élevée liée aux modifications de l’interface utilisateur |
| Test de charge | ✅ Performances validées sous des chargements d’utilisateurs et des volumes de données simultanés réalistes en utilisant des services Salesforce Load Testing ou des outils tiers ; révèle des problèmes de limitation du gouverneur, un contentieux de verrouillage, une dégradation des performances |
| Fréquence de test de chargement | ✅ Tests de charge exécutés avant les versions majeures et périodiquement (trimestriellement) pour valider les performances à des volumes de production 3x-5x actuels |
| Pyramide test | ✅ distribution de test équilibrée: beaucoup de tests unitaires (centaines, minutes), moins de tests d’intégration (dizaines, minutes), peu de tests E2E (moins de 20 minutes); retour rapide à la base, validation complète en haut |
| Isolation test | ✅ Les tests ne dépendent pas les uns des autres; peuvent être exécutés dans n’importe quel ordre; chaque test laisse le système en état propre ou utilise @TestSetup pour un point de départ cohérent |
| Cas de test négatifs | ✅ Les tests valident le traitement des erreurs, l’application des règles de validation, l’application des autorisations et la dégradation gracieuse dans des conditions défavorables |
| Test des limites du gouverneur | ✅ Les tests valident spécifiquement le comportement proche des limites du gouverneur, y compris les limites en requêtes SOQL, les limites en DML, le temps processeur, la taille du tas |
| Exécution de test continue | ✅ Les tests sont automatiquement exécutés à chaque validation via le pipeline CI/CD; les tests échoués empêchent le déploiement dans des environnements supérieurs |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Test de couverture | ⚠️ Tests écrits uniquement pour atteindre une couverture minimale de 75 % sans validation de règles métiers ou de cas limites ; tests qui n’affirment rien ou testent des chemins de code triviaux |
| Test des fonctionnalités de la plate-forme | ⚠️ Les tests vérifient que Salesforce enregistre les enregistrements ou les requêtes SOQL fonctionnent plutôt que de valider la logique métier ; gaspille des efforts sur les garanties de la plate-forme |
| Aucune stratégie fictive | ⚠️ Les tests unitaires effectuent des appels externes réels à des systèmes externes ; les tests sont lents, fragiles pour la disponibilité du système externe et consomment des limites en API |
| Échecs de test sporadiques | ⚠️ Les tests réussissent ou échouent de façon imprévisible en fonction du calendrier d’exécution, de l’état des données ou de l’ordre d’exécution des tests ; les équipes apprennent à ignorer les échecs et à réexécuter jusqu’à ce que les tests réussissent |
| Aucun test d’intégration | ⚠️ Seuls les tests unitaires existent ; l’équipe ne valide jamais le bon fonctionnement des déclencheurs, des flux, des événements de plate-forme et des tâches par lot |
| Test manuel E2E uniquement | ⚠️ Flux utilisateur critiques validés manuellement avant chaque version ; pas de tests E2E automatisés ; régressions découvertes en production lorsque les tests manuels manquent des scénarios |
| Test à vide | ⚠️ Performances jamais validées sous des charges simultanées réalistes ; problèmes de limitation du gouverneur, contention de verrouillage ou dégradation des performances découverts en production |
| Test des dépendances de données | ⚠️ Les tests dépendent d’enregistrements spécifiques existants dans l’organisation ou supposent une configuration utilisateur particulière ; se rompre lors de l’actualisation de sandbox ou de changements de configuration |
| Aucun cas de test négatif | ⚠️ Les tests valident uniquement les scénarios de parcours heureux ; ne testent jamais la gestion des erreurs, l’application automatique de la validation ou les contrôles d’autorisation ; modes d’échec non découverts |
| Tests ignorés | ⚠️ Échec des tests commentés hors de @isTest et ignorés plutôt que corrigés ; la suite de tests se dégrade au fil du temps à mesure que de nouveaux tests sont ignorés |
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Réviser la couverture | ✅ Toutes les modifications liées à la production transitent par l’examen de code via des requêtes d’extraction nécessitant une approbation avant la fusion; inclut Apex, Aura, LWC, Flux, règles de validation, ensembles d’autorisations, règles de partage |
| Liste de contrôle des critères de révision | ✅ Liste de contrôle explicite couvrant la sécurité (application CRUD/FLS, validation des entrées), les performances (masse en masse, optimisation SOQL), la conformité des limites du gouverneur (modèles de traitement, prévention de la récursion), la maintenabilité (nommage, documentation, complexité), la couverture des tests (tests significatifs, cas de bord), la cohérence architecturale (modèles de conception, séparation des préoccupations) |
| Révision des limites en taille | ✅ Tirer les requêtes gardées sous 400 lignes de changement significatif permettant un examen approfondi; grandes fonctionnalités divisées en plus petites modifications incrémentielles qui peuvent être examinées individuellement et déployées indépendamment |
| Vérifier le calendrier | ✅ Examens effectués dans un jour ouvrable en maintenant la dynamique de développement et en fournissant des commentaires rapides; les examens retardés créent un changement de contexte |
| Contrôles préalables à l’examen automatisés | ✅ Analyse statique, tests unitaires et scan de sécurité exécutés automatiquement avant l’examen humain demandé; les contrôles automatisés détectent les problèmes mécaniques afin de concentrer les examinateurs sur la conception et la logique métier |
| Responsabilité d’examen distribué | ✅ Responsabilité de l’examen du code répartie entre l’équipe de prévention des blocages et de partage Knowledge; les développeurs juniors examinent le code senior et expliquent leur propre code lors des examens |
| Vérifier la qualité des commentaires | ✅ Les examinateurs fournissent des commentaires précis et exploitables avec une justification; distinguez les changements requis (problèmes bloquants) et les suggestions (améliorations agréables à avoir) |
| Consulter la documentation | ✅ Les descriptions de requêtes d’extraction expliquent ce qui a changé, pourquoi il a changé, quels tests ont été effectués, et toutes les considérations de déploiement spéciales ou procédures de restauration |
| Examen de la configuration déclarative | ✅ Les flux, les règles de validation et les changements d’autorisation reçoivent la même rigueur d’examen que le code; la configuration est architecturale et mérite un examen minutieux |
| Suivi des commentaires | ✅ Tous les commentaires d’examen traités avant la fusion; les questions auxquelles il a été répondu, les modifications mises en œuvre ou les raisons pour lesquelles la suggestion n’a pas été adoptée |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Aucun examen de code | ⚠️ Modifications engagées directement dans la branche de production sans aucun examen par les pairs; élimine le mécanisme de détection des défauts principaux |
| Estampage en caoutchouc | ⚠️ Les examinateurs approuvent les demandes d’extraction en quelques secondes sans examiner réellement les modifications ; l’examen devient une vérification de la conformité des cases à cocher plutôt qu’une vérification de la qualité |
| Bottleneck d’examinateur unique | ⚠️ Un seul développeur senior autorisé à réviser le code ; crée un goulot d’étranglement et un point d’échec unique ; Knowledge concentré plutôt que distribué |
| Requêtes d’extraction massives | ⚠️ Extraire les requêtes contenant des milliers de lignes de modifications couvrant plusieurs fonctionnalités ; impossible de les examiner en profondeur conduisant à un examen superficiel |
| Examens retardés | ⚠️ Tirer les requêtes restent sans révision pendant des jours ou des semaines ; les développeurs perdent le contexte et passent à d’autres travaux ; les commentaires de révision arrivent lorsque le développeur a basculé le contexte mental |
| Aucun critère d’examen | ⚠️ L’équipe n’a pas de critères explicites pour ce que les examinateurs devraient examiner; la qualité de l’examen varie énormément selon les examinateurs; certains examinateurs se concentrent sur le style, d’autres sur la logique, aucun complet |
| Révision sans test | ⚠️ Les examinateurs approuvent les modifications uniquement en fonction de l’inspection du code sans extraire la branche et tester localement ou valider la réussite des tests automatisés |
| Contrôles automatisés ignorés | ⚠️ Les examinateurs approuvent les demandes d’extraction malgré l’échec de l’analyse statique, des analyses de sécurité ou des tests unitaires; va à l’encontre de l’objectif des barrières de qualité automatisées |
| Culture d’examen hostile | ⚠️ Les examens deviennent une critique personnelle ou un exercice compétitif plutôt qu’une amélioration collaborative de la qualité ; décourage l’apprentissage et la sécurité psychologique |
| Aucun examen déclaratif | ⚠️ Les flux, les règles de validation, les ensembles d’autorisations et les règles de partage se déploient sans examen pendant que le code Apex est examiné minutieusement ; crée un écart de qualité dans la configuration déclarative |