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