Cette page fournit d’autres détails qui précisent et/ou enrichissent les documents et les principes couverts dans la section Gestion des projets : liste de contrôle des meilleures pratiques.
Les listes de cette sous-section ne sont pas complètes, mais établies comme une introduction.
Lors de la mise en oeuvre de l'AEM (en particulier pour la première fois), vous devrez examiner les capacités et workflows d'AEM pour vous assurer des zones que vous souhaitez ou dont vous avez besoin.
Tenez compte des fonctions d’AEM que vous utiliserez et de l’impact sur votre travail de conception, par exemple :
En outre, consultez les notes de mise à jour pour les différentes versions d’AEM, afin de savoir quand de nouvelles fonctions ont été ajoutées.
AEM peut être intégré à d’autres produits Adobe et/ou services tiers. Ceux-ci peuvent augmenter la puissance et les fonctionnalités à votre disposition.
Voir Intégration de solutions pour obtenir des informations complètes.
Il est important de déterminer si vous voulez :
Lors du passage d’une version précédente à la version actuelle, il y a deux possibilités :
Comme dans tout projet, il est essentiel d’établir des règles de base dès que possible. Celles-ci comprennent :
Ces points sont génériques, la liste de vérification des meilleures pratiques traite des détails relatifs à l'AEM.
Rôles
Ils doivent être définis clairement et connus de toutes les personnes impliquées dans le projet. En outre, il est recommandé d’insister sur les :
Responsabilités
Implication
En impliquant dès que possible les parties concernées, vous pouvez les inciter à devenir des parties prenantes dans le projet, et améliorer ainsi leur engagement dans sa réussite.
Voies de communication
Processus
Les processus à définir varient selon votre projet particulier. Là encore, essayez de rester simple en considérant :
Outils de suivi
Il existe de nombreux outils pour le suivi des informations sur les bogues, les tâches et d’autres aspects de votre projet. Voir Présentation des outils potentiels pour plus de détails.
Portée
Définissez de façon précise ce qui doit être traité par le projet à différents niveaux :
Création de rapports
Définissez clairement les informations que vous inclurez dans les rapports, leur format, leur fréquence et leurs destinataires.
Terminologie
Hypothèses
Ces informations peuvent être définies dans un manuel de projet ; l’utilisation d’un wiki peut également vous assurer que les modifications en cours sont gérées efficacement. Où qu'ils soient définis, les principaux facteurs sont les suivants :
Les organisations utilisent des indicateurs de performances clés (IPC) pour évaluer leur capacité à atteindre des cibles. Ces indicateurs sont des valeurs mesurables qui peuvent être utilisées pour montrer si les objectifs spécifiés sont satisfaits.
Ces indicateurs peuvent être :
des indicateurs métier :
Performances:
Certains indicateurs, mais pas tous, peuvent reposer sur les mesures cibles que vous identifiez et définissez.
Les mesures sont utilisées pour définir des mesures quantitatives de la qualité de votre site web. Elles sont essentiellement une définition des objectifs de performance à atteindre et peuvent être utilisées pour définir vos IPC (indicateurs de performances clés).
De nombreuses mesures peuvent être définies, mais celles que vous définissez sont souvent liées à vos objectifs en matière de performance et d’accès simultané. En particulier, des facteurs qu’il peut s’avérer difficile de mesurer et qui sont souvent évalués d’une façon émotionnelle :
« Notre site web est beaucoup trop lent aujourd’hui. » : à partir de quel moment le site web est-il lent ?
« Tout s’arrête lorsque mon collègue ouvre une session. » : combien d’utilisateurs simultanés le système peut-il prendre en charge ?
« Lorsque j’effectue une recherche, le système s’arrête. » : quels sont les types de requêtes de recherche qui affectent le système ?
« Le téléchargement du fichier prend une éternité. » : quelles sont les durées de téléchargement acceptables (avec des conditions normales de réseau) ?
Les mesures cibles sont définies au début d’un projet de façon à :
Comme toujours, les mesures cibles doivent être définies avec soin :
Au cours du développement du projet, elles peuvent être mises à jour et ajustées selon les besoins. Une fois le projet mis en œuvre, elles peuvent vous aider à contrôler votre installation et surveiller/maintenir les niveaux de service requis pour le fonctionnement courant.
Si elles sont correctement utilisées, ces mesures peuvent fournir un outil utile. En revanche, si elles sont utilisées de manière irresponsable, elles peuvent constituer une distraction et une perte de temps. Comme toujours, vous devez comprendre ce que vous mesurez, ainsi que comment et pourquoi vous le mesurez.
Cette section aborde les principes de base et les problèmes à prendre en compte. Chaque installation est différente, c’est pourquoi les valeurs à mesurer diffèrent.
Toutes les mesures sont, d’une manière ou d’une autre, affectées par la conception du projet. À l’inverse, le meilleur moyen de résoudre de nombreux problèmes consiste à modifier la conception.
Par conséquent, il est préférable de définir les mesures cibles avant de décider de la conception. Cela permet d’optimiser votre conception en fonction de ces facteurs. Une fois le projet développé, il sera difficile de modifier les principes de conception de base.
Lorsque vous créez la structure du site web, suivez la structure recommandée pour les sites web AEM. Veillez à bien comprendre les problèmes et/ou les principes suivants :
Si vous estimez que votre conception ne suit pas les consignes ou si vous n’êtes pas sûr de certaines des implications, clarifiez ces questions avant de débuter la phase de programmation ou d’ajouter le contenu.
Pour définir ou évaluer l’infrastructure, il est utile de définir des valeurs cibles telles que :
En fonction de votre situation et de la signification stratégique du site web, cela permet d’évaluer et de sélectionner votre infrastructure :
Il existe plusieurs facteurs de performance pouvant être évalués :
Temps de réponse pour les pages individuelles, en tenant compte des éléments suivants :
Temps de réponse pour les requêtes de recherche
Cette section peut être lue conjointement avec Optimisation des performances qui développe les détails techniques de la mesure réelle des performances.
Le temps que met votre site web pour répondre aux requêtes des visiteurs constitue l’un des problèmes majeurs.
Bien que cette valeur varie pour chaque demande, une valeur cible moyenne peut être définie. Une fois que cette valeur se révèle à la fois réalisable et gérable, elle peut être utilisée pour surveiller les performances du site web et indiquer le développement d’éventuels problèmes.
Cibles divergentes sur les environnements de création et de publication
Les temps de réponse que vous ciblerez seront différents sur les environnements de création et de publication, reflétant l’audience cible :
Environnement de création
Cet environnement est utilisé par les auteurs qui créent et mettent à jour du contenu ; il doit donc :
Environnement de publication
Cet environnement intègre le contenu que vous mettez à la disposition de vos utilisateurs :
La vitesse reste essentielle, mais il est souvent plus lent qu’un environnement de création.
Des mécanismes supplémentaires d’amélioration des performances sont souvent appliqués :
Comment puis-je décider des temps de réponse (moyens) atteignables ? Il s’agit souvent d’une question d’expérience :
Toutefois, dans des conditions contrôlées, les consignes suivantes peuvent être appliquées :
Les chiffres ci-dessus supposent les conditions suivantes :
Il existe plusieurs méthodes pour surveiller les temps de réponse :
Surveillance des temps de réponse avec le fichier request.log d’AEM
Le journal des requêtes est un point de départ intéressant pour l’analyse de performances. Entre autres informations, vous pouvez l’utiliser pour afficher les temps de réponse des requêtes isolées. Voir Optimisation des performances pour plus d’informations.
Surveillance des temps de réponse à l’aide des commentaires HTML
Les commentaires HTML peuvent être utilisés pour inclure des informations sur le temps de réponse dans la source de chaque page :
</body> </html>v <-- Page took 58 milliseconds to be rendered by the server --> Response times for search requests
Les requêtes de recherche peuvent avoir un impact important sur votre site web, en termes de :
temps de réponse de la recherche ;
impact sur les performances générales.
La définition des cibles pour les requêtes de recherche est, là encore, une question d’expérience en fonction :
Elles doivent être planifiées et intégrées dès le tout début du projet. Les mécanismes disponibles pour la surveillance incluent :
Surveillance des temps de réponse de recherche avec le fichier request.log d’AEM
Là encore, le fichier request.log peut être utilisé pour surveiller les temps de réponse des requêtes de recherche ; voir Optimisation des performances pour plus d’informations.
Mécanismes programmés pour mesurer les temps de réponse des recherches
Pour personnaliser les informations que vous collectez sur les requêtes de recherche et leur performance, il est recommandé d’inclure la collecte d’informations dans le code source du projet ; voir Optimisation des performances pour plus d’informations.
Votre site web sera disponible pour un certain nombre d’utilisateurs/de visiteurs, dans les environnements de création et de publication. Les numéros sont souvent plus élevés que ceux utilisés lors du test, mais ils sont également fluctuants et difficiles à prévoir. Votre site web doit avoir été conçu pour qu’un nombre moyen d’utilisateurs/de visiteurs simultanés ne remarquent pas d’impact négatif sur les performances. Là encore, le fichier request.log
peut être utilisé pour effectuer des tests d’accès simultané ; voir Optimisation des performances pour plus d’informations.
Les cibles pour le nombre d’utilisateurs simultanés dépendent du type d’environnement :
Environnement de création
Environnement de publication
Avant de discuter des mesures relatives, une définition rapide des termes :
Volume
Capacité
Capacité et volume
Quoi / Où | Capacité | Volume |
---|---|---|
Client | Puissance de calcul de l’ordinateur de l’utilisateur. | Complexité de la mise en page. |
Réseau | Bande passante réseau. | Taille de la page (code, images, etc.). |
Cache du répartiteur | Mémoire serveur du serveur Web (mémoire principale et disque dur). | Serveur Web (mémoire principale et disque dur). Nombre et taille des pages mises en cache. |
Cache de sortie | Mémoire serveur du serveur AEM (mémoire principale et disque dur). | Nombre et taille des pages du cache de sortie, nombre de dépendances par page. Le cache du Dispatcher réduit ce volume. |
Serveur web | Puissance de calcul du serveur Web. | Nombre de demandes. La mise en cache réduit ce volume. |
Template | Puissance de calcul du serveur Web. | Complexité des modèles. |
Référentiel | Performances du référentiel. | Nombre de pages chargées à partir du référentiel. |
Les sections précédentes présentent les principales mesures à définir.
Selon vos besoins spécifiques, il peut être utile de définir des mesures supplémentaires de façon isolée ou en prenant en compte les classifications ci-dessus.
Cependant, il est préférable de garder un ensemble réduit de mesures essentielles précises qui fonctionnent de manière simple et fiable, plutôt que de tenter de mesurer et de définir chaque aspect de votre site web. De par sa nature, votre site web commencera à changer et à évoluer dès qu’il sera remis à vos utilisateurs.
La sécurité est cruciale et présente un défi toujours plus grand. Elle doit être considérée et planifiée dès les premières étapes de votre projet.
La liste de contrôle de sécurité décrit les mesures à prendre pour s’assurer que votre installation d’AEM est sécurisée lors de son déploiement. D'autres aspects de la sécurité sont couverts par Sécurité (lors de son développement) et Administration utilisateur et sécurité.
Notez les points suivants :
Pour une nouvelle implémentation d’un projet AEM standard, vous devrez tenir compte des tâches comme les suivantes :
Pour tous les aspects, il est recommandé d’utiliser une approche itérative :
Divisez le lancement du projet en prélancement(s) (disponibilité réduite et itérations multiples) et en lancement complet (pleine disponibilité, complètement activé) afin de permettre l’ajustement, l’optimisation et la formation des utilisateurs dans des conditions réalistes au sein de l’environnement de production.
Voir la liste de contrôle de projet pour consulter des exemples de tâches que vous devez effectuer (ou évaluer) pendant le cycle de vie de votre projet.
Voici quelques points à noter pour chaque catégorie :
Développement
Définissez tout d’abord l’architecture de base.
Utilisez plusieurs itérations (sprints) pour le développement :
Planifiez l’éventualité d’une mise à jour de la version d’AEM disponible au cours du projet.
Planifiez les tests et l’optimisation pendant les sprints.
Planifiez les phases de stabilisation et d’optimisation.
Créez un journal des éléments à planifier pour les versions futures.
Planifiez la participation des partenaires et le transfert associé.
Infrastructure
Définissez tout d’abord l’architecture de base :
Utilisez plusieurs itérations. Pour le premier sprint et la configuration initiale, préparez les événements suivants :
Planifiez plusieurs tests de charge.
Planifiez les tests et l’optimisation pendant les sprints.
Planifiez une phase de stabilisation et d’optimisation.
Déployez sur l’environnement de production dès que possible (laissez l’équipe des opérations installer le système pour acquérir l’expérience).
Utilisez dès que possible des utilisateurs nommés et des rôles définis.
Planifiez la formation (par exemple, la formation des administrateurs).
Planifiez le transfert à l’équipe des opérations.
Contenu
Selon la liste de tâches obtenue, vous pouvez établir des estimations initiales de temps et d’efforts pour les définitions (de haut niveau) des tâches. Celles-ci doivent inclure une indication de qui, du client ou du partenaire, fera quoi et à quel moment.
La liste suivante présente des approximations standard et des corrélations entre les efforts nécessaires, et donc les coûts :
Ces valeurs peuvent uniquement être utilisées pour les estimations initiales. Un développeur AEM expérimenté doit effectuer une analyse détaillée.
Phase | Effort |
---|---|
Développement | Une estimation approximative de 2 à 4 heures pour chaque noeud de composant couvrira toutes les exigences de développement. |
Test des développeurs | 15 % du développement |
Suivi | 10 % du développement |
Documentation | 15 % du développement |
Documentation JavaDoc | 10 % du développement |
Correction de bogues | 15 % du développement |
Gestion de projets | 20 % des coûts du projet pour la gestion et la gouvernance continues du projet |
La planification détaillée peut ensuite associer les ressources disponibles ou requises aux échéances et aux coûts.
L’architecture de référence est fournie afin de fournir une solution de modèle pour l’architecture d’AEM. L’architecture de référence répond aux problèmes généralement rencontrés par les systèmes d’entreprise, y compris le dimensionnement, la fiabilité et la sécurité.
Les mesures de site suivantes doivent être définies :
Classification | Définition |
---|---|
Nombre de sites Internet | |
Nombre de sites intranet | |
Nombre de bases de code (par exemple, si Internet et intranet diffèrent) | |
Nombre de pages individuelles | |
Nombre de visites du site / jour | |
Nombre de vues de page / jour | |
Volume (en Go) du transfert de données/jour | |
Nombre d’utilisateurs simultanés (groupe d’utilisateurs fermé) | |
Nombre de visiteurs simultanés (publication) | |
Nombre d'auteurs simultanés | |
Nombre d'auteurs enregistrés | |
Nombre d'activations de page / jour ouvrable | |
Nombre d’activations de page pendant le déploiement |
La liste suivante est fournie pour vous informer des outils qui peuvent être utilisés. Elle a été établie pour servir d’introduction, ne constitue pas une liste exhaustive de recommandations et ne devrait certainement pas vous dissuader d’utiliser d’autres outils que vous pourriez préférer.
Produit | Description |
AEM | aem fournit une gamme de mécanismes pour vous aider à surveiller, tester, rechercher et déboguer votre application ; y compris : |
Selenium | Seleniumis est un outil de test Open Source. Les tests s’exécutent directement dans le navigateur en émulant la façon dont les utilisateurs travaillent. |
Microsoft Project | Outil de gestion de projet couramment utilisé. |
Jira | Jirais est un outil Open Source pour le suivi et la gestion des détails de vos bogues logiciels. Des workflows peuvent être imposés sur les détails des bogues selon vos besoins. |
Git | Gitis est un logiciel de contrôle de révision. |
Eclipse | Eclipse est un IDE Open Source, composé de divers projets. Ils sont concentrés sur la création d’une plate-forme de développement ouverte, composée de structures extensibles, d’outils et de runtimes pour la conception, le déploiement et la gestion des logiciels tout au long du cycle de vie. Voir Comment développer des projets AEM à l’aide d’Eclipse pour plus d’informations. |
IntelliJ | Un IDE professionnel (et donc susceptible de supporter les coûts de licence) offrant une gamme complète de fonctionnalités. Voir Comment développer des projets AEM à l'aide d'IntelliJ IDEA pour plus d'informations. |
Maven | Mavenis est un outil de gestion de projet logiciel et de compréhension qui peut gérer le processus de construction d'un projet (logiciel et documentation). |
En outre, les sections ci-après sont particulièrement intéressantes :
Adobe propose d’autres meilleures pratiques pour toutes les phases et tous les publics :