Exploitation au quotidien

Livrer un site#

1. Générer les accès de production

   npm run create:site -- --nom "Boulangerie Martin" --depot agence/boulangerie-martin

   La commande affiche deux blocs qui ne voyagent pas ensemble : ce qui part chez le client (une clé, une adresse) et ce qui part chez l'hébergeur (l'empreinte, les secrets, le jeton). Plus la liste de vérification d'avant livraison.

   La clé n'est écrite nulle part. Ce qui n'est pas copié à ce moment-là est perdu — et c'est voulu.

2. Vérifier avant d'annoncer

   Les quatre commandes de Déploiement, plus l'essai des cinq clés fausses. Une livraison annoncée puis rattrapée coûte plus cher qu'une heure de vérification.

3. Transmettre

   • l'adresse monsite.fr/admin ;
   • la clé, par un canal séparé — pas dans le même message que l'adresse, idéalement pas par courriel ;
   • le lien vers /aide ;
   • la capsule de formation.

La capsule de formation#

Six minutes, enregistrées en partage d'écran sur le site du client lui-même. Le client la regarde quand il en a besoin — c'est-à-dire trois semaines après la livraison, le jour où il veut changer une photo. Une formation en direct est oubliée avant d'avoir servi.

Et une phrase, une seule, sur ce qu'il ne peut pas casser : « Vous ne pouvez pas casser la mise en page, et rien n'est jamais définitivement perdu : chaque publication est conservée. En cas de doute, écrivez-nous. »

Ce qu'il ne faut pas mettre : le multilingue si le site est monolingue, le fonctionnement de la reconstruction, le nom de l'hébergeur ou du dépôt, et une liste des choses interdites — le client ne peut pas les faire, les énumérer ne fait que suggérer que l'outil est fragile.

Mettre à jour un site#

npm update inline-core
npm test && npm run check

Le journal des versions dit ce qui change. Le versionnage sémantique a ici une règle qui lui est propre :

Publier les paquets#

1. Éprouver les archives

   npm run test:pack

   Le seul mode qui attrape un fichier oublié dans files ou un chemin absent d'exports. Ces erreurs sont invisibles tant qu'on installe depuis un dossier, et elles cassent le premier site d'un tiers.

2. Mettre à jour le journal des versions

   Ce qui a changé, et surtout ce qu'un site doit faire pour suivre.

3. Publier

   npm run release:core     # inline-core
   npm run release:cli      # create-inline

Essayer une archive à la main

# 1. fabriquer les archives
npm pack ./packages/inline-core   --pack-destination /tmp/inline
npm pack ./packages/create-inline --pack-destination /tmp/inline

# 2. créer un site depuis l'archive de création
cd /tmp/inline && mkdir atelier && cd atelier
npm exec --yes -- "file:/tmp/inline/create-inline-1.0.0.tgz" mon-site --nom "Essai"

# 3. installer le cœur depuis son archive, puis construire
cd mon-site
npm install "file:/tmp/inline/inline-core-2.0.0.tgz"
npm run build && npm run serve:functions

Suivre plusieurs sites#

Au-delà de trois clients, la question n'est plus « est-ce que ça marche » mais « quelle version tourne où ». Tenir un tableau, quelque part, avec une ligne par site :

C'est ce tableau qui rend un correctif de sécurité applicable : dix npm update inline-core, dix npm test, dix poussées. Pas dix modifications à retrouver dans dix bases de code différentes.

L'échéance qu'on oublie

L'expiration du jeton Git. Elle ne casse pas le site : elle casse la publication, et le client le découvre en essayant de modifier une page — souvent un vendredi. Un rappel une semaine avant, par site, coûte trente secondes à poser.

Sauvegarde et restauration#

Les demandes qui arriveront#

Passer la main#

Ce qu'un développeur qui reprend le projet doit recevoir :

• L'accès aux dépôts et au compte machine.
• L'accès à l'hébergeur, et la liste des projets.
• Le tableau des sites : version, échéances, dates.
• Les trois premiers chapitres de cette documentation, dans l'ordre.
• Le fichier de consignes du dépôt — les onze règles absolues.
• Et surtout : pourquoi le périmètre est gelé. C'est ce qui se perd en premier.