The assembled candidate’s parent pipeline passed verify_assembly.
Delivery-ledger MR !7 preserves v1 compatibility; it is one of three component changes.
Recorded synthetic parcel NTH-9681 is acknowledged by the unchanged v1 scanner.

The problem behind Northline

Delivery hardware can outlive several generations of backend software. A scanner may still do its job perfectly well while the services receiving its messages need new features. I built Northline around that practical constraint: a delivery team should be able to keep its older scanner while the software learns to carry a photo reference with newer deliveries.

Northline is a new synthetic delivery application for this event. It has a frozen original scanner and separately versioned intake, publisher and ledger services. A scan becomes a saved operation, moves through Pub/Sub and reaches a recorded delivery. The interesting question is whether the acknowledgement, parcel identity and delivery effect still agree when different service versions overlap or a message arrives again.

A release that follows the parcel

An operator starts one authorized release, and the Hands-off workflow takes it from there. Three fresh GitLab Duo Agent Platform investigations examine scoped failures in the intake API, event publisher and delivery ledger. Each proposes a small code change. The controller validates all three outputs before creating the component merge requests, checking their pipelines and assembling the parent application.

A separately protected GitLab build checks the complete candidate source and creates fixed application images. The rollout changes readers before writers, exercises compatibility in an isolated environment, promotes the checked versions and observes production. It then completes the exact component and parent source merges. Google Cloud supplies the real service boundaries through Cloud Run, Pub/Sub and PostgreSQL.

Hands-off describes the release after that initial authorization. Provisioning, access policy and recovery remain operator responsibilities. Duo proposes the code changes. The release controller handles the tests and deployment under the existing release policy.

The result I can show

The completed October 23 run contains three finished investigations, six successful release pipelines and four reviewed source merges. Its production test recorded twelve accepted operations and twelve effects with no pending work. Two additional recorded browser tasks then exercised the original NTH-9681 parcel and the photo-bearing NTH-9682 parcel, each producing one effect. The retained view reached fourteen accepted operations, fourteen effects and zero pending.

The film follows the newer parcel's photo reference through its saved operation and committed record, then returns to the original scanner's acknowledgement. Those are synthetic parcels sent through real deployed interfaces. These are the results of the recorded test run.

Challenges and lessons

The hardest part was keeping a successful production check attached to a complete source release. An earlier run reached production acceptance but stopped during source finalization. I kept that outcome uncertain and preserved its history. It could not stand in for a later completed run.

That experience changed the design: source merge completion became part of the same release story as the service update. I also learned to inspect the saved operation and final effect together, because a green build or a counter alone leaves important questions unanswered.

Northline is for backend teams with long-lived clients, particularly delivery and field-service workflows. Next I would broaden the delayed-message and failure cases and try the workflow with people who maintain those systems. The public console, MIT source, CI history and deployment recipes expose the current demonstration without giving visitors permission to start a rollout.

Try the project | MIT source and CI | Watch the demo