Private Pipelines, Production Discipline

I opened a personal repo after two weeks away and spent the first twenty minutes remembering how to ship it.

Not writing the fix. Not reviewing the diff. Reconstructing folklore: which branch gets the version bump, which check is the real gate, whether the changelog is hand-edited or generated, and which button in CI actually means “yes, production.” By the time the ritual came back, the evening was half gone and the urge to postpone was winning.

That is the boring failure mode of side projects. Not a bad idea. A release process that only exists in the head of whoever last touched the repo — which, for personal work, is always you, and always after a gap.

So I started treating private pipelines with more production discipline than the products strictly “deserve.” Release automation, version bots, one local check that matches CI. Not because Larry, this site, and Gitty are pretending to be platform companies. Because I have little uninterrupted time, and more than one repo that all need to keep moving.

Scarce time is a systems problem

Side projects do not compete with each other in theory. They compete in the calendar.

A few evenings a month, split across work residue, family, and whatever still feels fun, is not enough budget for a unique release culture per repository. Every custom step is a reason to say “next week.” Next week becomes never. Or worse: the thing stays public, and the next security advisory arrives while you are deep in a different repo.

The expensive part is not typing git tag. It is context switching into a half-remembered procedure under time pressure. That is when people invent a version number at midnight, skip a check “just this once,” or leave an advisory sitting because the deploy path feels sharp.

I already write durable project context in Markdown so future-me and AI tools can resume without archaeology — that thread lives in the Markdown bridge post. Pipelines need the same honesty. If shipping depends on memory, shipping becomes optional.

One operating model, several products

The projects are different. The operating model underneath them is deliberately not.

I am not going to tour each codebase here. The useful claim is the overlap:

When code changes in a way that should ship, I declare the change instead of inventing a version at the end of a tired session. In practice that means a Changeset — a small file that says what kind of bump this is — rather than hand-editing package.json like a raccoon with commit access.

CI finalizes the boring part: consume those declarations, bump versions, write the changelog, tag the release. The human job is judgment and merge timing, not remembering which files must stay in sync.

Locally I want one gate — usually pnpm check — that means the same thing CI will mean. Format, lint, types, tests, whatever that repo considers non-negotiable. If green locally is not green in the pipeline, the “automation” is just a second folklore to learn.

That sameness is the whole return on the upfront investment. Different shells, different deploy targets, same muscle memory. Open any of those repos after two weeks and the question is no longer “how does this one ship?” It is “what am I shipping?”

Yes, the pipelines can look a little serious for personal work. That is not the point. Looking serious in a screenshot is free. Recovering an evening after a context switch is not.

Patching is why this stops being taste

Dependency advisories and stack bumps do not wait for inspiration. They show up while you are deep in something else — often in a different product entirely.

If releasing is expensive, or unique per repo, patching becomes optional. Optional patching on anything internet-facing is how a personal project quietly becomes liability: still reachable, no longer practiced, slightly ashamed of the pnpm audit output.

Shared, cheap releases change the economics. “I should bump that” becomes a short, familiar merge request in a procedure you already trust, not a weekend of rediscovering which job deploys what. The production discipline is not there to impress imaginary enterprise reviewers. It is there so safety work fits inside the same scarce evenings as feature work.

I have shipped more than one personal patch release that would have waited weeks if the path had still been folklore. The advisory did not care that the project was “just” mine.

Is this over-engineering?

Fair question. For a single script you touch twice a year, a full release bot is theater. Build the smallest path that makes the next safe change cheap, then stop.

The thesis also fails if the automation becomes the project — if every spare evening goes into polishing CI while the product starves. Production discipline is leverage only while it shortens the path back to shipping. The moment the pipeline is more interesting than the work it protects, you have built a new hobby with worse users.

What I am defending is narrower: several personal repos, little continuous attention, anything that can rot in public. Under those constraints, identical release grammar is not cosplay. It is how you stay shippable without living in one repository.

What I am actually buying

I do not automate personal releases to look professional.

I automate them so scarce time still produces safe, shippable work across more than one project — with the same moves every time, including the unglamorous nights when the only “feature” is leaving fewer advisories on the table.

The first twenty minutes after a gap should be for the change. Not for remembering the ritual.