Prologue

Au marteau et au burin

Quand ce site a commencé à exister, en 2005 déjà (le nom de domaine a été enregistré le 11 juin 2004, un jour sans importance), il était fait à la main. En bon artisan de l’informatique, je lui ai fait subir des transformations au gré des technologies. Ainsi, on a pu voir sur ce site, des pages entièrement écrites avec un éditeur de texte.

Avant cela, n’ayant pas d’hébergement et encore moins de nom de domaine, j’ai même possédé un site sur Multimania. J’étais spécialement fier du menu latéral fait avec un applet Java. À ce propos, il s’agissait de ma première expérience avec du code Java que j’avais décompilé pour enlever le contrôle de la clé de licence.

L’ère industrielle

Mais sur alleluia.ch, je n’ai pas réitéré l’exploit de l’applet Java. J’ai tout de suite tapé dans le dur. Au commencement, j’ai codé en HTML. J’ai presque eu l’idée de concevoir moi-même un framework en PHP pour gérer mes pages. Heureusement, cette folie n’a même pas passé par le début du commencement d’un petit peu de codage. De longues heures ont été épargnées et les nuits de sommeil complètes qui s’en sont suivies m’ont revigoré.

Très rapidement, il a été question de ne plus coder ces pages à la main. C’est pourquoi, j’ai mis en place quelque chose de très tendance à l’époque : un CMS !

Mon choix s’est porté sur Joomla! qui était certainement une version 1.0.x. Le tout début de ce CMS.

J’ai même créé des extensions pour Joomla! : un nuage de mots-clés - qui se souvient encore de ça - ainsi qu’une extension affichant aléatoirement les fameux faits sur Chuck Norris.

Oui, c’était le comble du fun à l’époque. Mieux que TikTok.

Pendant plusieurs années, j’ai maintenu cette instance de Joomla! ainsi que d’autres utilisées par d’autres sites - presque sans mon consentement. Les mises à jour de Joomla! était assez pénibles. Elles n’étaient pas automatisées. La mise à jour en un clic n’est arrivée que bien plus tard.

Lorsque j’étais stagiaire au Post, Kay Graham m’a donné un excellent conseil. Elle m’a dit : « Ne sois pas trop bon dans un travail que tu ne veux pas. »

Tina Fey dans le rôle de Cinda Canning dans la série Only Murders in the Building

La décroissance

Il faut savoir que Joomla! c’est quand même plus de 9’000 fichiers pour servir, dans mon cas, quelques malheureuses pages. En ajoutant à cela la maintenance de la base de données qui doit être elle aussi entretenue. Tout cela n’est pas une sinécure.

J’ai donc longuement réfléchi et j’ai testé plusieurs types de CMS dit flat. Entendre par là « flat file » CMS, c’est-à-dire un CMS à fichier plat pour la base de données.

En outre, les services de plateforme pour réaliser sont propre site web, même s’ils sont très appropriés dans beaucoup de cas, n’étaient pas vraiment une option pour moi, car je ne souhaitais pas souscrire un abonnement supplémentaire et plus cher à celui que j’avais déjà pour ma messagerie et d’autres sites web.

C’est donc au fil de mes tribulations, qu’il m’est revenu à l’esprit qu’il existait des générateurs de sites web.

Et là, une nouvelle ère avait commencé pour Alleluia ! Jekyll serait le générateur de ce site.

Revenir aux bases

Dans mon cas, la barrière principale était la sélection et la maintenance d’un thème pour mon site. Même s’il est vrai que je sais naviguer dans les eaux troubles de l’HTML et des CSS, je préfère l’éviter. C’est pour cette raison, que je me suis tourné rapidement la sélection d’un thème pour le site parmi l’offre en ligne existante.

Dans le domaine des thèmes gratuits et libres, le choix est vaste, mais je n’ai pas trouvé celui qui me semblait approprié. C’est évidemment une question de goût personnel.

De plus, il y a quand même quelques critères qui étaient importants pour moi : une recherche dans le site et la possibilité d’adapter quelques éléments comme les couleurs, les polices de caractères, etc. Après de nombreuses heures de recherche, j’ai finalement trouvé un thème, payant certes, mais à un prix raisonnable.

Il faut savoir que lorsque vous achetez un thème pour Jekyll, vous obtenez en fait tout le code source du thème. En effet, il n’est pas possible pour le vendeur de l’encapsuler dans une sorte de package hermétique et signé.

Ceci était un immense avantage pour moi, car j’y ai apporté un nombre importants d’améliorations ; en tout cas, c’est comme ça que ces modifications m’apparaissent.

