Releases

Ship changes from sandbox to production, and see exactly what moves

Build in development, compare with the next environment, choose what goes, and promote it as a release.

DevelopmentWhere changes are madeLatest changes

QAWhere changes are testedRelease 2.4

ProductionWhat your users seeRelease 2.3

Illustration. Compare any two environments, choose the changes, and apply them as a release you have reviewed.

The problem

Changing the app your customers use this morning is risky

Most tools edit production directly or hand you an export nobody can read.

How we solve it

Example: a customer asks for regional pricing. The reviewer sees exactly what changes, and nothing else.

1 Build and choose

2 Release 14: review the diff

Reviewed

3 Promote, one step at a time

Four changes, one script, nothing else. Work in progress stays in Development.

What you get

Everything the change needs to work in the next environment. Open a tile for detail.

Release · Development → QAIllustration

v15A configuration version
The changes you selected become a new version of the app in the target environment. Items you did not select stay as they were.
parents → childrenReference data, in a safe order
Choice lists and lookup tables move with the release, parents before children, so references never break halfway.
appliedfailedpendingMigration scripts
Scripts run in the target environment, each tracked as applied, failed or pending.
Only what you chose
Half-finished work in development does not leak into production.
+ added− deletedA readable diff
Added, updated and deleted items, for configuration and data, so someone who did not build the change can check it.
.csCode in the same release
Custom scripts are part of the configuration, so a rule written in code moves with the screens it belongs to.

Use cases

Illustrated apps, each with its records, approvals, screens and reports.

What each example covers

Purchase and expense approvals: Route every purchase request and expense claim to the right approvers, with deadlines.
Vendor onboarding: Collect supplier documents, review them properly, and approve new vendors with a record.
CRM and sales pipeline: Leads, accounts and deals shaped around how your team actually sells.
Intake forms with review: Forms that ask the right questions, then route each submission to the right reviewer.
Admin tools on an existing database: Put screens, roles and change history on tables you already have.
Scheduled operational reporting: The reports people ask for every week, built once and sent on time.

In a demo we make a change on a real app, show you the diff, and promote it.