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

9.
La diversité Drupal9

10.
La diversité Drupal10

11.
La diversité Drupal11

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