Débuter un projet drupal 8 avec git

Attention !
Cet article nécessite certains pré-requis.

Pré-requis

Pour pouvoir suivre cet article, il est néccessaire que certains logiciels soient installés sur votre environnement de développement ainsi que sur vos serveurs de production. Les logiciels nécessaires sont les suivants

1 – Créer un dépôt pour le projet

La première étape consiste à créer un nouveau dépôt vide pour notre projet. Pour ma part j’ai choisi de travailler avec gitlab.com qui est une alternative gratuite à Github et qui permet de créer un nombre illimité des dépôts privés. Mais libre à vous de choisir n’importe quel hébergement git ou votre propre serveur.

2 – Préparation de l’environnement de production

Pour préparer notre projet, j’ai choisi de réaliser les premières étapes sur le serveur de production afin de réduire les temps de download/upload des fichiers lors du commit initial.

2.1 – Mise en place de votre dépôt git

Connectez-vous en ssh à votre serveur et placez-vous, à l’aide de la commande cd, dans le répertoire sensé accueillir votre site. Exécutez ensuite les commandes suivantes:

git clone [votre_repository]
cd [votre_repository]
Important :
Après cette étape, il faut mettre à jour votre configuration apache afin de faire pointer le nom de domaine de votre site vers le répertoire [votre_repository]

2.2 – Téléchargement de la dernière version de drupal 8

