Mise en place : stratégie de déploiement

Je rumine depuis un moment l’idée d’utiliser mon domaine carevic.eu pour autre chose que du courriel et d’avoir un espace pour écrire sans pseudo.

C’est chose faite et tout reste à faire.

Le cœur

Après avoir réfléchi et laborieusement testé plusieurs solutions (Grav et Eleventy notamment), j’ai choisi d’utiliser Kirby CMS qui me semble le plus à ma portée pour pouvoir me concentrer sur le contenu plus « rapidement ».

Pourquoi pas Dotclear ? Je voulais essayer l’approche basée sur des fichiers (flat file) plutôt qu’une base de données et je me retrouve entièrement dans les raisons avancées par Julien dans son étude de cas.

Le tout est toujours hébergé chez Monarobase ❤️.

Kirby est payant (il y a régulièrement des promos), mais vous pouvez l’essayer gratuitement. Sur Monarobase, il est possible de l'installer en un clic avec Softaculous, qui automatise l’installation d’applications web, si vous n’avez pas envie de le faire manuellement.

Je me suis dit que travailler l’architecture et la stratégie de déploiement du site dès le début serait intéressant pour avoir des fondations solides plutôt que de commencer à me jeter sur le templating et la configuration.

Je tâcherai d’écrire ici au fur et à mesure que j’avance.

Un site versionné

L’intérêt d’une approche basée sur des fichiers, c’est la simplicité de sauvegarde et la possibilité d’utiliser Git (disponible sur mon hébergement) pour versionner le site.

Si j’étais raisonnable, je me contenterais d’utiliser un transfert FTP et je laisserais les jouets des devs tranquille. Seulement, j’aime bien bidouiller sur mon temps libre et avoir l’impression d’être une apprentie sorcière.

Mon lointain idéal : travailler en local avec un dépôt (pour les gouverner tous, un dépôt pour les trouver, un dépôt pour les amener tous…), utiliser les submodules pour mettre à jour avec Git l’application Kirby et les plugins et déployer en production tout en versionnant le contenu et la partie technique.

Naïve, je pensais que ça serait facile à mettre en place (à ma décharge, il était déjà minuit quand je m’y suis mise), mais ça s’est révélé plus complexe que prévu.

En effet, au départ, j’avais simplement prévu de versionner l’intégralité du dossier où se trouve Kirby. C'était sans compter sur les conflits et erreurs liées aux modifications en production de certains fichiers.

Je suis très loin de maitriser Git que je pratique de manière basique au quotidien. J’ai donc laissé de côté l’idée des submodules ou des subtree pour l'instant et de gérer les plugins avec Git.

Mon organisation actuelle : travailler en local sur plusieurs dépôts et déployer en production tout en versionnant le contenu et la partie technique.

Ça donne quelque chose de moins élégant puisque j'aurai à jongler dans un dossier entre :

  • un dépôt pour l'application Kirby (dossier kirby) ;
  • un dépôt pour la partie technique avec notamment les dossiers assets et site (en excluant certains dossiers) ;
  • un dépôt pour le contenu (dossier content).

Ne copiez rien de ce qui suit sans le comprendre ou faites-le en gardant bien en tête que je bidouille et que je suis plus que susceptible de faire des erreurs. Développer n’est pas mon métier !

cPanel et Git™ Version Control

Gérer le dossier kirby avec Git et cPanel

