Planète

Du 21 au 25 mars 2017 ont eu lieu les Drupal Developer Days à Séville. Environ 280 personnes y ont participé.

Cela était très sympathique et enrichissant d'être au contact avec la communauté internationale et des nombreux français sur place :).

L'ambiance est bien différente d'une DrupalCon, on est moins noyé dans la masse et il est plus facile d'aborder et discuter avec des personnes « influentes/connues » dans la communauté.

Une année de plus dans l'histoire de l'association vient de se clôturer par cette assemblée générale. Nous étions 14 participants/votants à ce rendez-vous, sur 43 adhérents à jour de cotisation.

Retour sur l'année écoulée

Profitant de nos nouveaux supports de communication, nous avons présenté le bilan de l'année avec le nouveau format de présentation de l'association. Ce format, nouvellement disponible, est à disposition de tous ceux souhaitant présenter l'association ou présenter des sujets liés à Drupal lors de meetups et rencontres, à but Open Source bien entendu.

Les évènements de l'année

Comment ne pas mentionner le Drupalcamp Nantes 2016 ?

• 110 participants
• 3 jours de rencontres
• près de 20 présentations

Le bureau de l'association remercie toute l'équipe bénévole de l'évènement et particulièrement Sébastien Corbin qui a porté ce groupe vers cet évènement.
Le bureau a donc décidé en conséquence de remettre à Sébastien le prix Drupal France 2017 pour le remercier, pour toutes ses actions et le temps qu'il a consacré à Drupal et à la communauté.

A noter que cette année encore, l'association a été présente à d'autres évènements : WordCamp, AgoraCMS, JDLL, Drupagora, OSS Paris, Symfony Live ... Ces types de représentation seront toujours à l'honneur pour l'année à venir et nous en sommes très fiers.

Les évènements de l'association se sont aussi les rencontres locales dans toute la France, par le biais des meetups. Cette année nous avons noté plus de 25 rencontres, 11 drinks, et plusieurs sprints.

Une communauté soudée

L'association et tous les membres du bureau avaient suivi l'évolution du parcours de Cellou Diallo, c'est avec un grand regret que nous le voyons quitter la France, mais gardons en secret espoir qu'il puisse monter à son tour une association Drupal au Sénégal.

La communauté c'est aussi de l'entraide et cette année se sont déroulés plusieurs sprints d'un sprint "premiers patchs". Il y a toujours un bon moment pour commencer à contribuer !
A noter les autres sprints : média et traduction.

Des nouveautés

L'année dernière nous présentions notre nouveau logo, cette année encore nous avons poursuivis nos travaux. En plus des slides nommé, le site a reçu quelques améliorations. Donc le changement de nom de domaine, pour le très officiel drupal.fr.

Innovation aussi que le Grand Sondage Drupal France lancé en fin d'année. Nous remercions toutes les personnes ayant donné de leur temps pour nous aider. Nous avons reçu de nombreuses et qualitatives idées. Nous referons sans doute un sondage de ce type.

Des projets en cours

Il nous reste encore quelques sujets à traiter et des sujets en cours. Nous avons engagé cette année une discussion avec Dries et la Drupal Association à propos des noms de domaines. Nous espérons vous informer de ces avancées le plus tôt possible.

Et pour revenir sur les commissions, un premier groupe a lancé des projets sur la refonte du site drupal.fr, toujours en cours de conception, nous espérons vous dévoiler le plus tôt possible cette nouvelle version, qui proposera, sur un socle Drupal 8, de nouveaux contenus à destination des débutants et de tous ceux qui souhaitent en savoir plus sur Drupal.

Autre travail commencé, celui d'une charte pour l'organisation des meetups. Ce document encore en cours de rédaction à pour but de fédérer l'organisation des meetups en protégeant les organisateurs, les participants et l'association.

Préparons l'année à venir

Après l'heure du bilan, nous avons procédé à l'élection du nouveau bureau de l'association. Plusieurs membres ont décidés de laisser leur place.

Après délibération, voici la composition du nouveau bureau :

• Président : Vincent Maucorps
• Trésorier : Kévin Gautreau
• Vice-trésorière : Anne-Sophie Picot
• Secrétaire : Floris Moriceau
• Vice-secrétaire : Thierry Jarrige

