Planifier les processus de création, de test et de contrôle qualité
Cette unité passe en revue les processus de développement vous permettant de gérer les processus de création, de test et de contrôle qualité. Elle fournit également des informations sur la manière de planifier la gestion de ces processus.
Créer un plan de projet pour les builds
Selon la méthodologie que vous choisissez, vous devez sélectionner les heures et les emplacements des builds. Vous devez également déterminer l’ordre dans lequel vos builds se produisent. Par exemple, vous ne souhaitez pas concevoir le code de votre environnement de développement dans l’environnement de production sans passer par l’environnement de test au préalable.
Vous devez également réfléchir à la gestion d’un développement qui ne passe pas les tests, car vous devez annuler ce développement. Cette approche vous évite de promouvoir des erreurs. Vous pouvez gérer votre build d’un environnement à l’autre à l’aide de Microsoft Dynamics 365 Lifecycle Services.
Par exemple, une build peut restaurer tout code avec des erreurs de votre environnement de test vers votre environnement de développement, promouvoir le code réussi de l’environnement de test vers l’environnement de production, puis enfin promouvoir votre code terminé de l’environnement de développement vers l’environnement de test.
Déterminer les environnements nécessaires
Vous devez planifier la sélection de vos environnements au début de l’implémentation. Lors de la planification de vos environnements, vous devez :
- déterminer la fonction de l’environnement : déterminez si vous prévoyez d’utiliser les environnements pour le développement, les tests système, les tests d’acceptation utilisateur (UAT) ou les opérations ;
- tenir compte de la topologie de l’environnement, par exemple Développer ou Concevoir et tester ;
- tenir compte du niveau d’environnement (niveau 1 ou 2).
Un environnement de niveau 1 est un environnement à boîtier unique avec tous les composants installés sur le même serveur. Un environnement de niveau 1 utilise Microsoft SQL Server et est structuré pour optimiser l’efficacité du développement. Ce niveau n’est pas une bonne option pour les UAT ou les tests de performance.
Un environnement de niveau 2 ou supérieur est un environnement multi-boîtier avec des composants installés sur plusieurs serveurs. Au lieu de Microsoft SQL Server, les environnements de niveau 2 utilisent Microsoft Azure SQL Database. L’architecture de cet environnement est la même que celle de l’environnement de production, mais elle n’utilise pas la fonctionnalité de récupération d’urgence. Vous devez utiliser cet environnement pour les UAT et les tests de performance.
L’offre cloud standard pour les environnements comprend un environnement de niveau 1 pour le développement et les tests, un environnement de niveau 2 pour les UAT et un environnement de production. Le système fournit ces environnements à différents moments :
- Environnement de niveau 2 : lors du processus d’installation.
- Environnement de développement et de test de niveau 1 : lorsque la phase de conception démarre et après que vous avez configuré Microsoft Azure DevOps.
- Environnement de production : lors de la préparation du système de production avec Microsoft. Vous devez demander cet environnement au moyen de Lifecycle Services.
Vous pouvez également ajouter un autre environnement complémentaire pour les environnements de niveau 1 et de niveau 2, si nécessaire. De plus, vous pouvez déployer les environnements de niveau 1 en tant qu’environnements hébergés dans le cloud ou images d’environnement. Les clients ou partenaires gèrent les environnements hébergés dans le cloud. L’image d’environnement est un environnement local qui utilise un disque dur virtuel.
Vous pouvez choisir les environnements dont vous avez besoin et quand vous en avez besoin. Vous devez résumer vos listes d’environnements requis dans une matrice pour Microsoft.
Vous pouvez choisir le flux de code de création dans tous vos environnements et structurer votre ALM à l’aide du plan d’environnement.
Planifier le nombre de tests requis
Lors de l’implémentation des applications de finances et d’opérations, vous devez décider comment tester votre développement pour approbation, qui teste, quels critères vous utilisez pour approbation et comment suivre les tests. Vous pouvez tester le système à l’aide de tests unitaires, de tests de régression et de tests de performance.
Les tests unitaires sont utiles pour tester si une fonctionnalité spécifique fonctionne. Les tests unitaires ne vérifient pas si le nouveau code affecte les fonctionnalités existantes du système.
Les tests de régression exécutent un test sur un processus entier pour s’assurer que les fonctionnalités existantes fonctionnent toujours avec le nouveau développement. Par exemple, si vous apportez une modification pour ajouter des fonctionnalités liées aux clients, vous souhaiterez peut-être effectuer des tests de régression pour vous assurer que la nouvelle fonctionnalité n’interfère pas avec les fonctionnalités existantes telles que les commandes vente.
Vous pouvez également envisager de tester les performances du système pour vous assurer qu’il est stable. Pour ce faire, plusieurs utilisateurs doivent accéder au système et exécuter des processus de taxation à volume élevé. Cette approche peut vous aider à identifier des opportunités pour augmenter les performances.
Les applications de finances et d’opérations comprennent l’outil Enregistreur de tâches vous permettant de documenter les étapes d’un processus suivi par un utilisateur. Grâce à Microsoft Azure DevOps, vous pouvez lier des tâches à une solution de projet de développement. Ensuite, la tâche vous permet de suivre les mises à jour, les documents de test et d’autres notes.
Contrôle de code source et contrôle qualité pour les développeurs
Parfois, plusieurs développeurs peuvent travailler simultanément dans les applications de finances et d’opérations. Pour empêcher les développeurs d’interférer les uns avec les autres, vous pouvez configurer le contrôle de code source avec un projet Azure DevOps.
Le projet Azure DevOps héberge le code source de votre modèle, ce qui permet aux utilisateurs d’archiver et d’extraire des objets. Lorsque vous extrayez un objet, vous indiquez au système que vous apportez des modifications. Lorsque vous archivez l’objet, le système crée une version de cet objet.
Le contrôle de version vous permet d’afficher les modifications précédentes que quelqu’un a apportées. Vous pouvez annuler les modifications en attente des dernières modifications archivées. De plus, vous pouvez cliquer sur Obtenir le dernier sur les objets, afin d’extraire la dernière version archivée de l’objet. Les développeurs doivent s’assurer régulièrement qu’ils utilisent le code le plus récent à l’aide de cette fonctionnalité.
Pour assurer la qualité du développement, suivez les bonnes pratiques Microsoft Dynamics 365 X++. En outre, vous pouvez développer vos propres bonnes pratiques telles que les conventions d’affectation de noms, afin de maintenir tous les développements standardisés sur l’ensemble de l’organisation.
Sélectionner un système de contrôle de version
Dans les applications de finances et d’opérations, un système de contrôle de version est obligatoire. Azure DevOps prend en charge Team Foundation Version Control (TFVC) et Git.
Azure DevOps Team Foundation Version Control
Le système Azure DevOps Team Foundation Version Control est un système de contrôle de version unique pour les applications de finances et d’opérations. Il s’agit d’un système de contrôle de version centralisé. Autrement dit, les développeurs travaillent dans une branche et disposent d’une version de chaque fichier sur leurs machines de développement. Chaque branche appartient à un espace de travail serveur et chaque développeur travaille dans un espace de travail local. Lorsqu’un développeur archive le code source, il doit veiller à archiver la dernière version et résoudre les conflits existants.
Par défaut, les référentiels TFVC sont désactivés dans la zone Paramètres de l’organisation d’Azure DevOps. Vous devez activer les référentiels avant de pouvoir créer un projet Azure DevOps avec TFVC comme système de contrôle de version.
Pour activer Team Foundation Version Control (TFVC) dans votre organisation, procédez comme suit :
- Ouvrez Azure DevOps en accédant à dev.azure.com/<votre organisation>.
- Cliquez sur Paramètres de l’organisation dans le coin inférieur gauche du tableau de bord.
- Ouvrez Repos > Référentiels.
- Désactivez le bouton bascule Désactiver la création de référentiels TFVC dans la section Paramètres de tous les référentiels.
Vous pouvez créer des projets Azure DevOps avec TFVC comme système de contrôle de version.
Git
Git est le système de contrôle de version par défaut de Microsoft recommandé pour le développement.
Alors que TFVC est un système de contrôle de version centralisé, Git est un système distribué. Chaque développeur dispose de sa propre copie d’un référentiel source (ou d’une branche légère) et peut y apporter des modifications. Les développeurs peuvent créer des branches privées et passer d’une branche à une autre. Dans TFVC, il est plus difficile de passer d’une branche à une autre et cela nécessite souvent plusieurs environnements de développement.
Notez que vous pouvez migrer de TFVC vers Git, et vice versa.