Présentation du CMS Drupal pour l'évènement Drupagora du 9 novembre 2012. Ce diaporama donne les clés d'un démarrage projet réussi, les bonnes pratiques de développement ainsi que les outils et méthodes pour maintenir dans la durée un projet Drupal.

1. Les clés de la réussite d’un projet
Drupal
Marine 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 Drupal
2

3. Pourquoi Drupal est si
particulier
3 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’abstraction
4

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 fortes
5

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

7. La diversité Drupal
 A compléter
7

8. La diversité Drupal
8

9. La diversité Drupal
9

10. La diversité Drupal
10

11. La diversité Drupal
11

12. Les clés d’un départ réussi
12 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
 Contextes
14

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
Drupalien
15

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 Drupal
17

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

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 Drupal
20

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écifiques
21

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éveloppement
23 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éveloppement
26

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 test
27

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
important
28

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éliorer
29

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
production
30

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

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 urgence
32

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 version
33

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ées
34

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 production
35 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ée
36 titre de la présentation

37. merci
37