Toute l'équipe du nouveau bureau, remercie très chaleureusement Léon pour son implication et le temps qu'il a offert à l'association.

Un point qui revient souvent lors du développement est la gestion des paramètres de configuration (MySQL par exemple) sur les différents environnements (production, préproduction, local…) et entre différents développeurs d'une même équipe.

Si l’on est tout seul à travailler sur un projet avec un seul environnement (la production) alors la question ne se pose pas, on met les paramètres dans le fichier de configuration (wp-config.php pour wordpress, settings.php pour drupal…) et ça fonctionne.

Le problème du versioning de la configuration

Mais si l’on utilise un système de gestion de version (git avec gitlab / github par exemple) alors cela veut dire que nos identifiants de connexion à la base de données de notre site en production sont stockés sur d’autres serveurs que l’unique sur lequel il devrait être...

Github et Gitlab sont des solutions éprouvées, mais on est jamais à l’abri d’une fuite ou d’un piratage, ou tout bêtement de l’oubli de désactiver l’accès au dépôt à un ancien collaborateur avec qui l’histoire s’est mal terminée et qui a une éthique pro douteuse.

Le problème du travail en équipe

Autre potentiel problème, imaginons une équipe de deux personnes (A et B) qui travaillent en local sur un site en développement.

A travaille sous windows avec wamp, par défaut l’identifiant de connexion à la base de données sous wamp est «root», il n’y a pas de mot de passe.

B travaille sous macos avec mamp, par défaut l’identifiant de connexion à la base de données sous mamp est «root», le mot de passe est lui «root».

On voit vite le jeu que cela va être à chaque commit, A et B s'écrasant mutuellement le fichier de configuration de l’autre.

En plus, notre sysadmin étant moins drôle, il refuse de définir le mot de passe de mysql en production sur «root», encore moins marrant, il refuse de ne pas en définir… Donc on se retrouve avec un troisième jeu d'identifiants que l’on devra (re)mettre à chaque mise à jour du site en production…

Note : évidement utiliser "root" comme idenfiant ou mot de passe, ailleurs qu'en local est évidement à éviter impérativement ! Il faut créer un utilisateur qui n'a la main que sur la (ou les) base(s) de données du site. Bonne pratique à utiliser aussi en local, même si c'est moins «dangereux».

Le problème des environnements

En plus des différences d’identifiants de base de données, il existe souvent d’autres divergences entre deux environnements d’un même site.

Généralement notre site ne fonctionne pas exactement pareil en local, sur notre serveur de développement, sur notre préproduction et sur notre serveur de production.

Par exemple, si l'on travail sur un site d'e-commerce, on aura pas forcément la même brique de paiement, ou il faudra lui passer des paramètres différents pour activer le mode test.

Autres exemples : l'affichage des messages d'erreurs, la désactivation du cache en local pour éviter d’avoir à le vider manuellement à chaque modification...

Enfin, On peut (doit ?) aussi désactiver ou intercepter les envois de mail sur les autres serveurs que celui de production.

Les solutions

Avertissement

Les solutions décrites ici sont des solutions que j'ai trouvées, expérimentées, modifiées... Je n'en réclame ni la paternité ni leur supériorité sur une autre solution, d'ailleurs, si vous faites autrement, n'hésitez-pas à en parler.

Se baser sur le HTTP_HOST

Un première possibilité serait, au sein même du fichier de configuration, d’ajouter des conditions en fonction de l’url par exemple.

Ainsi si l’url du site est “monsite.dev” on sait que l’on est en local, si c’est "monsite.com" alors on est en production.

Exemple de code :

//Paramètres par défaut = production
$databases = array (
  'default' => 
  array (
    'default' => 
    array (
      'database' => 'monsite.com',
      'username' => 'monsite',
      'password' => 'loremipsum',
      'host' => 'localhost',
      'port' => '',
      'driver' => 'mysql',
      'prefix' => '',
    ),
  ),
);
$conf['site_env'] = 'PROD';

// Si l'url se termine par .mapreprod.monentreprise.com"
// par exemple monsite.mapreprod.monentreprise.com
// alors on est en préproduction
if(preg_match('`\.mapreprod.monentreprise.com$`',$_SERVER['HTTP_HOST'])) {
  $conf['site_env'] = 'PREPROD';
  $databases['default']['default']['database'] = 'monsite.com';
  $databases['default']['default']['username'] = 'monsite_preprod';
  $databases['default']['default']['password'] = '123456789';
}

