Environments

Eventvisor does not have a separate environment entity. Use Sets when development, staging, and production need independent definitions, tests, state, and datafiles.

Initialize with environments#

$ npx @eventvisor/cli init --project=environments

This creates development, staging, and production Sets with a linear promotion flow.

Structure#

module.exports = {
  sets: true,
  tags: ["all", "web", "backend"],
};

Each directory below sets/ is an isolated project:

sets/
├── development/
│   ├── attributes/
│   ├── events/
│   ├── destinations/
│   ├── effects/
│   ├── targets/
│   └── tests/
├── staging/
└── production/

Commands process every environment by default. Select one with --set:

npx eventvisor lint --set=staging
npx eventvisor test --set=staging
npx eventvisor build --set=production

Generated datafiles are isolated below datafiles/sets/<set>. State uses .eventvisor/sets/<set>, generated code can be emitted per set, and the Catalog includes a set selector.

Promote changes between environments#

Restrict allowed promotion directions in eventvisor.config.js:

module.exports = {
  sets: true,
  promotionFlows: [
    { from: "development", to: "staging" },
    { from: "staging", to: "production" },
  ],
};

Preview first, then apply the reviewed plan:

npx eventvisor promote --from=development --to=staging
npx eventvisor promote --from=development --to=staging --apply --audit

See Promotions for selection, conflict, protection, and rollback behaviour.

When an attribute is enough#

You can model an environment as an ordinary attribute when all environments intentionally share the same definitions and datafile. Sets are safer when release lanes must remain independently buildable and deployable.

For more testing patterns, including matrices and environment-specific routing expectations, initialize test-environments:

$ npx @eventvisor/cli init --project=test-environments

Related#

• Sets
• Promotions