Drupagora - Les clés de la réussite d'un projet Drupal

1. Les clés de la réussite d’un projetDrupalMarine Soroko, Quentin Delance

2. Sommaire partie 1 Pourquoi Drupal est particulier partie 2 Les clés d’un démarrage projet réussi partie 3 Les bonnes pratiques de développement partie 4 Les outils et méthodes pour maintenir dans la durée un projet Drupal2

3. Pourquoi Drupal est si particulier3 titre de la présentation

4. Un outil très riche…  La force de la communauté et la richesse modulaire  Des besoins de base non couverts par le core  Un outil extensible avec un certain niveau d’abstraction4

5. Des méthodes de développement particulières  Utilisation de l’API et de hooks  Potentiellement très peu de développement  Des contraintes structurelles fortes5

6. Une multitude de projets possibles  Internet  Communautaires  Extranet  Métier  Ecommerce  …6

7. La diversité Drupal  A compléter7

8. La diversité Drupal8

12. Les clés d’un départ réussi12 titre de la présentation

13. Les règles d’or de la conception Drupal 4 points clefs 1 Connaître Drupal 2 Eviter l’usine à gaz 3 Penser l’architecture 4 Utiliser la communauté13

14. Vocabulaire et contraintes à connaître  Entités  Types de contenu  Blocs  Vues  Utilisateurs  Menus  Taxonomies  Panels  Contextes14

15. Des spécifications made in Drupal Penser les spécifications avec les contraintes et limites des modules utilisés Définir tous les types de contenu Définir toutes les vues Définir les méthodes de gestion d’arborescence Préciser les adaptations BO Adapter la gestion d’utilisateurs et workflows au fonctionnement Drupalien15

16.  Axure or not ?16

17. Rester sur du standard  L’extensibilité permet d’utiliser Drupal comme CMF  Plus puissant que d’autres CMS  Pas un « vrai » framework au même titre que Zend ou Symfony   Nécessité de s’adapter à la conception et au fonctionnement de Drupal17

18. Choix des modules 1/2  + de 5 000 modules  Attention à la qualité  Redondance des fonctionnalités18

19. Choix des modules 2/2  Popularité  Dernières mises à jour et leurs fréquences  Quantité des « issues »19

20. Choisir la bonne version de Drupal  2 versions Drupal supportées à un instant t  API incompatibles entre versions majeures  Ne pas adopter trop tôt une nouvelle version Drupal20

21. Les indicateurs de la charge de développement  Combien de gabarits  Combien de vues  Combien de panels / context  Quels modules particuliers  Quels développements spécifiques21

22. Les points de vigilance graphique et ergonomiques  Une structuration particulière du HTML  Des vues contraintes  Des contextes particuliers  Une ergonomie FO pas toujours adaptée  Optimiser le BO ?22

23. Les bonnes pratiques de développement23 titre de la présentation

24. La bonne composition d’une équipe  … selon la complexité du projet  Développeurs Drupal  Thémeur  Profils fonctionnels pour les specs/tests d’intégration  Profil architecte sur sujets cache/perf/scripts/https  Attention à la courbe d’apprentissage Drupal !24

25. Les règles d’or du développement  Ne pas toucher au core  Respecter les normes de codage Drupal  Requêtes et fonctionnalités hors du template  Distinguer le code custom des modules communautaires  Limiter les modification des modules communautaires – Suivre les patchs créés ou appliqués – Soumettre les patchs créés à la communauté (« patch management »)  Utiliser les outils disponibles (Coder, Security Review, Acquia Insight) pour s’améliorer  …25

26. Une répartition des tâches avec peu de développement  Paramétrage & configuration  Intégration CSS  Tests  Et un peu de développement26

27. Le bon environnement de développement  SVN / Git  Outil de développement bien configuré  Plateformes : Prod / Pré-prod / Test / Dév  Déploiement  Stratégie de test27

28. La méthodologie de tests  Outillage qualité et patch management  Tests unitaires avec SimpleTest ?  Tests d’intégration manuels ?  Jeu de données (BD + « files ») de référence  Les outils de tests avec Drupal ne sont pas simples à exploiter. Les tests avec Drupal sont un point de charge important28

29. Optimiser la sécurité et les performances  Activer les caches Drupal  Agréger les contenus statiques (CSS/JS) et toutes les autres bonnes patiques Web (sprites, tuner BD, …)  Ne pas logger en base de données  Déporter le search sur un composant externe Apache Solr  Mettre en place reverse proxy cache Varnish  Mettre en place APC  Faire des tests de performance(Jmeter)  Utiliser les nombreux outils disponibles (Yslow, Pagespeed, http://webpagetest.com) pour s’améliorer29

30. Mettre en place la bonne architecture  Architecture LAMP  A compléter avec Varnish voire Memcache (perf) ou Solr (recherche)  Intégrer la stratégie de cache à la conception  S’assurer l’hébergeur maîtrise le web et LAMP en particulier  Mettre en place le bon nombre de plateformes tôt dans le projet  Rapprocher l’environnement de développement sur celui de production30

31. Les outils et méthodes pour maintenir dans la durée31

32. S’assurer du bon fonctionnement  Vérifier les logs  Mettre en place le monitoring de l’ensemble de l’architecture  Suivre les mises à jour des modules et alertes de sécurité  Disposer d’une procédure de livraison en urgence32

33. Stockage des données Drupal BizTalk Server Code Base de données « files »  Drupal stocke dans une même base de données le contenu et la configuration   Complexifie les montées en version33

34. Gérer les montées de version 1/2  Impossible de restaurer la base de données d’un environnement à l’autre Dev Content Config Content Config test v2 test v2 Content Config Content Config prod v1 Prod prod v2   Les montées en version doivent se faire sans livrer la base de données34

35. Gérer les montées de version 2/2  Implémenter les modifications de configuration via code  Exporter les objets (Views, Panels etc) pour les réimporter via l’API Drupal  Activer les changements via hook_update lors du déploiement  Possibilité de packager des fonctionnalités via module Features   Processus délicat à valider avant d’arriver en production35 titre de la présentation

36. Industrialiser les livraisons  Utiliser drush (Drupal Shell), l’outil en ligne de commande  Fournir script d’installation (appelant Drush…)  Valider les montées en version via le nombre de plateformes adéquat  Il faut être en capacité de relivrer vite de manière sécurisée36 titre de la présentation

37. merci37