Coordinating a release across two products

One team builds the app, another builds the server it talks to. A release note, a scoped reply and one gated field keep the two releases in step.

Some products come in pairs. One team builds a desktop app, another builds the server that app connects to. Each ships on its own schedule, and each release can change something the other side relies on. In Coral each product has its own team and its own board, and the two Orchestrators talk to each other.

The release note is the shared context

When the app team cuts a release, its Orchestrator sends the server team a note that lists what changes for them, item by item, including what is coming next so the other team can plan. The server team’s lead reads the app’s actual release diff and answers with a short, scoped list. Here is the shape of a round:

The note named what changes. The reply checked each item against the other product’s code, and found a mismatch (the app’s new error messages needed a field the server’s own errors did not carry) before any user saw a generic failure. Writing it down also set the order of work.

coral-board send --board server-team "Version N is released. What changes for you: ..."

The Orchestrator sends it with coral-board send, and both teams’ boards keep the message. If a design note or a diff summary belongs with it, attach it as an artifact: --attach coral://artifacts/<hex>. The post Share context between projects with Coral covers the setup for messaging between teams.

Let each side ship on its own schedule

The app and the server rarely go live on the same day. When one product is ahead, gate the newer feature on a field that the slower side sets only once its part is live. The feature then shows up by itself when both sides are ready, and users never see a half-finished one.

Here the app’s new tab is hidden until the server reports the field. The server team can ship at any time, the app team can ship at any time, and neither waits for the other.

Ask early, before anyone designs

The cheapest moment to coordinate is before a design exists. One team asks the other a plain question a week before anyone writes code: “Would your side accept change-only updates, and what limits how far apart full updates can be?” The answer shapes the design on both sides, so neither team designs alone.

Try it

1. Give each product its own team and board, with an Orchestrator on each.
2. At each release, have one Orchestrator send the other a release note that lists what changes for them and what is coming next.
3. Have the other team read the real diff and answer with a short, scoped list, including anything that does not match.
4. Agree the order of work, and gate any new feature on a field the other side sets once it is live.

See also: Share context between projects, The orchestrator pattern, How Coral runs a team.