Fiuto: releasing the feature to production

Context

The previous part, on planning and building a feature with the build agent, left the collaboration feature merged to the development line in phases. What remains is the release, where finished work leaves staging and reaches the people using the product, and it closes the arc that started with a question the studies list could not answer. Code, data and server-side behaviour deploy on different schedules, so the same screen can show different things in the live app and on staging while the ship runs; a team that cannot tell which layer is behind a missing element will report a deployment-order problem as a design defect. This part shows what the two environments displayed during the release, how long the feature took from ideation to delivery, and the definition of a production release the ship skill carries now.

A release, step by step

As this session ran it, a release of a feature like this one has four parts, whoever carries them out.

1. Knowing what goes out. A release carries every change merged since the last one, so the decision covers that whole batch and the risk inside it, and the feature that prompted the release is one item among them.
2. Migrations, in order. The avatars depended on the last migration, and until it had run on an environment the code there could only show part of the feature. Deploying code ahead of the schema it expects is how a finished feature arrives incomplete.
3. The same code on staging. Staging had the feature before production did, so the list, the share panel and the mobile layout could be checked on the exact code about to go live.
4. Watching the deployment to the end, then looking at the product. The ship in the video was a progress bar until the edge function came up and the list showed the avatars, and the last check was the list on a phone, since a narrow desktop window does not reproduce a device.

01The pipeline

The /ship skill

Merging a pull request to main lands code on the development line and updates staging. A ship is a separate operation: it promotes every unshipped commit on main to prod, and the production workflow applies the migrations and deploys the frontend and the edge functions through GitHub Actions. The /ship skill runs that in order and stops when the batch is not ready.

The skill proves that the batch is ready, the dry run clean and staging green; only I release it, and only I accept a flagged migration. An urgent fix ahead of a batch that is not ready goes through a separate hotfix workflow that picks already merged commits and records the divergence.

02The session

What is in this video

Two environments, side by side: in the live app the studies list shows no avatars and no indication of each study’s privacy setting, because the feature had been delivered to staging only; on staging the privacy lock is visible on the public study, with my own avatar as its user, but the collaborator avatars are not, since they depend on the last migration and it had not run there yet. The ship was already in progress when I started, and I expected it to complete within a minute or so.

At 1:46 I give the timing: from the start of the implementation in the previous part to the finalised delivery took approximately three hours, and since I went for a walk and to Sainsbury’s in that span the active work was probably closer to two. The project had been created eight hours earlier, so from ideation to delivery the feature took one day of work, alongside several other features delivered the same day.

The edge function is active at 2:35, staging has the full feature, and I open the share panel directly from the list, then show the mobile version and the list on a Pro Max iPhone. The mobile layout clamps titles to two lines, as agreed with the agent, although the items on screen are short enough to sit on one; a long title truncates in the middle, so the distinguishing part of the name stays visible across several versions of the same study. The live app then shows the same layout as staging.

5 min Watch on Loom

Two details in the recording are out of date. Its closing invitation to the pre-alpha is out of date, since that programme has ended. And it gives no time for the avatars: the ship is a progress bar I describe as moving pretty much everything from staging into the app, and the migration that had to run before they could appear is never shown running. One rule went into the ship skill after this run: merging to main is not a release; a release is the whole difference between main and prod, proven in a report-only pass before anything is written and stopped by a destructive match or a red batch.

Conclusion

A release covers everything merged since the last ship, whether that is one feature or several, so the decision to release is a decision about the whole batch, and the checks in the skill are sized to it: the survey names its risk areas, the dry run covers its migrations, staging runs its exact commits. The feature that prompted this ship was one row of that survey. The two environments on camera carry the other half of the point: code, schema and edge functions arrive on their own schedules, and whoever reads the list during a deployment needs to know which layer is behind a missing element before calling it a defect. The batch decision and the look at the product on a real device stayed with me; the survey, the dry run, the smoke and the watch to green did not.