PHPerformances
Les CMS comme WordPress et Drupal ont de fortes dépendances a leurs bases de données. Ce système permet de configurer énormément de choses depuis l’interface d’administration. C’est un gros plus pour les utilisateurs finaux, cependant c’est un véritable défis pour les développeurs lorsqu’ils sont amenés à travailler en équipe.
Dans cet article je vais expliquer ce que j’ai mis en place pour permettre a notre équipe de travailler sans accrocs (ou presque). À l’aide d’outils, d’une bonne organisation dans le GIT et de quelques commandes, il est possible de se synchroniser et de ne pas avoir de télescopage dans nos développements.
Pour automatiser et faciliter la vie de l’équipe, nous utilisons Wp-CLI et Capistrano avec un plugin wordpress. Il est bien sur possible d’utiliser d’autres outils comme Deployer avec l’équivalent pour les commandes WordPress.
Les exemples dans cet article sont basés sur une structure de projet avec Composer, comme introduit dans l’article précédent. Je vous conseille fortement de le lire avant de continuer celui-ci.
Développement et Infrastructure
Les développements sont faits en local, a l’aide du serveur local de PHP ou d’une CLI comme Symfony CLI et de Docker pour les services.
Pour pouvoir travailler correctement en équipe avec un CMS, il faut une base de données principale de référence. Deux choix sont possible. Soit, elle est en local sur un des postes de développement, soit sur un serveur distant.
Nous avons opté pour mettre en place une version sur un serveur distant ce qui permet de centraliser toutes les configurations.
Gestion des sources
La base d’une bonne organisation dans l’équipe est une bonne gestion des sources. Il y a beaucoup de ressources qui expliquent comment théoriquement un dépôt GIT devrait correctement organisé, par exemple Gitflow, TwGit.
Dans la réalité, c’est souvent plus compliqué. Je suis le premier à penser qu’il faut essayer des choses et trouver la meilleure solution en prenant en compte les retours de l’équipe et la typologie de projet. Nous avons essayé pas mal d’organisations et aujourd’hui elles peuvent être différentes en fonction des projets, et aussi en fonction de l’équipe qui travaille dessus.
Pour WordPress, nous avons opté pour une organisation se rapprochant de GitFlow. Nous avons 2 branches principales, dans cet exemple nous prendrons master et staging.
La branche master va représenter la production et staging l’état le plus avancé de synchronisation des développements. Les développements se font dans « l’idéal » sur des branches de features nommées feat/ma-fonctionalité et sont mergées sur la branche staging via une pull request.
La base de données
Afin de limiter au maximum les erreurs, nous avons opté pour une synchronisation de la base de données uniquement dans le sens « descendant ». C’est-à-dire que nous ne poussons jamais une base de données locale sur le serveur distant, mais nous la récupérons régulièrement.
Ce système permet de faire des resets réguliers de nos versions locales. C’est bien pratique lors de phases de test et permet de « jouer » avec les configurations locales sans polluer la « vraie » base de données.
Les modifications nécessaires de configuration sont donc à effectuer directement sur le serveur distant.
À l’aide d’un outil d’automatisation (dans notre cas Capistrano) nous pouvons rapatrier la base de données avec la commande suivante :
bundle exec cap staging wordpress:db:pullCette commande permet d’automatiser l’export et la récupération de la base de données du serveur distant a l’aide de Wp-CLI et de RSync. Elle lance ensuite la commande d’import de Wp-CLI sur le poste de développement.
Cette commande est très intéressante car elle permet pendant l’import de remplacer automatiquement le nom de domaine et les paths qui sont stockés en base de données.
Le cas particulier d’ACF
Concernant les configurations d’ACF nous utilisons `wpackagist-plugin/acf-extended` permettant (entre autre) la synchronisation des configurations.
Il est donc possible de préparer en local les configurations ACF pour après les versionner dans votre dépôt. C’est extrêmement pratique, car ça permet de travailler a plusieurs sur la configuration de vos customs fields et de merger simplement l’export.
Il faut pour le moment encore forcer la mise à jour via l’import JSON, mais une synchronisation automatique est prévue dans la roadmap du plugin.
Le dossier uploads
Concernant les médias situés dans le dossier uploads il est possible récupérer le contenu a l’aide de commande de type RSync. Le plugin de Capistrano permet de lancer la commande dans les deux sens. C’est-à-dire de récupérer, pousser et même de synchroniser le dossier distant et le dossier local.
Récupération des fichiers distants :
bundle exec cap staging wordpress:uploads:pullEnvoi des fichiers locaux :
bundle exec cap staging wordpress:uploads:pushSynchronisation des deux :
bundle exec cap staging wordpress:uploads:syncLes limites rencontrées
Sur WordPress les limites sont surtout situées dans la corrélation entre certaines configurations et le contenu. L’idéal serait d’avoir un principe d’export de configuration comme avec Drupal, qui permet de versionner tout ce qui concerne la configuration sous forme de fichiers Yaml et d’importer avec une simple commande.