Feature deep dive

Environments: controlled releases from DEV through TEST to PROD

Several efforts run in DEV at once, and a release usually takes only a few of them. Pick the work that is ready, and Model One builds the next release of TEST or PROD with everything that work needs, checks it, and writes the migration and dbt project for exactly that state. Each stage decides who approves it; your team or your pipeline deploys it.

Request a trial Back to features

The Environments tab with DEV, TEST and PROD side by side: each stage's target databases and the version the ledger records each one running, a drift check of PROD's database, the release each stage holds with its downloads, Promote…, and the efforts waiting in the stage before

Overview

Promote work, not models

DEV, TEST and PROD are not three copies of the model to keep in step. They are three places a selection of finished work has reached.

A warehouse team rarely ships everything at once. Several efforts run in DEV at the same time, a release usually takes only a few of them, and a source table can feed two entities when only one of them is ready. Copying a whole model from one environment to the next ships the unfinished work with the finished, so teams fall back on hand-picked scripts and a spreadsheet of what went where.

In Model One, DEV is the live project people model in together, and every change counts toward the work item its author is working on. TEST and PROD each hold a release: a version of the model that nobody edits, which changes only when a promotion, a removal of work or a rollback is deployed into it. So “what is in PROD?” is answered on the Environments tab, effort by effort.

A promotion takes whole efforts, single work items or individual pieces. Model One brings along what they need, carries the matching change of anything they would break, and checks the release with the same rules as a save. It then writes the migration of each target database, the dbt project and the release notes for exactly that release. PROD takes its values from TEST's release, so what reaches production is what was tested.

Model One still deploys nothing and never connects to your databases. Each stage sets its own approvers and checks, a person or the stage's pipeline runs the approved files, and a person confirms each deployment.

Walkthrough

One effort from DEV to PROD

Six steps, from defining the stages to catching a change someone made straight in PROD.

Step 1

Define the stages, and see what each one holds

An owner adds the environments in order: the live project first, usually DEV, then stages such as TEST and PROD. Each stage names the physical models it deploys and the target database each one is recorded under. The Environments tab gives every stage a column: its targets, the release it holds with its files, the promotions on their way in and the efforts waiting in the stage before. Open any release to read it in the modelling views.

Up to 20 stages in order; the live project comes first and holds no release
DDL, dbt project and migration downloads for each stage, generated from what it holds
One dbt project for every stage, with a profiles.yml target for each environment
A stage's release, or any version, opens read only in the Logical, Flow, Dictionary and Physical views

Step 2

Let every change name the work it belongs to

Each person picks the work item they are working on, and their changes to the model count toward it, as do the changes OneAssist and their agents make for them. An effort is a work item and everything below it, such as an epic and its stories, so the project knows what each effort changed. Each stage's column shows the efforts waiting in the stage before, how many changes each one has, and where two of them changed the same thing.

Changes made with no work item picked wait for an editor to assign them
Earlier work, imports and restores attributed from a comparison with a version
An owner can require a work item for every change to the model
A work item shows a chip for each stage that holds it

Tasks and the work you are on

TEST's and PROD's columns: the Sales Mart waiting in DEV, the four efforts TEST holds and the same four waiting in TEST for PROD with their numbers of changes, and the order-to-cash epic that PROD holds only in part

Step 3

Pick the work that is ready, and get what it needs

Promote… opens a wizard. Tick the efforts waiting in the stage before, add single work items, or compare the two stages and tick pieces one by one. Model One builds the next release from the one the stage holds, with the picked changes taken from the stage before: the live model for TEST, and TEST's release for PROD. It shows what comes along and why, the related changes it only offers, and the overlaps where two work items changed the same field.

Pick whole efforts, single work items, or pieces such as one attribute, one column setting or one Flow step
What a pick needs comes along: an attribute brings its entity and term, a Flow its entities and source objects
Removing something the stage still uses brings the matching change, or is refused with the reason
A source object two efforts share goes with the first that is ready, without the other's columns
Graphs and concepts are promoted like the rest of the model

