Multiple Develop Environments

Most Bragi systems have one deployment chain: a Develop environment where Configs are written, and the Test and Production environments that work is deployed up through. A system can also hold more than one Develop environment, each at the top of a chain of its own.

Develop  ->  Test  ->  Production            (chain 1)
Develop Project  ->  UAT Project             (chain 2)
Sandbox                                      (chain 3 - a Develop environment on its own)

Holding more than one chain is a licensed feature. See Licensing below.

Why you would want another chain

A second chain gives a piece of work somewhere to live that never gets in the way of the first. A system has one Production environment, at the end of the main chain, and nothing deploys from one chain into another, so work in another chain cannot reach Production by accident. Common reasons to add one:

A long-running project alongside business as usual. A source system upgrade or migration can take months, and its Configs are not ready for Production until it goes live. Built in the main Develop environment, those half-finished Configs sit in every compare and have to be left out of every routine deployment. Built in a chain of its own, the project has its own Develop and Test to work and test in, while the main chain keeps releasing as normal.
A sandbox. A Develop environment with nothing below it is a safe place for training, trying out a new source, or prototyping. Nothing built there can be deployed anywhere.
A metadata backup. Re-seed Environment with Metadata Only turned on copies Configs into a Develop environment without touching its warehouse, keeping a record of what the Configs looked like that you can compare against or copy back out of later.

When not to add one

A chain is a separate line of work, not a separate place to test. If you only need somewhere else to run the same Configs - another UAT, a performance test environment, a pre-production copy - add an environment to the existing chain that deploys from the one above it. It then receives the same Configs through normal Deployments.

A chain is not a second live warehouse either. A system has one Production environment, so separate businesses or release cycles that each need to go live belong in separate Bragi installations, not separate chains.

Work that has to come back together later is also a reason for caution. Chains do not merge: once Configs are copied from one chain to another they are unrelated, and bringing a project's changes back into the main chain means exporting them as a .bra package, importing it into the main Develop environment and checking the result by hand. If a piece of work is small, or will finish soon, doing it in the main chain is usually simpler.

How chains work

Each environment records the environment it deploys from, and those relationships form a chain rooted at a Develop environment. Develop is the only kind whose Configs can be edited; the rest are read-only and receive changes through Deployments.

Chains are independent: nothing deploys from one chain into another, and a Develop environment is never a deployment target. The Compare and Deployment screens only offer targets within the source environment's own chain.

What belongs to a chain and what is shared

Belongs to one environment	Shared across the system, with a value per environment
Configs, Jobs and Code Libraries	Connections, File Sources and Variables

Each chain therefore holds its own Configs and Jobs. Connections, File Sources and Variables are defined once, so a new Develop environment needs a value set for every Connection, File Source and Variable its Configs use, the same as any other environment.

Give each chain its own warehouse

Two chains can hold Configs of the same name without confusing Bragi, which identifies a Config by its id and resolves dependencies within a single environment. The warehouse is a different matter. If two chains write to the same warehouse database, two Configs of the same name are two Configs owning one physical table, and they will overwrite each other's data and structure.

Moving work between chains

Because nothing deploys across chains, work moves between them by copying:

Re-seed Environment copies Configs from any environment in one chain, such as its Develop or Production, into the Develop environment of another, building the warehouse objects to match. Anything the target already holds is deleted and re-added rather than updated, and the target can optionally be cleared out first.
Export a .bra package from one chain with Export Package and bring it into the other with Import Package. This also works between separate Bragi installations.

Re-seed Environment only copies into the other chains: the main chain, which deploys to Production, is never its target. Bringing a project's work back into the main chain is done by exporting it as a .bra package and importing it into the main Develop environment.

Either way the result is a set of new Configs in the target chain. They carry no shared history with the Configs they came from, and a compare between the two chains will not pair them up. From there they are deployed up the target chain in the usual way.

Licensing

The chain that is always licensed is the one rooted at the Primary Develop Environment.

Adding a second chain

A new Develop environment starts a second, empty deployment chain. On Administration > Environments, add an environment with its Definition set to Develop and Deploys From left as -, then set up the chain below it by adding environments that deploy from it.

Before it can be used:

Give it a warehouse Connection String of its own - see Give each chain its own warehouse.
Give every Connection, File Source and Variable the chain needs a value for each new environment.
Bring in the Configs it starts from with Re-seed Environment or a .bra package, or author them fresh.
Upload the Code Libraries its Code Configs need, or run Copy Additional DLLs on the Upgrade screen, which copies the DLL folder into every Develop environment.
Add each new environment's code to the scheduler's BragiConfig:EnvironmentCodes configuration and restart the scheduler service, so its Jobs run. See Environment Codes.

The Primary Develop Environment stays where it is. Anything resolving without an environment - the external API's Export links, a code test project that is not given an environment - keeps resolving to the original chain, and that chain stays first in every list of environments. A Code Config project downloaded from the new chain is given its Develop environment, so it runs there.

A system holds only one Production environment, so the new chain's other environments are Test ones.

Removing a chain

Delete the environments in the chain from the bottom up on the Environments page: an environment that others deploy from cannot be deleted, and neither can the primary Develop environment. If the chain holds work you may want later, copy or export its Configs first.

02 October 2026