Bonnes pratiques générales de développement pour Adobe Commerce
Cette rubrique décrit la ligne de base d’un processus de développement Adobe Commerce sain. Il décrit les processus fondamentaux, les principes de codage et les principes de conception d’application pour guider les développeurs.
Ces bonnes pratiques ont été développées sur la base d’années d’expérience dans le développement et la diffusion de projets Commerce. Adobe recommande que les initiatives techniques suivent ces bonnes pratiques et que vous amélioriez les processus et le code existants pour vous aligner sur ces bonnes pratiques.
Conventions de texte
Les mots-clés "DOIT", "NE DOIT PAS", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" et "FACULTATIF" dans cette rubrique doivent être interprétés comme décrit dans la RFC 2119.
Processus
- Une méthodologie de projet définie DOIT être convenue avant de commencer les activités du projet. Il peut s’agir de Scrum, de Cascade ou de toute autre méthodologie ou combinaison de méthodologies, à condition qu’elle soit définie.
- Le développement NE DOIT PAS commencer tant qu’une stratégie d’embranchement pour le système de contrôle de version n’est pas disponible pour l’équipe de développement.
- Le développement NE DOIT PAS démarrer tant qu’après l’approbation des spécifications techniques, l’approbation des articles d’utilisateurs et des cas d’utilisation et l’approbation des cas de test ne sont pas disponibles pour l’équipe de développement.
- Développement NE DOIT PAS démarrer tant qu’au moins un environnement de développement et d’assurance qualité n’est pas disponible.
- Les exigences spécifiques au projet qui sont obligatoires pour que le développement démarre PEUVENT être documentées dans une Définition de prêt.
- L’approbation doit être effectuée par un représentant client autorisé à valider les éléments livrables du projet.
- Dans les méthodologies de projet agiles, des exigences supplémentaires PEUVENT suivre l’approbation. Ces exigences doivent être traitées comme de nouvelles exigences et doivent être capturées, architecturées et planifiées en conséquence.
- Tout développement DOIT être testé fonctionnellement par le développeur avant envoi.
- Tout développement DOIT réussir les tests automatisés avant d’être envoyé pour révision du code. Il PEUT être configuré en tant que processus automatisé à la suite de la création d’une requête de tirage.
- Tout développement DOIT transmettre une révision manuelle du code par un architecte technique ou un développeur principal avant de l’envoyer pour l’assurance qualité.
- Tout développement DOIT transmettre l’assurance qualité avant la diffusion au client.
- Les exigences spécifiques au projet qui sont obligatoires pour la diffusion PEUVENT être documentées dans une "Définition du Terminé".
Environnement
- Tous les développeurs doivent utiliser le même IDE. PhpStorm est l’IDE recommandé pour le développement d’Adobe Commerce.
- Tous les développeurs doivent développer et tester à l’aide de la même pile technologique que celle utilisée sur les (futurs) serveurs de production. Les versions du logiciel de cette pile technologique DOIVENT correspondre aux versions majeures et mineures du logiciel installé sur les serveurs de production. Voir Configuration requise pour plus d’informations sur la pile de technologie type pour Adobe Commerce.
- L’administrateur système ou l’architecte technique PEUT fournir à l’équipe un environnement de développement local géré de manière centralisée pour assurer et promouvoir des environnements locaux égaux et à jour.
- Les développeurs et les ingénieurs QA DOIVENT avoir accès à la ligne de commande, à la base de données et aux fichiers journaux de l’environnement d’assurance qualité. Cela PEUT nécessiter une connexion VPN.
Contrôle de version
Les versions de module DOIVENT respecter la norme Semantic Versioning 2.0.0 standard.
Les dépendances sur le code base Adobe Commerce DOIVENT suivre les instructions de dépendances des versions de module.
CONTRÔLE DE RÉVISION
Les validations DOIVENT être accompagnées de messages de validation significatifs.
Sécurité
- Les fonctions non sécurisées NE DOIVENT PAS être utilisées.
- Les stratégies de prévention XSS DOIVENT être appliquées.
- Stratégies de sécurité du contenu DOIVENT être appliquées.
- Les nouvelles instances Adobe Commerce DOIVENT être diffusées sur la dernière version de sécurité d’une version qui n’a pas encore atteint la date "Fin des correctifs de sécurité". Voir Adobe Commerce Software Lifecycle Policy.