Finlay.worksBareBones Ticketing manual

Operate

Change Control

The five things that must exist before you change a running BareBones Ticketing installation.

RC2 approved for evaluation Status: release-candidate Audience: System Administrator Source: c4b4d41

Change Control

Five things must exist before you change a running installation. This page lists them, says how to tell when each one is real rather than assumed, and says what the product decides for you here. Nothing.

The five

Requirement It exists when
A procedure for this deployment family and this target version Someone has written the steps for the exact package you are installing, on Windows Service or Linux Docker Compose, and you are reading them
A coordinated backup of all four continuity classes PostgreSQL data, attachments, Data Protection keys, and deployment configuration are captured at one compatible point, and the integrity check passed
A defined set of success and failure checks You wrote down what a good outcome looks like and what a bad one looks like, before starting
An agreed recovery decision You know what you will do if it fails, who decides, and by when
Authority to make the change Someone who can authorize this environment has authorized it

If any of the five is missing, you do not have a change. You have an experiment on a production system.

1. A version-specific procedure

Generic steps are not a procedure. The steps must name the exact package, its version, and its checksum, and they must match the deployment family in front of you.

The current entry points are in Upgrades and restarts: rerunning Install-BareBonesTicketing.cmd on Windows, and replacing the bundle then rerunning configure-database.sh on Linux. Those are entry points, not the whole procedure. Your procedure adds the quiesce, the backup, the checks, and the recovery path around them.

A procedure written for another version, another environment, or another customer is not this procedure. Neither is an old runbook whose version you cannot confirm.

2. A coordinated backup

Coordinated means one recovery point across all four classes. A database captured on Tuesday with attachments captured on Wednesday is not a recovery set. See Backup and restore for the four classes, the capture order per family, and what your PostgreSQL commands must satisfy.

Confirm before you start:

  • the capture completed and the integrity check passed;
  • you know which package version the data belongs to;
  • the person who would run the restore has access to the backup and to the restore commands; and
  • the backup you are relying on is not the one this change would overwrite.

A backup that has never been restored is a plan, not a proof. Rehearse against a spare target on your own schedule, and record the date and result.

3. Success and failure checks

Write down, before the change, what you expect to be true afterwards. At minimum:

  • the service or container starts;
  • the running version matches the version you approved;
  • an administrator signs in;
  • an attachment stored before the change retrieves;
  • a protected setting still decrypts;
  • System Diagnostics shows no new unexplained failure; and
  • whichever external check matters here — the public address, the certificate, the proxy — succeeds.

Also write down what constitutes failure. "It looks wrong" is not a criterion anyone can act on at two in the morning.

4. A recovery decision

Decide in advance:

  • the point in the window after which you stop trying to fix forward and start recovering;
  • which way you go — restore the complete prior set, or apply a reviewed forward repair;
  • who makes that call; and
  • how long recovery is expected to take.

Replacing application files or container images does not reverse a schema or data change. Going backwards after a migration means restoring the complete set from one recovery point, with the matching package. Know that before you need it.

5. Authority

Holding the SystemAdmin role in BareBones Ticketing authorizes nothing outside the application. It does not authorize a host restart, a database migration, a restore, a DNS or certificate change, or a production deployment. Those approvals come from whoever owns the host, the database, the network, and the environment.

Name them before the window, not during it.

What the product decides for you

Nothing on this page. BareBones Ticketing supplies no default recovery time objective (RTO), recovery point objective (RPO), backup frequency, retention period, monitoring, or maintenance window. Those are your organization's decisions. An unset value is a reason to stop, not an invitation to pick one during an incident.

Record the change

Keep, for each change:

  • the reason and the exact approved scope;
  • the environment, the current version, the target version, and the package identity and checksum;
  • who requested, approved, performed, and verified it;
  • the backup reference and the migration decision;
  • the procedure reference;
  • the window and the expected downtime;
  • the checks and their results;
  • the final installed version; and
  • anything left over, with an owner.

Record references and outcomes. Do not record commands containing passwords, connection strings, or the contents of an environment file.

During the window

  1. Reconfirm the five requirements and the recovery decision point.

  2. Capture the pre-change state: version, diagnostics summary, backup completion.

  3. Quiesce or stop the deployment exactly as your procedure says.

  4. Apply only the approved scope. Nothing else, however tempting while the system is already down.

  5. Start the deployment through the same procedure.

  6. Run the checks from section 3 before the recovery decision point passes.

  7. If they pass, record the results and close the window.

  8. If something is wrong, stop. Do not keep trying variations. Preserve the state, take the recovery decision you already agreed, and escalate.