// Si l'url se termine par .dev"
// par exemple monsite.dev
// alors on est en local
if(preg_match('`\.dev$`',$_SERVER['HTTP_HOST'])) {
  $conf['site_env'] = 'DEV';
  $conf['theme_debug'] = true;
  $conf['hybridauth_debug'] = 1;
  $databases['default']['default']['database'] = 'monsite.com';
  $databases['default']['default']['username'] = 'root';
  $databases['default']['default']['password'] = 'mysql';
}

Par défaut, je définis les paramètres de production de mon site, ensuite, je me base sur le HTTP_HOST (l'adresse de notre site) pour déterminer l'environnement (ici préproduction ou local).

Et en fonction j'ajuste à la fois ma configuration mysql ainsi que différents paramètres de configuration pour mon site.

À noter, je définis aussi une variable qui contient l'environnement dans lequel je suis (ici : $conf['site_env']) ce qui peut être utile dans notre code pour savoir si l'on doit par exemple envoyer mail, sms, notification...

Quelques inconvénients à cette solution :

• Les identifiants de notre prod et de nos autres environnement sont versionnés.
• Si un nouveau développeur arrive sur le projet et qu'il a un fonctionnement différent, alors le fichier de config sera sans cesse écrasé.

La config différentielle dans un fichier non versionné

C'est la solution que j'utilise maintenant, on se base non plus sur l'url mais sur un fichier supplémentaire, qui défini la configuration spécifique et écrase potentiellement la configuration selon l'environnement.

Exemple :

Le fichier de configuration commun et versionné :

// La configuration de la base de donnée n'est pas définie car elle
// spécifique à chaque environnement
 $databases = array();

// On inclue le fichier settings.local.php s'il existe
if (file_exists(__DIR__ . '/settings.local.php')) {
  include __DIR__ . '/settings.local.php';
}

Le fichier de configuration settings.local.php en production (lui non versionné) :

<?php
  $conf['site_env'] = 'PROD';
  $databases['default']['default']['database'] = 'monsite.com';
  $databases['default']['default']['username'] = 'monsite';
  $databases['default']['default']['password'] = 'loremipsum';

Le fichier de configuration settings.local.php en local (lui non versionné non plus) :

<?php
  $conf['site_env'] = 'DEV';
  $conf['theme_debug'] = true;
  $conf['hybridauth_debug'] = 1;
  $databases['default']['default']['database'] = 'monsite.com';
  $databases['default']['default']['username'] = 'root';
  $databases['default']['default']['password'] = 'mysql';

Les fichiers settings.local.php ne sont pas versionnés grâce au fichier .gitignore et cette ligne (ici pour un drupal, mais à adapter en fonction de votre configuration) :

web/sites/*/settings.local.php

Avantages de cette solution :

• Une fois configuré, le fichier de configuration de base ne bouge pas, il contient la configuration commune du site.
• Pas de risque de s'écraser mutuellement la configuration entre développeurs.
• Les fichiers settings.local.php ne sont pas versionné et donc aucun identifiant ne se retrouve sur github ou gitlab.

Je vois un inconvénient principal : quand un nouveau développeur arrive sur le projet, il faut qu'il comprenne cette organisation, c'est pourquoi généralement je crée un fichier settings.local.example.php qui lui est versionné et j'ajoute les lignes suivantes au readme du projet :

Pour ne pas risquer d'altérer la configuration de la base de données en production,
les identifiants de base de données doivent être renseignés dans un fichier `sites/default/settings.local.php`,
vous pouvez copier le fichier `sites/default/settings.local.example.php` en le renommant pour avoir un exemple
de fichier local.

Le fichier settings.php ne doit jamais être modifié directement, sauf cas très particulier.

Conclusion

La solution décrite juste au-dessus me convient bien, et semble bien marcher aussi pour les personnes avec qui je travaille. Néanmoins, ça n'est évidemment pas la solution universelle et vous avez peut-être mieux, si c'est le cas, n'hésitez-pas à venir en discuter dans les commentaires !