The Promote wizard into PROD on its What comes along page: the entities, Flow and relationship of the two picked efforts, then the source object and source system the Flow needs, each with why it comes along

Step 4

Check it, approve it, and deploy what was approved

Before a promotion can be requested, Model One checks the release with the same rules as a save, judging only what the promotion introduces. Each stage has its own approvers and checks. The migration of each target database, the dbt project and release notes grouped by effort are recorded with their SHA-256 when the promotion is requested, and a file that no longer matches is refused. A person or the stage's pipeline runs them, and a person confirms the deployment with Mark deployed.

From no approval, where the person promoting decides, to several named approvers
Checks per stage, such as work items In Review for TEST and Done for PROD
A migration that renames a column a Flow reads ships with the dbt redeploy as one deployment, migration first
A promotion whose stage moved on meanwhile is marked stale and requested again
Model One deploys nothing: a person confirms each file deployed

The Promote wizard's Checks page for a promotion into PROD: every check of the stage passed, then the findings in the composed release and the dbt project it generates

Step 5

Hand each release to your pipeline in Git

Connect the project to a repository on GitHub or Azure DevOps (github.com or dev.azure.com), and an owner can have each approved release of a stage committed to that stage's own branch and folder, tagged with the stage and the version, such as prod-v14. The commit holds exactly the approved files, numbered in the order they are deployed, with the release notes and a manifest. Its message links every work item back to Model One, so an issue in Jira or Azure DevOps can refer to it.

One commit per release, on a branch for each stage such as model-one/prod
The migration, the dbt project, the release notes, the full DDL and a manifest of every file's SHA-256
Model One never rewrites a branch, and warns when someone changes the stage's folder
Send the current model or any version to Git too, from Import / Export or the version timeline

Step 6

Find what changed in PROD outside Model One

Every change should reach PROD through DEV and a promotion, but someone can still change the database directly. Model One never connects to it. Instead, paste or upload the database's exported schema, and a drift check compares its tables, columns, types, nullability and keys with what the stage's release creates. Adopt a difference into DEV, download a script that reverts it, or accept it as known with a reason.

The export is read by the SQL DDL import's parser, in the target's own dialect
Adopt into DEV records the differences in a Bug and makes the changes that map onto the model
Revert writes a script back to the release, with data-losing steps commented out
An owner can require a recent drift check with nothing unresolved before any promotion

The drift report of PROD's production database: three open differences by table, each with what the release and the database say, and two of them picked for Adopt into DEV, Revert or Accept as known

Highlights

Built for how releases really go

Partial releases, urgent fixes and the occasional step back.

PROD gets what TEST held

A promotion into PROD takes its values from TEST's release, not from DEV, so what reaches production is what was tested.

A way back

Take an effort back out of a stage, or roll a stage back to an earlier release. Both are approved and deployed like a promotion, and the migration back keeps its data-losing steps commented out.

A hotfix fast track

Where an owner allows it, an urgent fix made in DEV goes straight to PROD. The requester says why, the release history records it, and every other check still applies.

Every release readable

Open what any stage holds in the modelling views, read only for everybody, owners included. A version an environment holds or held cannot be deleted.

Roles that fit a release

Owners define the stages and their rules, Owners and Members promote, the approvers each stage names approve, and Viewers read every stage without the controls.

Agents preview, people decide

OneAssist and your own agents can preview a promotion, a removal or a rollback and read drift reports. Approving and deploying stay a person's acts.

Keep exploring

What a release is made of

A release composes the work done in every other module.

Walk one effort from DEV to PROD with us

Bring a release you shipped recently. We will promote one effort of it through TEST to PROD while the rest stays in DEV: the picks, what comes along, the checks, the approval, the scripts and the confirmed deployment.

Book a demo Compare plans