Continuous delivery is great

But why wait for a release every time you want to try the app in production? A branch already represents a version of the application. CI already builds it. In many setups, the backend is already deployed into a preview environment.

Testing the actual client, however, still often means waiting for a release, downloading another build, reinstalling the application, somehow keeping multiple versions around, and remembering which backend belongs to which frontend. That makes trying a branch much more expensive than creating one.

A branch can become a release channel

A release does not have to be the only deployable version of an application. A branch can become a release channel. That is the approach being added to Agent-Up.

Branches prefixed with a ticket number become channels. For example:

235-avalonia-mobile-client

becomes channel 235. Every commit can then produce an immutable build:

rc-235-f32a77d

The installed frontend can select channel 235, check the newest available version, and update directly to it. There is no reinstall, no separate app, and no waiting for the feature to reach the normal release pipeline. The installed application stays the same. Only the version behind the selected channel changes.

That creates a much shorter feedback loop:

1. Push a change.
2. CI builds it.
3. The channel moves forward.
4. Update the installed client.
5. Test the actual production build.

A channel can represent the complete environment

The same idea becomes more interesting when the backend is included. A branch does not only have to produce a frontend artifact. Its backend can be deployed as well.

For Agent-Up, that means a channel can eventually represent the complete environment:

• The frontend build
• The headless Agent-Up Server
• The behavior currently being developed on that branch

Selecting another channel can therefore mean switching more than the UI. It can mean connecting to another automatically deployed server instance running the corresponding branch.

Branches stop being only source-code boundaries. They become runnable environments.

There are some obvious advantages: much faster production-like feedback, no repeated reinstall cycle, easier testing before merge, easier reproduction of branch-specific behavior, the ability to exercise frontend and backend changes together, and cheap switching between implementations.

The difficult part is compatibility

But there is a cost. A cached frontend might stay on rc-235-abc1234 while the backend for channel 235 has already moved several commits ahead. That means a channel cannot be treated as permission to break everything on every push.

Ideally, most changes inside a channel are additive:

• New endpoints
• Optional fields
• New behavior
• Internal fixes

They should not be renamed contracts, removed fields, incompatible protocol changes, or destructive migrations that older clients cannot understand. Otherwise, every frontend version would have to be locked to exactly one backend deployment. At that point, the channel starts becoming another release system.

There are other costs too: more infrastructure is kept alive, stale channels need cleanup, every deployed branch increases the exposed surface, database migrations become more complicated, and compatibility testing becomes more important. Release channels are not free.

But neither is waiting for every change to become a release before it can be tested properly. Continuous delivery shortened the distance between a commit and production. Release channels can shorten the distance between a branch and actually using it.

For Agent-Up, that seems worth exploring. A branch should not only be something that can be reviewed. It should be something that can be used.

Download Agent-Up:

https://agent-up.themassiveone.net/

GitHub:

https://github.com/agent-up-oss/agent-up/