• A la une
  • Catégories
  • Dossiers
  • Rédacteurs
  • +

Aujourd'hui sur le Blog du Webdesign, découvrez comment mettre votre site wordpress en production simplement grâce à Git.

Un des problèmes que je vois à travailler avec Wordpress est qu'il n'est pas simple de travailler avec Git. Là la plupart des applications web en python, nodejs ou ruby se déploierons très simplement avec des outils comme Capistrano, la solution de préférence pour Wordpress sera le FTP.

Pourquoi préférer un déploiement par Git à un déploiement par FTP

Pour ceux qui ne connaissent pas Git, allez lire avant toutes choses cet article: Git : Présentation d'un Programme de Versioning Pratique.

avec Git il suffit d'une simple ligne pour passer en production (git push origin production), le faire par FTP impliquera de glisser déposer les fichiers modifiés dans les bons dossiers. Avec git, le risque d'erreur est très réduit, avec FTP, nous pouvons très bien oublier un fichier, ou faire une erreur de manipulation dans notre glissé déposé.

De plus, en cas d'un bug important dans la nouvelle version, Git permet de très vite annuler un changement, ce qui est pratiquement impossible dans un déploiement par FTP.

Enfin, et ce point est crucial pour toute équipe de plus de deux personnes, il est possible avec Git de travailler sur les mêmes fichiers sans pour autant que l'un des membres de l'équipe perde son travail lors du passage en production.

Toutes ces difficultés de productions (passage en prod et travail en équipe) font que la plupart du temps, l'édition de site WordPress se fait "à la cowboy" directement sur le FTP du site en production, sans passer par une pré-prod. Il faut donc mettre le site "en maintenance" plus souvent qu'à son tour, ce qui est vraiment dommageable.

Quels sont les éléments d'un site Wordpress managé avec Git

- Un serveur web local, ainsi qu'une base de données. Cela permettra d'avoir sa version du wordpress pour faire ses tests, créer des fonctionnalités, installer des plugins, ou mettre à niveau. Certaines personnes conseillent de ne manager que le thème du Wordpress, mais dans ce cas, nous passons à coté de toutes les installations de plugins, les traductions et les changements dans le wp-config.php.

- Un répo Git sur un serveur, ou bien sur Github, pour partager son code entre tous ses collaborateurs. Ce dépôt peut être "bare", c'est à dire nue, sans que le code du wordpress soit présent dans le dossier. Il n'est présent que comme sauvegarde, et pour synchroniser le code de toute l'équipe.

- Une pré-prod sur le serveur, pour montrer vos changements au client, et les tester avec la base de données de production. (uniquement si besoin, pour ce point)

- Le site en production, le seul que vos visiteurs verront.

Une fois que vous avez tout ça, il ne vous reste plus, pour déployer le site, que pousser votre code sur le server. Bien reglé, votre dépôt mettra à jour la préproduction avec la branche development, et la production avec la branche master. Votre passage en ligne ressemblera donc à "git push origin production", ce qui est bien moins générateur de stress que d'éditer sur le FTP et croiser les doigts pour que ça marche.

Mise en place du wordpress et du dépot Git

Pour commencer, preparons notre Wordpress.

