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.
Organisation et méthodes de travail
Comme toutes les stratégies architecturales, les micro-frontends ont des implications qui vont bien au-delà de la technologie qu'une organisation choisit de mettre en œuvre. La décision de créer des applications micro-frontales doit être conforme à l'entreprise, au produit, à l'organisation, aux opérations et même à la culture (par exemple, en responsabilisant les équipes et en décentralisant la prise de décision). En retour, ce type d'architecture micro-frontend permet un développement réellement agile et axé sur le produit, car il réduit considérablement les frais de communication entre des équipes par ailleurs indépendantes.
Développement agile
L'idée du développement logiciel agile est devenue si universelle ces dernières années que pratiquement toutes les organisations prétendent travailler de manière agile. Bien qu'une définition concluante de l'agile dépasse le cadre de cette stratégie, il convient de passer en revue les éléments clés pertinents pour le développement de micro-frontend.
Le paradigme agile repose sur le Manifeste agile
Dans le contexte de l'architecture micro-frontend, il est important d'adopter les principes agiles suivants :
-
« Fournissez fréquemment des logiciels fonctionnels, de quelques semaines à quelques mois, en privilégiant les délais les plus courts. »
Ce principe souligne à quel point il est important de travailler par étapes et de livrer des logiciels à la production aussi régulièrement et aussi souvent que possible. D'un point de vue technologique, cela fait référence à l'intégration continue et à la livraison continue (CI/CD). Dans CI/CD, les outils et les processus de création, de test et de déploiement font partie intégrante de chaque projet logiciel. Le principe implique également que l'infrastructure d'exécution et les responsabilités opérationnelles doivent appartenir à l'équipe. Cette propriété est particulièrement importante dans les systèmes distribués où les sous-systèmes indépendants peuvent avoir des exigences très différentes en matière d'infrastructure et d'exploitation.
-
« Construisez des projets autour de personnes motivées. Donnez-leur l'environnement et le soutien dont ils ont besoin, et faites-leur confiance pour accomplir leur travail. »
« Les meilleures architectures, exigences et conceptions sont le fruit d'équipes auto-organisées. »
Ces deux principes mettent l'accent sur les avantages de la propriété, de l'indépendance et de end-to-end la responsabilité. Une architecture de micro-frontend sera efficace lorsque (et seulement lorsque) les équipes seront véritablement propriétaires de leurs micro-frontends. La nd-to-end responsabilité, depuis la conception jusqu'à la livraison et à l'exploitation, en passant par la conception et la mise en œuvre, garantit que l'équipe peut réellement s'approprier. Cette indépendance est requise, tant sur le plan technique qu'organisationnel, pour que l'équipe soit autonome quant à l'orientation stratégique. Nous ne recommandons pas l'utilisation d'une plateforme micro-frontend dans une organisation centralisée qui utilise un modèle de développement en cascade.
Composition et taille de l'équipe
Pour qu'une équipe logicielle puisse exercer ses responsabilités, elle doit se gouverner elle-même, y compris comment et ce qu'elle fournit, dans les limites imposées par l'organisation.
Pour être efficaces, les équipes doivent être en mesure de fournir des logiciels de manière indépendante et avoir le pouvoir de décider de la meilleure façon de les fournir. Une équipe qui reçoit les exigences relatives aux fonctionnalités d'un chef de produit externe ou des conceptions d'interface utilisateur d'un concepteur externe, sans être impliquée dans la planification de ces éléments, ne peut pas être considérée comme autonome. Les fonctionnalités peuvent enfreindre les contrats ou fonctionnalités existants. De telles violations nécessiteront de nouvelles discussions et négociations, avec le risque de retarder la livraison et d'introduire des conflits inutiles entre les équipes.
Dans le même temps, les équipes ne doivent pas devenir trop grandes. Alors qu'une équipe plus nombreuse dispose de plus de ressources et peut s'adapter aux absences individuelles, la complexité de la communication augmente de façon exponentielle avec chaque nouveau membre. Il n'est pas possible de définir une taille d'équipe maximale universellement valide. Le nombre de personnes nécessaires à un projet dépend de facteurs tels que la maturité de l'équipe, la complexité technique, le rythme d'innovation et l'infrastructure. Par exemple, Amazon applique la règle des deux pizzas : une équipe trop nombreuse pour être nourrie de deux pizzas doit être divisée en équipes plus petites. Cela peut être un défi. La scission doit se faire selon des limites naturelles et donner à chaque équipe l'autonomie et la maîtrise de son travail.
DevOps culture
DevOps fait référence à une pratique de génie logiciel dans laquelle les étapes du cycle de développement sont étroitement intégrées du point de vue organisationnel et technique. Contrairement à la croyance populaire, DevOps c'est une question de culture et d'état d'esprit, et très peu de rôles et d'outils.
Traditionnellement, une organisation logicielle devait disposer d'équipes de spécialistes, notamment pour la conception, la mise en œuvre, les tests, le déploiement et les opérations. Chaque fois qu'une équipe terminait son travail, elle confiait le projet à l'équipe suivante. Cependant, la livraison de logiciels par le biais de silos d'équipes spécialisées entraîne des frictions lors des transferts. Dans le même temps, lorsque les spécialistes sont contraints de travailler dans une optique étroite, ils manquent de connaissances dans les domaines voisins et n'ont pas de vision systémique du produit. Ces déficits peuvent entraîner une faible cohérence du produit logiciel.
Par exemple, lorsqu'un architecte logiciel conçoit une solution qui doit être mise en œuvre par un membre d'une autre équipe, il peut négliger certains aspects inhérents à la mise en œuvre (tels que l'inadéquation des dépendances). Les développeurs prennent ensuite des raccourcis (comme un patch en forme de singe), ou une formalisation back-and-forth est initiée entre l'architecte et l'équipe de développement. En raison de la surcharge liée à la gestion de ces processus, le développement n'est plus agile (au sens de flexible, adaptatif, progressif et informel).
Bien que le terme DevOps se rapporte principalement à la culture, il implique les technologies et les processus qui le rendent DevOps possible dans la pratique. DevOps est étroitement lié au CI/CD. Lorsqu'un développeur a fini d'implémenter un incrément de logiciel, il le commet dans un système de contrôle de version tel que Git. Traditionnellement, un système de build créait et intégrait ensuite le logiciel, puis le testait et le publiait dans le cadre d'un processus plus ou moins unifié et centralisé. Avec CI/CD, la création, l'intégration, les tests et la publication du logiciel sont inhérents et automatisés. Idéalement, le processus fait partie du projet logiciel lui-même par le biais de fichiers de configuration spécifiquement adaptés au projet donné.
Le plus grand nombre possible d'étapes sont automatisées. Par exemple, les pratiques de test manuel devraient être réduites, car presque tous les types de tests peuvent être automatisés. Lorsque le projet est configuré de cette manière, les mises à jour d'un produit logiciel peuvent être fournies plusieurs fois par jour en toute confiance. Une autre technologie prise en charge DevOps est l'infrastructure en tant que code (IaC).
Traditionnellement, la configuration et la maintenance de l'infrastructure informatique nécessitaient le travail manuel d'installation et de maintenance du matériel (configuration des câbles et des serveurs dans un centre de données) et des logiciels opérationnels. C'était nécessaire, mais cela présentait de nombreux inconvénients. L'installation prenait beaucoup de temps et était source d'erreurs. Le matériel était souvent surprovisionné ou sous-approvisionné, ce qui entraînait des dépenses excessives ou une dégradation des performances. En utilisant iAC, vous pouvez décrire les exigences d'infrastructure d'un système informatique par le biais d'un fichier de configuration à partir duquel les services cloud peuvent être déployés et mis à jour automatiquement.
Qu'est-ce que tout cela a à voir avec les micro-frontends ? DevOps, CI/CD et IaC sont des compléments idéaux à une architecture de micro-frontend. Les avantages des micro-frontends reposent sur des processus de livraison rapides et fluides. Une DevOps culture ne peut prospérer que dans des environnements où les équipes sont end-to-end responsables de projets logiciels.
Orchestrer le développement du micro-frontend entre plusieurs équipes
Lorsque le développement du micro-frontend est étendu à plusieurs équipes interfonctionnelles, deux problèmes apparaissent : tout d'abord, les équipes commencent à développer leur propre interprétation du paradigme, à faire des choix en matière de framework et de bibliothèque, et à créer leurs propres bibliothèques d'outils et d'assistance. Deuxièmement, les équipes totalement autonomes doivent assumer la responsabilité des fonctionnalités génériques telles que la gestion de l'infrastructure de bas niveau. Il est donc logique d'introduire deux équipes supplémentaires dans une organisation micro-frontend à plusieurs équipes : une équipe d'habilitation et une équipe de plateforme. Ces concepts sont largement adoptés dans les organisations informatiques modernes dotées de systèmes distribués et sont bien documentés dans Team Topologies
Le schéma suivant montre l'équipe d'habilitation fournissant des outils, des bibliothèques, des normes et des tests à trois équipes de micro-frontend. L'équipe de la plateforme fournit une infrastructure, des fonctionnalités d'exécution partagées et des services de domaine à ces trois mêmes équipes de micro-frontend.
L'équipe de la plateforme soutient les équipes du micro-frontend en les libérant du levage de charges lourdes indifférenciées. Ce support peut inclure des services d'infrastructure tels que les temps d'exécution des conteneurs, les pipelines CI/CD, les outils de collaboration et la surveillance. Cependant, la mise en place d'une équipe chargée de la plateforme ne doit pas aboutir à une organisation dans laquelle le développement est dissocié des opérations. Le contraire est vrai : l'équipe de la plateforme propose un produit d'ingénierie, et les équipes du micro-frontend sont propriétaires et responsables de l'exécution de leurs services sur la plateforme.
L'équipe d'habilitation fournit un soutien en se concentrant sur la gouvernance et en garantissant la cohérence entre les équipes du micro-frontend. (L'équipe de la plateforme ne doit pas être impliquée dans cette affaire.) L'équipe d'habilitation gère des ressources partagées telles qu'une bibliothèque d'interface utilisateur et crée des normes telles que le choix du framework, les budgets de performance et les conventions d'interopérabilité. Dans le même temps, il fournit aux nouvelles équipes ou aux nouveaux membres de l'équipe une formation à l'application des normes et des outils tels que définis par la gouvernance.
Déploiement
La clé de voûte de l'autonomie des équipes de micro-frontend est de disposer d'un pipeline automatisé avec un chemin de production indépendant des autres équipes de micro-frontend. Les équipes qui suivent le principe de ne rien partager peuvent mettre en œuvre des pipelines indépendants. Les équipes qui partagent des bibliothèques ou dépendent d'une équipe de plateforme doivent décider comment gérer les dépendances dans les pipelines de déploiement.
En général, chaque pipeline effectue les opérations suivantes :
-
Construit des actifs frontaux
-
Déploie les actifs vers l'hébergement à des fins de consommation
-
Veille à ce que les registres et les caches soient mis à jour afin que les nouvelles versions puissent être livrées aux clients
Les étapes réelles du pipeline varient en fonction de la technologie et de l'approche de composition des pages.
Pour la composition côté client, cela implique de télécharger des ensembles d'applications vers des compartiments d'hébergement et de les distribuer à la consommation via la mise en cache sur un CDN. Les applications qui utilisent la mise en cache du navigateur avec les agents de service doivent également mettre en œuvre des moyens de mettre à jour les caches des agents de service.
Pour la composition côté serveur, cela signifie généralement le déploiement de la nouvelle version du composant serveur et la mise à jour du registre du micro-frontend pour rendre la nouvelle version détectable. Vous pouvez utiliser des modèles de déploiement bleu/vert ou canari pour déployer progressivement de nouvelles versions.
