Configuration de l’équipe de développement d’entreprise pour AEM as a Cloud Service enterprise-setup

Découvrez comment configurer et dimensionner votre équipe de développement d’entreprise et comment AEM (Adobe Experience Manager) as a Cloud Service peut prendre en charge votre processus de développement.

Présentation introduction

Pour prendre en charge les clientes et les clients avec les configurations de développement d’entreprise, AEM as a Cloud Service s’intègre entièrement à Cloud Manager et à ses pipelines CI/CD parfaitement définis conçus spécifiquement pour les besoins. Ces pipelines et services sont créés sur la base des bonnes pratiques, ce qui garantit des tests complets et la plus haute qualité de code.

Prise en charge de Cloud Manager dans la configuration du développement d’équipe d’entreprise cloud-manager

Pour garantir une intégration rapide, Cloud Manager fournit tout ce qui est nécessaire pour commencer à développer des expériences digitales, y compris un référentiel Git pour stocker les personnalisations. Ces personnalisations sont ensuite créées, vérifiées et déployées par Cloud Manager.

Avec Cloud Manager, les équipes de développement peuvent valider fréquemment les modifications sans avoir besoin de l’aide du personnel d’Adobe.

Trois types d’environnements sont disponibles dans Cloud Manager.

Il est possible de déployer le code dans des environnements de développement en utilisant un pipeline hors production. Pour les environnements d’évaluation et de production, qui vont toujours de pair et garantissent ainsi la bonne pratique de validation avant le déploiement en production, un pipeline de production utilise des points de contrôle qualité pour valider le code de l’application et les modifications de configuration.

Le pipeline de production déploie d’abord le code et la configuration dans l’environnement d’évaluation, teste l’application et effectue enfin le déploiement en production.

Un SDK Cloud Service toujours mis à jour avec les dernières améliorations d’AEM as a Cloud Service permet le développement local directement à l’aide du matériel local du développeur. Cette approche permet un développement rapide avec des délais courts. Les développeurs peuvent ainsi rester dans l’environnement local avec lequel ils sont familiarisés, choisir parmi un large éventail d’outils de développement, et accéder à des environnements de développement ou de production lorsqu’ils le jugent approprié.

Cloud Manager prend en charge des configurations multi-équipes flexibles, ajustables en fonction des besoins de l’entreprise. Pour garantir des déploiements stables au sein de plusieurs équipes, le pipeline parfaitement défini de Cloud Manager valide et teste le code de toutes les équipes simultanément. Cette approche permet d’éviter les situations où les modifications d’une équipe affectent la production de toutes les équipes.

Exemple de scénario example-scenario

Chaque entreprise a des exigences différentes, notamment la configuration de l’équipe, les processus et les processus de développement. Adobe utilise la configuration décrite ci-dessous pour plusieurs projets qui fournissent des expériences en plus d’AEM as a Cloud Service.

Par exemple, les applications Adobe Creative Cloud, telles qu’Adobe Photoshop ou Adobe Illustrator, incluent des ressources de contenu telles que des tutoriels, des exemples et des guides. Les applications clientes utilisent le contenu d’AEM as a Cloud Service de manière découplée. Ils effectuent des appels d’API vers le niveau de publication d’AEM Cloud pour récupérer le contenu structuré en tant que flux JSON. En outre, le ​ réseau de diffusion de contenu (CDN) d’AEM as a Cloud Service est utilisé pour diffuser des contenus structurés et non structurés avec des performances optimales.

Les équipes qui contribuent à ce projet suivent le processus suivant.

Chaque équipe utilise son propre workflow de développement et dispose d’un référentiel Git distinct. Un référentiel Git partagé supplémentaire est utilisé pour les projets d’intégration. Ce référentiel Git contient la structure racine du référentiel Git Cloud Manager, y compris la configuration Dispatcher partagée.

L’intégration d’un nouveau projet nécessite une liste dans le fichier de projet Maven Reactor à la racine du référentiel Git partagé. Pour la configuration de Dispatcher, un nouveau fichier de configuration est créé dans le projet Dispatcher. La configuration Dispatcher principale inclut ensuite ce fichier. Chaque équipe est responsable de son propre fichier de configuration Dispatcher. Les modifications apportées au référentiel Git partagé sont rares et ne sont requises que lorsqu’un nouveau projet est intégré. Chaque équipe de projet effectue le travail principal dans son propre référentiel Git.

Le référentiel Git de chaque équipe est configuré à l’aide de l’archétype de projet ​ et suit donc les bonnes pratiques pour configurer les projets AEM. La seule exception est la configuration Dispatcher, qui est effectuée dans le référentiel Git partagé comme indiqué ci-dessus.