Pour débuter avec Jekyll, je conseille vivement la documentation officielle. Ci-après vous avez un bref aperçu expliquant comment créer un site à partir de rien.

Débuter avec Jekyll

Le code source suit la structure donnée par Jekyll. Tout est documenté ici. Si l’on souhaite créer un site soi-même depuis zéro, le prérequis principal est Ruby. Vous n’aurez pas besoin d’avoir la connaissance du language, mais c’est dans ce language qu’est écrit Jekyll.

Selon votre contexte, vous aurez à installer Ruby. Cette installation est expliquée ici. Par exemple, sur macOS, le plus simple est d’installer Homebrew et ensuite d’installer Ruby et Jekyll et Bundler (gestionnaire de dépendances de packages Ruby, les Gems).

brew install ruby
gem install jekyll bundler

Pour générer une structure d’un structure d’un site vierge {mon-site}, la commande suivante est exécutée:

jekyll new {mon-site}

Se rendre ensuite dans le répertoire du site généré

cd {mon-site}

Pour construire le site

jekyll build

Pour démarrer un serveur local servant le site

jekyll serve

Continuons notre chemin et commençons à nous préparer pour l’automatisation du site.

Préparation

Tout cela est bien plaisant. Vous avez votre thème et vous avez vos anciennes pages. Quelles sont les étapes pour parvenir à un site fonctionnels à partir de cela ?

Récupérer le matériel de base

Plusieurs éléments doivent être récupérés : le contenu de vos pages, ainsi que tous les médias auxquels vous faites références dans vos pages. Vous pourriez même avoir du code JavaScript spécifique à une page.

Si le contenu provient d’un CMS, le plus simple est d’effectuer une requête sur la base de données pour récupérer le contenu des pages. Généralement, il s’agit d’une mixture de code HTML et de texte brut.

Pour les médias, généralement ils sont stockés dans un ou des répertoires sur votre hébergement. Dans mon cas, les types de médias sont des images. Mais selon les situations, on peut en imaginer d’autres : des vidéos, des scripts JavaScript, etc.

Ensuite, il faudra convertir le texte de vos pages en Markdown. J’ai préféré reformater mes pages plutôt que de trouver un convertisseur HTML vers Markdown.

Ceci n’est pas fondamentalement nécessaire, car Jekyll peut générer un site à partir du code HTML existant. Selon la qualité du code HTML à la source, le résultat généré peut donc varier.

Hébergement

En ce qui concerne l’hébergement, un site fait avec Jekyll, nécessite extrêmement peu de prérequis. En gros, il faut simplement un serveur web qui puisse servir des ressources : documents de type HTML, CSS, JPEG, WebP, JavaScript, etc.

L’hébergement de mon site est fait sur Metanet. Comme indiqué plus haut, c’est un hébergement que je possédais déjà. Donc nul besoin d’en changer.

Automatisation

Il s’agit probablement de la raison pour laquelle vous êtes arrivé·e·s sur cet article : comment faire pour déployer automatiquement un site Jekyll.

Comme pour tout, il existe toujours mille façons de faire une chose. Regardez comment faire des pâtes sur internet et vous trouverez 15’000 sites vous expliquant comment chauffer l’eau avant et mettre les pâtes après. Comment les égoutter et comment les refroidir, etc.

Dans mon expérience DevOps, vous serez éconduits de la même manière. Loin de moi l’idée de proposer une version absolue du déploiement d’un site généré par Jekyll.

Dans ma situation, j’ai choisi de le faire au moyen d’Azure DevOps. La raison principale réside dans le fait qu’à l’époque où j’avais créé mon organisation sur Azure DevOps, Microsoft était le seul fournisseur de dépôts Git qui permettait d’avoir des dépôts privés.

Principe de fonctionnement

Pour effectuer un déploiement il faut donc également les sources du site. Celles-ci sont stockées dans un dépôt Git. Depuis le dépôt, les sources sont récupérées et traitées par le générateur Jekyll. Finalement, le site généré est déployé sur l’environnement idoine.

Processus

Les étapes mentionnées ci-dessus ne sont certes pas difficiles à exécuter manuellement. Toutefois, elles nécessitent un environnement de développement local et le lancement de commandes dans un terminal.

En automatisant ces tâches, nous nous concentrons sur la rédaction des articles et des pages et non pas à la mise en place d’un environnement de développement et à cette mécanique de génération. C’est exactement ce que nous allons automatiser.

Un pipeline de déploiement simple dans Azure DevOps, se décrit avec un fichier YAML. Il existe d’autres manière de décrire le pipeline d’intégration. L’avantage que présente le fichier YAML est qu’il est sauvegardé dans le dépôt de code source au même titre que le reste du site.

