Perth, Western Australia

A deploy should be one reviewed script.

Scriptshift turns a deploy into one reviewed, reproducible script with an audit trail, for software teams of two to five people. The working rule is short. If a deployment cannot be read start to finish by somebody who did not write it, we do not count it as a deployment. We count it as a habit that has not failed yet.

Send us your worst deploy story or read the working rule first

hello@scriptshift.cc · answered inside 5 working days, with an answer rather than a receipt

Jurisdiction: Western Australia
Entity: Proprietary company
Team size: Two to five
Release artefact: One committed file

Working rule

1One artefact a second person can read

Everything a release needs lives in one committed file that sits in the repository beside the code it ships.

A deployment is a sequence of decisions about what to change, in what order, and what to do when a step does not come back. In a small team that sequence usually lives in three places at once. Part of it is a wiki page written during the last incident. Part of it is a chat message somebody starred. The rest is in the head of whoever set the thing up in the first place.

Each of those degrades in its own way. The wiki page goes stale the first time a flag is renamed and nobody thinks to edit it. The chat message scrolls out of reach. The person who remembers the rest takes annual leave in the same week a certificate expires.

Our position is that the sequence belongs in a single executable file, committed alongside the application, changed through the same review process as the application, with no step that exists only as an instruction to a human. That is the whole idea. Everything else on this site is a consequence of it.

What readable means here

Readable is not a feeling. We hold a release file to five properties, and every one of them is something a reviewer can check without running anything.

The five properties of a readable release file
Property	What it requires	How a reviewer checks it
Linear	The file reads top to bottom in the order the actions happen. No dispatch table, no plugin lookup, no inheritance	Read it once without following a reference out of the file
Declared inputs	Every environment variable, secret name, credential and pre-existing resource the run depends on is named in the first block	Compare the declared list against what the body actually reaches for
No implicit state	Nothing depends on which machine ran the previous release, on a local cache, or on a step that somebody always does first	Look for a read that is not in the declared list
Reversal stated	Every action says whether it can be undone and how. An action with no reversal says so in the file rather than staying silent	Every action carries one of the two markers
Dry run	The same file prints the ordered set of actions without performing any of them	Run the plan step and read what it prints

The fifth property is what makes the other four testable. A file that can describe itself is a file a reviewer can disagree with before it runs, which is the only moment when disagreement is cheap.

Mechanics

2What the tooling does

Six pieces, each named for what it does to a release file rather than for a category it belongs to.

The tooling is a command that runs where you already run your build. It takes one file, reads it the way a reviewer would, and refuses the run at the first point where the file and the environment disagree. Every column below is something you can watch happen on a terminal.

Each part of the tooling and what it puts in front of a reviewer
Part	What it does	What a reviewer gets
Plan step	Reads the release file and prints the ordered list of actions with their declared inputs, performing none of them	The whole release as text, before anything has happened
Apply step	Runs that same ordered list, recording the start and the finish of each action	A run record with a timestamped line for every action
Input check	Fails the run before the first action when a declared input is missing or empty	The name of the input that did not resolve, at the top of the output
Reverse step	Applies the stated reversal of each completed action, in the opposite order. An action with no stated reversal halts it rather than being guessed at	The exact point where reversal stops being possible
Review summary	Reduces a release file to a plain summary for a reviewer who is not going to read every line of it	What changes, in what order, and which parts cannot be taken back
Second reader gate	Refuses an apply step against production until a named second person has approved that exact file	The name attached to the approval, and the file it was given for

Nothing on that list is a dashboard and nothing on it is a service. Six commands, one file, and an audit trail that is a by-product of running rather than a feature bolted on beside it.

Non-goals

3What it does not do

There are more entries here than in any feature list we could write, and this is the half of the pair worth reading.

No agent. Nothing is installed on your servers and nothing runs in the background. The tooling is a command that runs where you already run your build.
No hosted control plane. There is no dashboard, no account and no service to sign into. Removing us from the picture means deleting a file from a repository.
No secret storage. Secrets stay in whichever manager you already use. The tooling names what it needs and refuses to start when one is absent, and that is the whole of its involvement with secrets.
No infrastructure provisioning. Terraform, OpenTofu and Pulumi exist and are good at this. A release file calls them. It does not replace them.
No promise above roughly ten engineers. Past that size the coordination problem changes shape, and the honest answer is a different product built by somebody who has worked on it.
No compliance claim. Nothing here is offered as evidence towards an audit, a framework or a certification, and a review gate that produces a record is not the same thing as a control.

Writing a non-goal down turns it into something you can hold us to. Left in somebody's head it is only a preference, and a preference bends the first time a customer big enough to matter leans on it.

Scope

4Why teams of two to five

At that size nobody is a release engineer, and the person who wrote the change is the person who ships it.

The failure we care about is not a bad process. It is the absence of any process that survives one person being unavailable. A team of four does not need a change advisory board and would not tolerate one. What it needs is for the second person to be able to read what the first person is about to do, in the ten minutes before they do it.

Every design decision follows from those ten minutes. A dashboard does not help, because the reviewer is already looking at a pull request. A domain specific language does not help, because it adds something to learn before the reviewer is allowed to disagree. Anything that makes the file longer than a person will genuinely read is a defect, even when it is technically correct.

The two person property

We keep coming back to one test. Hand the release file to the colleague least involved in the change. If they can say what will happen, in what order, and what will be true afterwards, the file is finished. If they can only say that it looks fine, it is not.

Where the reasoning stops

We have not tested this at any other size and we are not claiming that it generalises. A team of forty has a different problem. A regulated environment has a different problem again. Neither is one we have worked on, and neither is one we will pretend to have an answer for in order to widen the market.

5The verifiable part

The claims on this site that a public register will settle one way or the other, and which register settles them.

Legal name

SCRIPTSHIFT TECHNOLOGIES PTY LTD

ACN

698 500 542

ABN

21 698 500 542

State

Western Australia

Entity type

Australian proprietary company

GST

Not currently registered for GST

Verification

Look the ABN up on the Australian Business Register at abr.business.gov.au, which shows its status and the GST position at no charge. ASIC holds the company record the ACN points at

Service of documents

Formal service goes to the office ASIC records against ACN 698 500 542. Printing a second address here would only create somewhere to send documents where they carry no effect

Contact

6One address

Every route into this company is a single mailbox, and it is read by the people who write the tooling.

Send us your worst deploy story. The one that ran for forty minutes at the wrong time of night, or the one where step four turned out to depend on step two having been done by hand. Write it to hello@scriptshift.cc and you will get a real reply about where a single reviewed file would and would not have helped, including the parts where it would not.

You will not find a form anywhere on these pages. A form that goes nowhere is a prop, and a working one quietly banks your address next to a fingerprint of your browser that nobody asked you about.

General mail is answered inside 5 working days, with an answer rather than a receipt. Anything raised under the Privacy Act 1988 (Cth) runs to the 30 day period that APP 12 and APP 13 set. A suspected security problem is picked up the same working day or the next one.

Send us your worst deploy story Subject lines and timings