Suite à mon article sur le workflow git, j’ai pas mal de gens qui m’ont demandés comment on gère la partie dev-staging-prod. 

C’est après quelques jours de réflexion et de tests que vous avons trouvé la solution la plus simple et, selon nous, la plus propre. Evidemment pour que cette solution fonctionne il faut un certain prérequis primordial et une équipe discipliné. 

Pour commencer, chaque projet embarque deux modules nécessaires à notre worflow. Vous les connaissez déjà sûrement, c’est Features & Strongram.

Features permet de compiler des fonctionnalités en un module. Ca a le gros avantage d’avoir beaucoup de configuration (CCK, Views, etc...) en un seul module. Bien évidemment les tiers partis doivent le gérer aussi. 

Strongram quant à lui permet d’overrider les valeurs par défaut d’un module ou de Drupal, pratique quand on souhaite faire un fichier de configuration à exporter sur de multiples serveurs.

Maintenant je vais vous expliquer en détail les différents stages de développement que nous avons et ce que nous avons mis en place.

Dev

L’environnement de développement est sur le proste du développeur. Chaqu’un possède un ordinateur avec un environnement AMP (Apache-MySQL-PHP) configuré au plus proche voir à l’identique de la configuration de production. 

Chaque développeur peut (c’est pas une obligation) à tout moment récupérer une sauvegarde de la base de donnée veille d’au minimum 24 heures sur un FTP distant.

Comme expliqué sur mon précédent article, chaque développeur crée un nouvelle branche (via Git forcément) avec son fix et bosse dessus et test sur son poste local. Une fois le fixé testé et fonctionnel sur son poste le développeur merge sa branche avec la branch development et push le tout repository Beanstalk qui lui aura la tâche de faire un déploiement automatique à chaque push.  

Staging

Quand le développeur merge sa branche avec la branch development et qu’il push, il pourra retrouver après quelques instants ses modifications sur le serveur staging ou preprod. Ce serveur a la particularité, d’être mise à jour régulièrement depuis la serveur de production (base de donnée et fichiers).

Une fois le fix arrivé sur le staging, le développeur vient tester son fix sur des données récentes et si tout est ok, il en fait par au client (souvent au travers d’un ticket ou par e-mail). Le client constate et donne son approbation pour la mise en production ou pas.

Prod

Pour la mise en production j’avoue m’être inspiré de ce qu’il se fait un peu chez Facebook, mais forcément à la taille de notre équipe (3 développeurs).

D'abord nous avons décidé, selon le projet, de faire une mise en production toutes les semaines ou tous les mois, de préférence on va le faire un mercredi après-midi.

Comme je l’avais dit dans mon précédent article, on utilise Beanstalk comme repository central mais surtout pour la function de déploiement. L’avantage, c’est qu’il est également possible d’appeler ce qu’on appel un Web Hook et les développeurs Drupal connaissent très bien ce qu’est un hook, du moins j’espère pour eux.

En bref, avant le déploiement et après le déploiement, Beanstalks donne la possibilité d’accéder à une url avec quelques informations. Nous avons donc développé un outil interne qui permet de faire quelques actions avant la mise en production, dans notre cas cela se déroule comme ceci : 

• Site offline
• Sauvegarde de la base de donnée

Une fois ces deux actions réalisées, le déploiement à lieu, c’est à dire que Beanstalks commence à envoyer les fichiers. Une fois les fichiers transférés, Beanstalk fait appel à une nouvelle url qui annonce le déploiement des fichiers. Toujours grâce à notre outil, celui-ci va faire appel au fichier update.php et mettre à jour le site.

Faut savoir que dans notre cas, nous avons quasiment/voir pas du tout aucune configuration à faire, car avec l’aide de Features + Strongram et du hook_update_N nous faisons la mise en production facilement. 

Durant la mise en production, tous les développeurs se retrouvent sur un chat commun (notre équipe est délocalisé, différents pays etc..). Et on suit la mise en production, on check le log d’erreur et en cas de problème, on revient à une version antérieur du site (donc déploiement d’une version du site antérieur, notre outils comprend si un déploiement est un rollback ou pas).

Conclusion

Notre workflow a plusieurs avantages à mon sens, le premier c’est qu’il permet un déploiement sur des serveurs mutualisé, le second c'est que, je pense, chaque déploiement doit avoir un historique et avoir la possibilité de revenir en arrière le plus facilement possible. D'ailleurs, une fois Beanstalk bien configuré et mis en place, la mise en production ne dure que 30 minutes au plus long.

A mon sens l’inconvénient à cette solution est le fait qu’il faut relativement être stricte dans ce que nous codons, et l’usage de Features (qui n’est absolument pas un mal) et Strongram. Et peut-être, pour les mauvaises langues, d’être dépendant d’un service comme Beanstalk, néanmoins, ce dernier peut facilement être remplacer par un système comme Capistrano. 

D'ailleurs, nous sommes entrain de travailler sur un système d'intégration continue avec Drupal sur notre plateforme de Staging. Pour commencer, on lancera les tests chaque nuit et après on espère le faire après chaque push avec un rapport des résultat des test (un peu comme le pifr sur Drupal). Jusqu'à maintenant nous ne faisions pas beaucoup de test dans nos développements, mais l'équipe semble motivée à faire ça. 

Vous avez des questions, suggestions, expériences à partager ?