Le pipeline définit 3 étapes principales :

  1. La récupération du code source du site
  2. La construction du site à partir du code source
  3. Le déploiement du site généré

Le fichier YAML s’appelle par défaut azure-pipelines.yml

Récupération du code source

Le code source du site est stocké dans un dépôt Git au même titre que le fichier de description du pipeline azure-pipelines.yml. Dans le descripteur du pipeline, la récupération du code source est implicite. Le contenu du dépôt dans lequel est stocké le descripteur de pipeline est donc récupéré automatiquement au moment du déclenchement du pipeline.

On doit néanmoins indiquer le déclencheur du pipeline : élément trigger ci-dessous. Cet élément du fichier YAML indique que l’on prend en considération toutes les modifications qui sont faites dans le dépôt pour le lancement du pipeline CI/CD à l’exception de celles faites dans le répertoire _drafts et sur le descripteur de pipeline lui-même : azure-pipelines.yml.

Je l’ai configuré ainsi, car je ne souhaitais pas démarrer le pipeline pour des changements qui ne sont pas visibles dans le site déployé. En effet, les articles placés dans _drafts ne sont pas publiés par Jekyll.

De même, je ne souhaitais pas qu’une modification du descripteur de pipeline provoque un déploiement du site même s’il n’avait pas été modifié.

trigger:
  paths:
    exclude:
      - '_drafts/*'
      - 'azure-pipelines.yml'

Construction du site

La construction du site est la deuxième étape de ce processus. En premier lieu, on choisit l’environnement sur lequel sera construit le site.

Avec Azure DevOps, on peut choisir dans une liste de plusieurs systèmes d’exploitation - présentés sous forme d’images de machines virtuelles - lequel de ceux-là sera utilisé pour la construction.

Ces images de machines virtuelles préparées par les équipes de Microsoft présentent l’avantage d’être à jour et d’avoir un grand nombre de composants logiciels préinstallés. Une liste complète de ces agents est disponibles ici.

Ensuite, le descripteur de déploiement indique les différentes étapes du pipeline. Avec en premier, l’étape build. Dans cette étape, on s’assure d’abord d’avoir la bonne version de Ruby. On installe ensuite Jekyll et ses dépendances. Et finalement, on exécute la construction du site.

Pour faire en sorte de passer le contenu généré à l’étape de déploiement, on copie et publie le site construits dans le pipeline.

pool:
  vmImage: ubuntu-latest

stages:
  - stage: Build
    jobs:
      - job: Package
        steps:
          - checkout: 'self'
            fetchDepth: '1'
            displayName: 'Checkout source code'
          - task: UseRubyVersion@0
            inputs:
              versionSpec: '>= 2.5'
            displayName: 'Install Ruby'
          - script: |
              gem install bundler jekyll
              bundle install --jobs=4
            displayName: 'Install bundles'
          - script: bundle exec jekyll build
            displayName: 'Build website'
          - task: CopyFiles@2
            inputs:
              SourceFolder: '$(System.DefaultWorkingDirectory)/_site'
              Contents: |
                **
                !*.yml
              TargetFolder: '$(Build.ArtifactStagingDirectory)'
            displayName: 'Copy website to staging directory'
          - publish: '$(Build.ArtifactStagingDirectory)'
            displayName: 'Publish website to pipeline'

Déploiement du site

Le déploiement du site se fait sur votre hébergement. Comme un site généré par Jekyll est un ensemble de fichiers HTML, CSS, JavaScript, etc., aucune configuration spéciale n’est habituellement nécessaire sur votre hébergement. Généralement un téléversement par FTPS est suffisant.

À cette dernière étape, on récupère le contenu du publié auparavant dans le pipeline et l’on pousse ce contenu au bon endroit sur l’hébergement.

La configuration de la connexion pour l’accès par FTP se fait de manière sécurisée. Aucun mot de passe n’est stocké dans le code source.

- stage: Production
  dependsOn: Staging
  jobs:
    - job: Deployment
      dependsOn: Verification
      steps:
        - checkout: none
        - download: 'current'
          displayName: 'Retrieve website from pipeline'
        - task: FtpUpload@2
          displayName: 'Upload website'
          inputs:
            credentialsOption: 'serviceEndpoint'
            serverEndpoint: 'FTP endpoint production'
            rootDirectory: '$(Pipeline.Workspace)/Build.Package'
            filePatterns: '**'
            remoteDirectory: '/'
            enableUtf8: true
            clean: false
            cleanContents: true
            preservePaths: true
            trustSSL: true

Votre site est maintenant déployé !

Il ne vous reste plus qu’à écrire ces articles dont vous avez depuis trop longtemps repoussé l’écriture.