L’une des choses les plus difficiles à propos de l’utilisation de générateurs de sites statiques a été de gérer les publications de planification à l’avance. J’ai quelques idées sur des façons intéressantes de planifier des publications, mais la plupart d’entre elles sont très complexes sur le plan technique. J’essaie donc d’explorer quelques solutions différentes, et je les écrirai ici au fur et à mesure que je les essaierai. Si vous ne l’avez pas encore lu, consultez mon article sur Démarrer un blog avec chabot afin que vous connaissiez le contexte de ce dont je parle.
La métrique indiquant si le processus de planification a réussi ou non est : Puis-je, à l’avance, déclencher un nouvel épisode du Five Minute Geek Show à publier à une certaine heure ? C’est important pour moi, car j’ai FMGS selon un calendrier défini, mais je ne suis pas toujours devant mon ordinateur principal pour le déployer.
Infrastructure
Normalement, publier sur le site signifie simplement exécuter le script de publication localement. Mon script de publication particulier génère les nouveaux fichiers, les déplace dans un référentiel Git et pousse le référentiel git, en s’appuyant sur Forge pour attraper le webhook Github et le déployer.
Comme nous le planifions pour l’avenir, nous ne pouvons plus compter sur le fonctionnement de ma machine locale au moment du déploiement. Nous devons donc trouver un autre moyen de le synchroniser.
Comment planifier sous Linux
Lorsque j’ai mentionné cela pour la première fois sur Twitter, Adam Wathan a souligné le at commande, qui est comme une tâche cron unique qui vous permet de programmer une commande plus tard. J’aime ça, et je vais planifier ça.
Donc, ma commande était celle-ci:
$ at 10:00
at> cd ~/fiveminutegeekshow.com
at> do whatever commands I want here
at> <ctrl-d>
Vous pouvez vérifier quelles commandes sont programmées ultérieurement avec $ at -l.
Option 1 : téléchargez le source au serveur de production et planifier une compilation
La première option consiste à se débarrasser entièrement de l’idée d’un dépôt github “distribution”. Nous pourrions télécharger le référentiel “source” sur le serveur de production, ainsi que son output_prod dossier. Ensuite, nous pourrions programmer un sculpin generate --env=prod commande au moment donné.
Nous pouvons simplement indiquer que la racine Web de Forge est /home/fiveminutegeekshow.com/output_prodpuis chaque fois qu’une nouvelle version est créée, Forge servira le nouveau contenu.
Option 2 : Désactiver le déploiement automatique sur le dépôt de distribution et programmer une commande git pull
Nous pourrions garder la situation telle qu’elle est en ce moment, désactiver le déploiement automatique de Forge et planifier à la place un git pull dans le bon répertoire au moment donné.
Option 3 : Le système de dossiers
Capistrano est un système de déploiement qui a une idée astucieuse : pour éviter les temps d’arrêt, chaque nouveau déploiement du site doit avoir son propre dossier dans un répertoire “deploys”. Ensuite, lorsqu’il est temps de publier la nouvelle version, tout ce que vous avez à faire est de créer un lien symbolique entre votre répertoire “actuel” (d’où provient votre serveur Web) et le nouveau répertoire. Cela facilite également le retour aux versions précédentes.
On pourrait faire le même genre de choses. C’est là que ça commence à devenir complexe, cependant. Nous parlons probablement d’utiliser quelque chose comme Capistrano ou Chef pour déployer le code, puis de devoir planifier le lien symbolique à l’avance. Je sais que quelqu’un va suggérer cette façon de faire, c’est pourquoi j’en parle, mais cela me semble fou.
La conclusion actuelle
Pour l’instant, je vais essayer l’option 2. J’ai un épisode qui sort à 10h00 heure de l’Est aujourd’hui, donc je vais voir si je peux le mettre en place pour cet après-midi, et faire un rapport ici.
MISE À JOUR : L’option 2 a fonctionné comme un charme !