Environments and promotion

An environment such as devtest or production is defined once for the whole platform. Every project deploys into the same environments, in the order the platform administrator set, and every agent says which environments it serves.

The environments#

$ weikio get environments

NAME         ORDER   PRODUCTION   EVENTS BUDGET   ENTITY EVENTS   ENTITY STORE   GATEWAYS                      AGENTS
devtest      1       no           2 GiB           1 GiB           512 MiB        devtest (default)             2/2 online
production   2       yes          8 GiB           4 GiB           2 GiB          internal (default), partner   1/2 online

A platform administrator creates them, usually as documents in the platform’s own repository:

apiVersion: weik.io/v1
kind: environment
metadata: { name: devtest }
spec: { displayName: Dev and test, order: 1, isProduction: false, protection: { allowSecretReveal: true, allowLatestVersion: true } }
---
apiVersion: weik.io/v1
kind: environment
metadata: { name: production }
spec: { displayName: Production, order: 2, isProduction: true, protection: { allowSecretReveal: false } }

Each environment has its own event stream, entity store, dead letters and budgets, its own gateways and hostnames, and its own values of every variable and secret. A third environment, such as staging, is one more document.

What a production environment changes#

An environment with isProduction: true is protected in three ways:

• Every command that changes it needs --env, from the flag, the document or WEIKIO_ENV. The CLI never uses a production environment from a context, and a command that would prints the same command with --env added.
• A deployment pins a version. Following latest is refused unless allowLatestVersion is set.
• Secret values can stay hidden for good: with allowSecretReveal: false, not even a platform administrator can read a value there.

$ weikio deploy finance/erp-invoice-export     # the context's environment is production

error: --env is required to write to production environment 'production'.
       To go ahead, run:
         weikio deploy finance/erp-invoice-export --env production

Promote#

weikio promote copies a deployment from one environment to the next. Production gets exactly the version devtest ran, and nothing is rebuilt:

$ weikio promote finance/erp-invoice-export --from devtest --to production

Target: https://hub.example, project finance (argument), environment production (--to)
This will promote 'finance/erp-invoice-export' 1.1.0 to production environment 'production'.
Continue? [y/N] y
Promoting finance/erp-invoice-export 1.1.0 (latest) to production...
deployment production/finance/erp-invoice-export updated (version 1.0.0 -> 1.1.0, previous 1.0.0)
Agents: 1 of 1 running after 4.0 s

When devtest follows latest, production gets the version latest is at that moment, so production is always pinned. The previous version is kept for weikio rollback.

A promote checks production before it writes. When a secret the version needs has no value there, it stops with the commands that set it:

$ weikio promote finance/erp-invoice-export --from devtest --to production

Target: https://hub.example, project finance (argument), environment production (--to)
error: Can't deploy finance/erp-invoice-export 1.1.0 to production: secret 'erp-api-key' has no value.
       To set 'erp-api-key', run:
         weikio secret set finance/erp-api-key --env production
       To set it for this integration only, run:
         weikio secret set finance/erp-api-key --integration erp-invoice-export --env production

What changes per environment#

The version is the same in every environment. What differs is configuration:

Production keeps its own overrides when you promote into it. An API promotes the same way with weikio api promote finance/invoices@v1 --from devtest --to production, which serves the definition devtest tested.

Promotion from Git#

In a repository, promotion is a pull request that changes one line, the version in finance/production/deployments/erp-invoice-export.yaml. The production workflow applies it after the required reviewers approve. Keep integrations in Git has the workflows.