Améliorer le cycle de développement - AWS Directives prescriptives

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Améliorer le cycle de développement

Le développement de logiciels pour le cloud pose de nouveaux défis aux ingénieurs logiciels, car il est très difficile de répliquer l'environnement d'exécution localement sur la machine de développement. Un moyen simple de valider le logiciel consiste à le déployer dans le cloud et à le tester sur place. Cependant, cette approche implique un long cycle de feedback, en particulier lorsque l'architecture logicielle contient plusieurs déploiements sans serveur. L'amélioration de ce cycle de feedback réduit le temps nécessaire au développement des fonctionnalités, ce qui réduit considérablement le délai de mise sur le marché.

Tests dans le cloud

Tester directement dans le cloud est le seul moyen de s'assurer que vos composants architecturaux, tels que les passerelles dans Amazon API Gateway, lesAWS Lambda fonctions, les tables Amazon DynamoDB et les autorisationsAWS Identity and Access Management (IAM), sont correctement configurés. Il peut également s'agir du seul moyen fiable de tester les intégrations de composants. Bien que certainsAWS services (tels que DynamoDB) puissent être déployés localement, la plupart d'entre eux ne peuvent pas être répliqués dans une configuration locale. Dans le même temps, les outils tiers tels que Moto et LocalStackqui simulentAWS des services à des fins de test peuvent ne pas refléter correctement les contrats d'API de service réels, ou le nombre de fonctionnalités peut être limité.

Cependant, la partie la plus complexe du logiciel d'entreprise réside dans la logique métier, et non dans l'architecture cloud. L'architecture change moins souvent que le domaine, qui doit répondre aux nouvelles exigences de l'entreprise. Ainsi, tester la logique métier dans le cloud devient un processus intense qui consiste à modifier le code, à lancer un déploiement, à attendre que l'environnement soit prêt et à valider le changement. Si un déploiement ne prend que 5 minutes, il faudra une heure ou plus pour apporter et tester 10 modifications de la logique métier. Si la logique métier est plus complexe, les tests peuvent nécessiter plusieurs jours à attendre la fin des déploiements. Si vous avez plusieurs fonctionnalités et plusieurs ingénieurs dans l'équipe, l'entreprise se rend rapidement compte de cette période prolongée.

Tester localement

Une architecture hexagonale aide les développeurs à se concentrer sur le domaine plutôt que sur les détails techniques de l'infrastructure. Cette approche utilise des tests locaux (les outils de test unitaires dans le cadre de développement que vous avez choisi) pour couvrir les exigences logiques du domaine. Vous n'aurez pas à perdre du temps à résoudre des problèmes d'intégration technique ou à déployer votre logiciel dans le cloud pour tester la logique métier. Vous pouvez exécuter des tests unitaires localement et réduire la boucle de rétroaction de quelques minutes à quelques secondes. Si un déploiement prend 5 minutes mais que les tests unitaires se terminent en 5 secondes, cela représente une réduction significative du temps nécessaire à la détection des erreurs. LaTester d'abord la logique métier section qui suit dans ce guide décrit cette approche plus en détail.

Parallélisation du développement

L'approche de l'architecture hexagonale permet aux équipes de développement de paralléliser les efforts de développement. Les développeurs peuvent concevoir et implémenter les différents composants du service individuellement. Cette parallélisation est possible grâce à l'isolation de chaque composant et aux interfaces définies entre chaque composant.

Délai de mise sur le marché du produit

Les tests unitaires locaux améliorent le cycle de feedback sur le développement et réduisent le délai de commercialisation des nouveaux produits ou fonctionnalités, en particulier lorsque ceux-ci contiennent une logique métier complexe, comme expliqué précédemment. En outre, l'augmentation de la couverture du code par les tests unitaires réduit considérablement le risque d'introduction de bogues de régression lorsque vous mettez à jour ou refactorisez la base de code. La couverture des tests unitaires vous permet également de refactoriser en permanence la base de code pour qu'elle reste bien organisée, ce qui accélère le processus d'intégration des nouveaux ingénieurs. Ceci est discuté plus en détail dans laQualité dès le design section. Enfin, si la logique métier est bien isolée et testée, elle permet aux développeurs de s'adapter rapidement à l'évolution des exigences fonctionnelles et non fonctionnelles. Ceci est expliqué plus en détail dans laS'adapter au changement section.