Installez Wordpress en local sur votre serveur de développement (si vous n'en avez pas, songez à http://www.wampserver.com/ ou http://www.mamp.info/en/index.html. Si vous êtes sur Linux, installez simplement apache, php et mySQL), et initialisez votre dépôt Git à la racine du Wordpress. Si vous ne savez pas initialiser un dépôt, je vous conseille de commencer par le début.

Une voie ceci fait, ouvrez le fichier caché ".gitignore" . Ce fichier permet de définir une liste de fichiers qui ne seront pas pris en compte par git. Ajoutez-y les liste suivante:

wp-content/uploads/
wp-content/blogs.dir/
wp-content/upgrade/
wp-content/backup-db/
wp-content/advanced-cache.php
wp-content/wp-cache-config.php
sitemap.xml
sitemap.xml.gz
*.log
wp-content/cache/
wp-content/backups/
.DS_Store

Tous ces fichiers n'ont aucune utilité à être copie en développement. Évidemment, si votre éditeur laisse des fichiers de cache derrière lui, n'hésites pas à les ajouter à la liste, de même pour les fichiers .nfo si votre Windows en laisse dans les dossiers.

2e étape, le dépôt git et les dossiers de dev et de prod

J'ai déjà traité cette étape dans un tutoriel précédent. Je vous conseille donc d'aller y jeter un oeil avant de continuer.

La seule petite différence est que si vous optez pour deux environnements, prod et de, il faudra évidemment créer deux dossiers, et penser à check out la bonne branche au bon endroit:

#!/bin/sh
GIT_WORK_TREE=/var/www/monsite.fr git checkout -f master
GIT_WORK_TREE=/var/www/dev.monsite.fr git checkout -f development

Et voilà, nous y sommes, la mise en place du projet est faite.


Pour aller plus loin

Avec tout ça, notre mise en ligne se trouve déjà bien simplifiée, mais il serait possible de faire encore mieux, en mettant en ligne (par exemple) un outil qui prendrait des screens de chaque page lors du passage en pré-prod, et qui comparaîterait ces screens a la dernière version valide (ne riez pas, cet outil existe). De cette façon, il ne serait plus nécessaire de tester toutes les pages a la main, nous pourrions avoir directement un affichage des différences.

  • Partager l'article en 1 clic !

    N'hésitez pas à aider le BlogDuWebdesign
Avatar_thumbAuteur : Benjamin voir son blog

Développeur autodidacte depuis quelques années, déjà, je suis le développeur du blog du webdesign, où mon rôle est de concretiser les différentes idées et maquettes.

Devenez membre !

Rejoignez la communauté des créatifs du web !
- Partagez vos créations
- Gagnez en visibilité
- Créez votre blog facilement
> En savoir plus

Créer mon compte

5Commentaires

  • Avatar_thumb
    TheGuit

    le 11/07/2013 | #1

    Ce qui manque toujours dans ce genre de truc c'est la duplication et la synchronisation de certaines config qui sont en BDD (quand on install, active ou désactive un plugin, ou les configurations). Et également la synchro de certains jeu de test (article de test, ...). J'aimerais bien trouvé une solutions à cet épineux problème !

  • Avatar_thumb
    Constantin

    le 25/07/2013 | #2

    Bonjour, Mon tuto, merci. Par contre j'ai une question, comment faire pour lui faire retirer les fichiers effacés ? Dans mon repo local, j'ai effacé un fichier (via la console git) et une fois commité et pushé, mon fichier était toujours là. Une idée ?

  • Avatar_thumb
    Andlil

    le 26/07/2013 | #3

    Bonjour, Merci pour cet article très instructif, pour simplifier l'utilisation de WordPress ! Bien à vous ;)

  • Avatar_thumb
    Sirius

    le 13/11/2013 | #4

    Bon article mais comme le dit @TheGuit, dommage qu'il n'y ai rien au sujet de la synchronisation entre la base de dev et celle de prod (afin de conserver les commentaires des utilisateurs et tout les autres changement qui se font en temps réel sur la prod).

  • Avatar_thumb
    Adrien Luxey

    le 01/04/2014 | #5

    <p>Article très sympa ! <br />Je m'étais précédemment basé sur cet article : <a href="http://joemaller.com/990/a-web-focused-git-workflow/" rel='nofollow'>http://joemaller.com/990/a-web-focused-git-workflow/</a> <br />Le fonctionnement est à peu près similaire, sinon qu'on crée aussi un repo sur le dossier www, si bien qu'on utilise post-update comme hook.</p> <p>Au sujet de la base de donnée, je fais des "git pull" depuis ma prod de temps en temps, et j'ai ajouté le hook post-merge au local, contenant quelque chose comme ceci :</p> <p>#!/bin/sh <br />ssh userprod@production 'mysqldump wordpress > /home/userprod/wp_db.sql' <br />scp userprod@production:/home/userprod/wp_db.sql /home/userloc/ <br />mysql -u userdb -pPass wordpress &lt; /home/userloc/wp_db.sql</p> <p>C'est bourin, mais on ne fait de pull de la prod que pour se mettre au même niveau de toute façon (dans le même ton on pourrait récupérer wp-content/uploads sans l'ajouter au repo).</p>

    Ecrire un commentaire

    captcha

    Ouvrir