Chaque équipe utilise un workflow Git simplifié avec deux + N branches, suivant le modèle de flux Git :

Le développement est effectué dans une branche de fonctionnalité. Lorsque la fonctionnalité arrive à maturité, elle est fusionnée dans la branche de développement. Les fonctionnalités terminées et validées sont sélectionnées à partir de la branche de développement et fusionnées dans la branche stable.

Toutes les modifications sont effectuées par le biais de PR (demandes d’extraction). Les points de contrôle qualité valident automatiquement chaque requête de tirage. Sonar est utilisé pour la vérification de la qualité du code et un ensemble de suites de tests est exécuté pour s’assurer que le nouveau code n’introduit aucune régression.

La configuration du référentiel Git de Cloud Manager comporte deux branches.

Chaque notification push vers le référentiel Git d’une équipe de la branche de développement ou stable déclenche une action GitHub.

Tous les projets appliquent la même configuration pour la branche stable. Une notification push vers la branche stable d’un projet est automatiquement envoyée à la branche stable du référentiel Git Cloud Manager. Une notification push vers la branche stable déclenche le pipeline de production dans Cloud Manager. Chaque notification push d’une équipe vers une branche stable déclenche le pipeline de production. Le déploiement en production est mis à jour si tous les points de contrôle qualité réussissent.

Les envois vers la branche de développement sont gérés différemment. Une notification push vers une branche de développement du référentiel Git d’une équipe déclenche également une action GitHub. Cette action envoie automatiquement le code dans la branche de développement du référentiel Git de Cloud Manager. Cependant, ce code push ne déclenche pas automatiquement le pipeline hors production. Un appel à l’API Cloud Manager le déclenche.

L’exécution du pipeline de production comprend la vérification du code de toutes les équipes via les points de contrôle qualité fournis. Une fois le code déployé dans l’environnement intermédiaire, les tests et les audits sont exécutés afin que tout fonctionne comme prévu. Lorsque tous les points de contrôle sont franchis, les modifications sont déployées en production sans interruption ni temps d’arrêt.

Le SDK d’AEM as a Cloud Service est utilisé pour le développement local. Le SDK permet de configurer un auteur, une publication et un Dispatcher locaux. Ce workflow permet le développement hors ligne et des délais courts. Parfois, seul l’environnement de création est utilisé pour le développement, mais la configuration rapide des environnements de Dispatcher et de publication permet de tout tester localement avant d’effectuer un transfert vers le référentiel Git.

Les membres de chaque équipe consultent généralement le code dans le Git partagé pour obtenir leur propre code de projet. Il n’est pas nécessaire de consulter d’autres projets parce qu’ils sont indépendants.

Cette configuration peut être utilisée comme référence, puis personnalisée en fonction des besoins d’une entreprise. Le concept flexible d’embranchement et de fusion de Git permet de créer des variantes des workflows ci-dessus, personnalisées selon les besoins de chaque équipe. AEM as a Cloud Service prend en charge toutes ces variations sans sacrifier la valeur de base du pipeline parfaitement défini de Cloud Manager.

Considérations relatives à une configuration multi-équipes considerations

Avec le référentiel Git de Cloud Manager et le pipeline de production, le code de production complet passe toujours par tous les points de contrôle qualité, en le traitant comme une seule unité de déploiement. Ainsi, le système de production est toujours disponible sans interruption ni temps d’arrêt.

En revanche, en l’absence d’un tel système, chaque équipe pouvant effectuer un déploiement distinct, il est possible qu’une mise à jour d’une seule équipe entraîne des problèmes de stabilité en production. En outre, il est nécessaire de prévoir une coordination et des temps d’arrêt planifiés pour déployer les mises à jour. Avec un nombre croissant d’équipes, l’effort de coordination devient beaucoup plus complexe et rapidement ingérable.

Si un problème est détecté au niveau des points de contrôle qualité, la production n’est pas affectée, et le problème peut être détecté et corrigé sans que le personnel d’Adobe n’ait à intervenir. Sans AEM as a Cloud Service et sans avoir à toujours tester l’ensemble du déploiement, les déploiements partiels peuvent entraîner des pannes qui nécessitent une demande de restauration ou même une restauration complète à partir d’une sauvegarde. Les tests partiels peuvent également entraîner des problèmes supplémentaires qui doivent être résolus ultérieurement, ce qui nécessite à nouveau la coordination et l’assistance du personnel d’Adobe.