← All projects

A URL per branch, on the machine that writes it

Before · in turns1
Now · in parallel3
branches live at once
Sector
Internal developer tooling
Duration
In use from the first month
Role
Design, delegation to an agent, and delivery

01Where it started

One machine, one set of ports, and several branches alive at the same time. Moving between them meant tearing the whole environment down, losing the state of the database, and waiting for the next one to come up. And for anyone outside to see a change, it had to be deployed to a shared environment, where the branch next door overwrites it. The work was being serialised for a reason that had nothing to do with the work.

02What could not move

  • The application code is not touched. This is infrastructure.
  • Every branch gets its own database, and none of them fight over ports.
  • Somebody new has to be able to install it by reading a single page.
  • Sharing cannot cost speed: the local address still reloads instantly.

03The decision

One working directory per branch, each with its own isolated environment and its own database. A router in front decides by hostname and discovers new ones on its own, so adding a branch touches no central configuration. To share outward, a tunnel to a server of our own holding real certificates. The alternative that was discarded is a shared staging server: it lowers today’s work and leaves the branches fighting over the same environment, which is exactly the problem to be solved. The build was delegated to an agent, with the scope written before any code: which commands it had to expose, which invariants it could not break, and a hard limit that it touched only the preview environment and never production.

04The trade-off

What it cost
It all runs on the machine of whoever is writing the code. Three environments in parallel are three times the memory, and the limit is set by the laptop rather than by the design. The tunnelled address, on top of that, only lives while that machine is on and connected.
Why it was worth it
In exchange, no branch costs infrastructure and none waits on a deploy to be seen. The isolation is real — its own database — rather than an agreement between people that holds until somebody is in a hurry. For what does have to be available at all times there is a third address, served from the server off the latest push, which depends on nobody keeping a machine open.

05What went wrong

Three faults turned up running the full cycle by hand, and none of them in the tests or in the agent’s own report: one environment served errors off the old schema, the tunnel was refused silently when the credential was wrong, and another could not write to its own storage. All three had the same cause: what fails is not bringing an environment up, it is the state the previous one left behind. Each was fixed where it surfaced — the environment repairs its own schema, the tunnel names that error out loud, permissions are relaxed from inside — and the rule that orders the rest stayed: the human pass over a live branch is what signs the work off, not the report of whoever did it.

06What came of it

Three addresses per branch, one installation, one command. A branch that gets merged stops being published and frees its slot on its own, with nobody remembering to clean up. A diagnostic says what is missing and the command that fixes it, before it fails. The tool is in use and it is not finished: it lives on its own unmerged branch, and the case of two shared branches at once is still unconfirmed. The part worth automating is not bringing an environment up. It is taking it down.

Something similar in front of you? Tell me what you are dealing with and I will reply, almost always within 24 hours.

Get in Touch