Updates, checked first

The path, step by step

1. 1

   Upload

   The change is uploaded to the main version of the site’s files in their storage. That is the release: nothing else needs pressing. The storage service (GitHub) tells the server at once, and a timer on the server looks for itself every minute in case the message is lost.

2. 2

   Build and checks

   The server fetches the source with a key that can only read, and builds the site in a sealed environment with no network and no way to the live site. Part of the build is the checkpoint, which refuses anything that does not belong on a server: a notes file (Markdown), a comment left in the code, a PHP file with a mistake that would stop it working. Then the checks run: on this site every time, on the others when a change touches the core files or is large.

3. 3

   Publish

   Only a build in which every step passed is copied into the site’s folder. The source itself never reaches it, and every published build stays in the server’s record, which is never rewritten.

4. 4

   Confirmed by the server

   A release counts as landed when the server’s log names the change that was uploaded and a new file, fetched by its name, answers from the live site. One without the other is not proof.

5. 5

   When a check fails

   A build that fails publishes nothing. The site’s folder is not touched, it keeps serving the last good release, and an alert reaches me. The guests see nothing.

What stops a change, site by site

• sudievu.ltthis site

  Stops it

  The build, every checker (fonts, the privacy notice, the contact form, icons, the demonstrations’ sandboxes, the client area’s tests on a simpler database (SQLite)) and the checkpoint, in every build on the server, before anything is published. Before an upload, the same build and the client area’s tests on another database (MySQL) run on my computer, and the upload is refused if they fail.

  Only warns

  The owners’ apps and the layout check I run in a browser on my computer before uploading a change they cover: the server has no browser.

• teatro.lt

  Stops it

  On every change, the checkpoint (notes files, comments in the code, broken PHP or JSON files) and the refusal of private files, such as settings. When the change touches the payment, calendar or other core files, or is large, the server also checks that the PHP files are not broken and runs the PHP tests in a sealed environment before the release.

  Only warns

  The browser tests I run on my computer before uploading a change they cover. A small change outside the core files is released without the PHP tests.

• roziunamas.lt

  Stops it

  On every change, the checkpoint (notes files, comments in the code, broken PHP or JSON files) and the refusal of private files, such as a database. When the change touches the payment, calendar or other core files, or is large, the server also checks that the PHP files are not broken and runs the PHP tests in a sealed environment before the release.

  Only warns

  The browser tests I run on my computer before uploading a change they cover. A small change outside the core files is released without the PHP tests.

• Hortus, In Favorem

  Stops it

  On every change, the checkpoint and the refusal of private files. When the change touches the core files or is large, the server also checks that the PHP files are not broken and runs the form and enquiry tests in a sealed environment before the release.

  Only warns

  The browser and content-parity checks I run on my computer. A small change is released without the tests.