Attention ! le lien utilisé ci-dessous peut varier.
Rendez-vous sur la page https://www.drupal.org/node/3060/release et copiez le lien vers l’archive .tar.gz de la version la plus récente de drupal 8
wget https://ftp.drupal.org/files/projects/drupal-8.0.0-beta4.tar.gz
tar -zxvf drupal-8.0.0-beta4.tar.gz
mv drupal-8.0.0-beta6/* . && mv -n drupal-8.0.0-beta6/.* .
rm -rf drupal-8.0.0-beta6 drupal-8.0.0-beta6.tar.gz

Et finalement exécutez cette longue commande qui fixera les droits en écriture sur les répertoires et fichiers requis pour que l’installation de drupal se déroule correctement :

cd sites/default; mkdir files; mkdir files/translations; cp default.settings.php settings.php; cp default.services.yml services.yml; chmod -R 777 files services.yml settings.php; cd ../..;

2.3 – Installation de Drupal 8

rendez-vous sur l’adresse que vous avez choisi pour votre projet (https://www.mon-site.com) et suivez l’assistant d’installation de drupal 8. Pensez à créer préalablement un nouvel utilisateur et une base de données associée via phpMyAdmin.

Une fois l’installation terminée, on retire les droits en écriture sur les fichiers de configuration, par mesure de sécurité.

chmod 755 sites/default/settings.php sites/default/services.yml

2.4 – Préparation du premier commit

Afin de pouvoir installer facilement une copie de notre projet sur notre environnement de développement, il est nécessaire de dupliquer le fichier de configuration de notre site.

cp sites/default/settings.php sites/default/production_settings.php

Attention : Le nom de la copie ci-dessus doit-être respecté et ne doit surtout pas commencer par settings. dans le cas contraire, ce fichier serait ignoré lors du commit à cause du fichier .gitignore que nous allons créer maintenant.

vi .gitignore

et collez dans ce fichier le contenu suivant :

sites/*/settings*.php
sites/*/files/php
sites/*/files/js
sites/*/files/css
sites/simpletest

Nous allons maintenant créer un répertoire que nous appellerons « backup » et dans lequel nous stockerons la sauvegarde de la base de données de notre projet.

mkdir backup

On sauvegarde notre base de données dans ce nouveau répertoire grâce à drush

drush sql-dump --result-file="backup/dump.sql"

On sauvegarde toutes les configurations de Drupal 8 qui ne sont pas stockés en base de données

drush config-export

Enfin, nous pouvons lancer notre premier commit !

git add -A
git commit -am "Initial commit"
git push origin master

3 – Travailler sur l’environnement de développement

3.1 – Récupérer le projet sur notre environnement de développement

git clone [votre_repository]
cd [votre_repository]

On met ensuite à jour les autorisations en écriture sur les dossiers qui le nécessitent :

chmod -R 777 sites/default/files

Comme sur notre serveur de production, il est nécessaire de créer une base de données vide et un utilisateur à l’aide de phpMyAdmin. Les informations de connexion à la base de données peuvent être différentes de celles de notre environnement de production.

On duplique notre fichier production_settings.php et on le met à jour avec les informations de connexion à notre base de données locale

cp sites/default/production_settings.php sites/default/settings.php
vi sites/default/settings.php

Tout en bas du fichier, on remplace les informations de connexion à la base de données par les informations de connexion à notre base de données locale que nous venons de créer.

3.2 – Importation de la base de données

Pour que notre site fonctionne correctement, il est évidemment indispensable d’importer la base de données à l’aide de la commande suivante :

drush sql-query --file="backup/dump.sql"

Et voilà ! Votre projet et maintenant prêt à fonctionner avec git !

4 – Travailler sur deux environnements distinct

4.1 – Avertissement

Je recommande vivement de ne travailler que sur un seul environnement à la fois et de toujours tenir l’autre environnement à jour. Pour ce faire je distingue deux phase dans la vie de notre projet :

  1. La phase de développement, durant laquelle notre projet n’a aucune existence pour son public cible. Tout au long de cette période, le projet présent sur l’environnement de production n’évolue pas (pas de nouvelles pages ou articles, pas de modifications ni de commentaires)
  2. La phase de production, durant laquelle le projet peut évolué sur l’environnement de production. Durant cette phase, je recommande d’effectuer sur l’environnement de développement uniquement des modifications dans le code source de nos modules ou thèmes. En effet, modifier le contenu ou les configuration de notre projet sur l’environnement de développement nécessiterait d’envoyer ces modifications sur l’environnement de production, ce qui risquerait d’engendrer des pertes d’informations qui auraient pus être introduites sur l’environnement de production entre temps.

4.2 Durant la phase de développement

Au cours de la phase de développement (ou au moins à la fin de cette phase), vous aurez besoin d’envoyer vos modifications vers votre environnement de production. Pour ce faire, il vous faudra suivre les opérations suivantes.

4.2.1 – Sur l’environnement de développement

Sur l’environnement de développement, on sauvegarde toutes nos modifications en créant un nouveau dump de la base de données et en exportants les configurations de notre projet :

drush config-export
drush sql-dump --result-file="backup/dump.sql"
git add -A
git commit -am "Sauvegarde des dernières modifications effectués sur l'environnement de développement"
git push

4.2.2 – Sur l’environnement de production

Sur l’environnement de production, nous récupérons maintenant les dernières mise à jours de notre projet. Ces étapes aurons pour effet de supprimer toutes les modifications qui auront était effectués sur l’environnement de production et qui n’auront pas été répercutés sur l’environnement de développement. C’est pour celà qu’il est primordial de ne pas suivre ces étapes au cours de la phase de production de notre projet.

git pull
drush config-import
drush sql-drop
drush sql-query --file="backup/dump.sql"

Si vous utilisez les caches, il sera nécessaire de les vider pour voir toutes les nouveautés grâce à la commande suivante:

drush cache-rebuild

4.3 – Durant la phase de production

Durant la phase de production, il est important de ne pas modifier d’informations qui nécessiteraient de mettre à jour notre base de données sur l’environnement de production. En effet certains commentaires ou modifications apparus sur l’environnement de production durant la mise en place de modifications sur notre environnement de développement seraient perdus.

4.3.1 – On sauvegarde la version sur l’environnement de production

Dans un premier temps, on sauvegarde notre projet depuis l’environnement de production afin de travailler avec la version la plus récente possible de notre projet.

drush config-export
drush sql-dump --result-file="backup/dump.sql"
git add -A
git commit -am "Sauvegarde de la version en production"
git push

4.3.2 – On met à jour notre environnement de développement

Exécutez les commandes suivantes sur votre environnement de développement :

git pull
drush config-import
drush sql-drop
drush sql-query --file="backup/dump.sql"

4.3.3 – Publication des modifications

une fois les modifications terminés sur notre environnement de développement, on sauvegarde uniquement les fichiers sources et surtout pas les configurations ni la base de données.

git add -A
git commit -am "Application des modifications"
git push

4.3.4 – Mise à jour de l’environnement de production

Maintenant il ne nous reste plus qu’a mettre à jour notre environnement de production pour appliquer nos modifications. Un simple pull suffira normalement à faire apparaitre les modifications :

git pull

Si vous utilisez les caches il vous faudra probablement vider ces derniers grâce à la commande suivante :

drush cache-rebuild
Tagués avec :
Publié dans : Développement web Drupal 8
2 commentaires pour “Débuter un projet drupal 8 avec git
  1. Max dit :

    Salut Fabien, Hyper intéressant ton billet. Par contre tu fais comment quand tu travailles en équipe avec le dump sql ?

    • Fabien LEGE dit :

      Salut Max, Merci pour ton commentaire. Malheureusement, le versioning de base de données est bien plus complexe que ça et je n’ai pas de solution à te donner…
      Si tu dois travailler en équipe sur ce genre de projet, je te recommanderais de ne pas versioner tout le site drupal mais uniquement les répertoires qui sont sensé être modifiés par les développeurs. tu peux ainsi avoir plusieurs repositories pour un même projet (par exemple, une repository pour le thème, une repo pour le plugin A, une repos pour le plugin B, etc). Dans tous les cas git apporte une très bonne solution pour le versioning de code source et le travail collaboratif sur celles-ci mais git n’est pas une réponse à la problématique du versioning de base de données (et encore moins pour ce qui est du travail collaboratif sur la base de données)…

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*