En local, cloner le dépôt officiel Kirby (https://github.com/getkirby/kirby.git).

git clone https://github.com/getkirby/kirby.git

Sur l’interface cPanel, aller dans Git™ Version Control pour créer un dépôt de travail (décocher Clone a Repository).

En local, ajouter le dépôt de travail Monarobase comme dépôt distant (remote).

git remote add monarobase ssh://adressedudepot

Pour que le contenu du dossier local soit déployé sur l’environnement de production, en même temps qu’il est poussé sur le dépôt distant, il faut ajouter un fichier de configuration .cpanel.yml. Voir la documentation de cPanel et un mémo plus concret.

Actuellement, mon fichier ressemble, après plusieurs tâtonnements, à ça :

---
deployment:
  tasks:
    - export DEPLOYPATH=/home/user/dossier-prod/
    - mv /home/user/dossier-prod/kirby /home/user/dossier-prod/old-kirby
    - mkdir /home/user/dossier-prod/kirby
    - /bin/cp -r * /home/user/dossier-prod/kirby
  1. Je définis l’endroit où déployer.
  2. Je renomme le dossier courant kirby en old-kirby.
  3. Je crée un nouveau dossier kirby et je verse tout le contenu à jour à l'intérieur.

Note : dans la documentation de cPanel, il est déconseillé d’utiliser le *. Il est donc fort probable que je fasse évoluer le script. Je voudrais en plus remplacer le nom du fichier old-kirby par date-backup-kirby.

Une fois le fichier ajouté, on le versionne et on le pousse sur le dépôt de travail.

git add .cpanel.yml
git commit -m "fichier déploiement"
git push monarobase

Ensuite a priori, les mises à jour de Kirby devraient se passer comme sur des roulettes 🤞 !

Gérer la partie technique : rsync ?

J’ai longtemps travaillé sur mes projets personnels à l’arrache faute de prendre le temps de bien faire en me disant que l’impact était faible. Toutefois, comme je n’ai déjà pas beaucoup de temps à y consacrer, il est préférable de vite retrouver ses petits après une absence plus ou moins longue.

J’essaie de ne pas reproduire ici les mêmes erreurs.

Pour l’instant, je pense utiliser un principe similaire au dossier kirby. C’est-à-dire remplacer le dossier présent sur l’environnement de production par ce qui est envoyé sur la branche master.

Sauf que mon script est lourd puisque dès que je fais un git push, je dois tout déployer tout (même s’il n’y a pas eu de modification), faute de savoir encore employer rsync.

Dès que j’aurai lu la documentation, je regarderai l’exemple de Yoan Malié plus en détail. Je m’efforce désormais de ne pas copier du code que je ne comprends pas.

Gérer le contenu

On arrive à la partie qui m’intéresse le plus : la gestion des contenus. C’est aussi celle qui me pose le plus de difficulté. Il est possible que quelques jurons m'aient échappé quand je me suis penchée sur le sujet.

Kirby propose un panneau d’administration où il est possible d’écrire et ajouter du contenu. A priori, j’utiliserai au quotidien plutôt un dossier local avec Zettlr comme éditeur Markdown que je suis en train de tester et qui me plaît bien.

MAIS je suppose qu’il n’est pas impossible que je modifie du contenu en passant par l’interface graphique un jour…

J’ai donc besoin à la fois de déployer du contenu en production à partir de mon dossier local sans écraser ce qu'il y a en prod et de récupérer le contenu non présent en local et créé/modifié directement sur le Panel.

Ça tombe bien, il y a un plugin Git Commit And Push Content pour mettre en place ce que je souhaite faire. Youpi !

Je lis les instructions d’installation du plugin et c’est le drame…

composer require thathoff/kirby-git-content

Qu’est-ce que c’est encore que ce truc ? Ma vie de bidouilleuse est devenue tellement plus compliquée à force que le développement web s’est truffé de dépendances et d’outils comme Docker, npm et cie.

Et encore une documentation à parcourir ! Pour l’instant, je n’ai pas eu le courage de me lancer. Composer, c’est donc un gestionnaire de dépendances pour PHP. J’espère bien y trouver la réponse à pourquoi avoir en logo un chef d’orchestre alors que l’outil s’appelle Composer et non Conductor.

Ce que j’ai appris et ce qu’il me reste à faire

J’ai appris à mettre en place un fichier de configuration YAML sur cPanel pour déployer sur mon environnement de production chez Monarobase.

J’ai révisé mes bases de Git. Si j’ai sagement décidé de laisser de côté submodule et subtree pour le moment, j’ai enfin utilisé git rm --cached -r sans prier pour que la commande n’efface pas tout mon disque.

J’ai révisé mes bases sur les commandes Unix et me suis notamment rappelé que la commande cp se contente, comme son nom l’indique, de copier ! Je me suis quand même d’abord étonnée de retrouver en prod un plugin supprimé en local après déploiement… Je ne remercierai jamais assez mon prof d’UNIX d’avoir rendu ses cours suffisamment intéressants pour que je ne sois plus terrorisée par un terminal.

Ma to-do :

  • lire la doc de rsync et tester Composer… ;
  • finir de mettre en place le déploiement de la partie technique et du contenu.