Day-to-day operation

Delivering a site#

1. Generate production credentials

   npm run create:site -- --nom "Martin Bakery" --depot agency/martin-bakery

   The command prints two blocks that do not travel together: what goes to the client (a key, an address) and what goes to the host (the hash, the secrets, the token). Plus the pre-delivery checklist.

   The key is written nowhere. What is not copied at that moment is lost — deliberately.

2. Verify before announcing

   The four commands from Deployment, plus the five-wrong-keys trial. A delivery announced and then patched costs more than an hour of checking.

3. Hand over

   • the address thesite.com/admin;
   • the key, through a separate channel — not in the same message as the address, ideally not by email;
   • the link to /aide;
   • the training video.

The training video#

Six minutes, recorded as a screen share on the client's own site. The client watches it when they need it — that is, three weeks after delivery, the day they want to change a photo. A live session is forgotten before it is useful.

And one sentence, exactly one, about what they cannot break: “You cannot break the layout, and nothing is ever permanently lost: every publication is kept. When in doubt, write to us.”

What not to include: multilingual features if the site is monolingual, how the rebuild works, the name of the host or the repository, and a list of forbidden things — the client cannot do them, and listing them only suggests the tool is fragile.

Updating a site#

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

The changelog says what changes. Semantic versioning here carries one rule of its own:

Publishing the packages#

1. Test the archives

   npm run test:pack

   The only mode that catches a file forgotten in files or a path missing from exports. Those errors are invisible while installing from a folder, and they break the first third-party site.

2. Update the changelog

   What changed, and above all what a site must do to follow.

3. Publish

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

Trying an archive by hand

# 1. build the archives
npm pack ./packages/inline-core   --pack-destination /tmp/inline
npm pack ./packages/create-inline --pack-destination /tmp/inline

# 2. create a site from the creation archive
cd /tmp/inline && mkdir workshop && cd workshop
npm exec --yes -- "file:/tmp/inline/create-inline-1.0.0.tgz" my-site --nom "Trial"

# 3. install the core from its archive, then build
cd my-site
npm install "file:/tmp/inline/inline-core-2.0.0.tgz"
npm run build && npm run serve:functions

Running several sites#

Beyond three clients, the question is no longer “does it work” but “which version runs where”. Keep a table, somewhere, with one row per site:

That table is what makes a security fix applicable: ten npm update inline-core, ten npm test, ten pushes. Not ten edits to find again across ten different codebases.

The deadline everyone forgets

Git token expiry. It does not break the site: it breaks publishing, and the client finds out while trying to change a page — often on a Friday. A reminder a week ahead, per site, takes thirty seconds to set.

Backup and restore#

The requests that will come#

Handing over#

What a developer taking over the project must receive:

• Access to the repositories and the machine account.
• Access to the host, and the list of projects.
• The site table: version, deadlines, dates.
• The first three chapters of this documentation, in order.
• The repository's instruction file — the eleven absolute rules.
• And above all: why the scope is frozen. That is what gets lost first.