Skip to content

Applications with several artifacts#

An application is often made of several artifacts released separately: a frontend, a backend, the database migrations. Every artifact is a release of its own: environment configuration, queue, inventory, rollback, promotion and retention are per application, artifact and environment. The artifact is artifact.name, required in every descriptor.

# backend
application: shop
environment: prod
artifact: {type: war, name: shop-api, version: 1.5.0, source: https://repo.example.com/shop-api-1.5.0.war}
---
# frontend
application: shop
environment: prod
artifact: {type: tgz, name: shop-web, version: 3.2.0, source: https://repo.example.com/shop-web-3.2.0.tgz}
Per application, artifact and environment
Release in service (inventory) one entry per artifact
Queue partition (environment_concurrency) <app>+<artifact>/<env>: different artifacts deploy in parallel
Rollback, promotion, requires of the artifact
Retention keep_releases per artifact
Default schedule name <app>-<artifact>-<env>

artifact.name accepts letters, digits, ., _, : and - (at most 128 characters, starting with a letter or digit): it becomes part of queue partitions, keys and paths. The path of an image goes in source. An application with a single artifact usually names it after the application.

The order between artifacts (migrations, then backend, then frontend) is expressed with after or a composed release.

Environment configuration per artifact#

The templates of the providers contain {artifact}: one document per artifact, with nothing shared (common targets and secrets are repeated in every document).

manent.yml
envconfig:
  required: true                                   # a missing document is an error: it catches a misspelled artifact
  providers:
    - name: default
      type: file
      file:
        path: "envconfig/{tenant}/{application}/{artifact}/{environment}.yml"
      # consul:
      #   key: "manent/{tenant}/{application}/{artifact}/{environment}"

envconfig/
  untenanted/
    shop/
      shop-api/prod.yml
      shop-web/prod.yml
      shop-db/prod.yml
  • Tenant: untenanted is the tenant of the applications no tenant lists; the documents of a tenant's applications are under its name.
  • Names: an artifact.name that cannot be part of a path or key (e.g. team/api) is refused.
  • A template without {artifact} reads one document per application/environment, shared by all its artifacts.
  • descriptor_policy.secret_refs accepts {artifact}: vault:secret/{tenant}/{application}/{artifact}/{environment}/*.
  • manent env validate --artifact <name> checks a candidate document of an artifact.

Rollback, promotion and inventory#

manent inventory -a shop                              # one entry per artifact
manent rollback -a shop -e prod --artifact shop-api   # -A for short
manent promote -a shop --from staging --to prod -A shop-web
manent list -a shop -A shop-db
manent dora -a shop -A shop-api

With a single artifact in the environment --artifact can be omitted; with more than one the request is refused and the error lists them. In a composed release with onFailure: rollback every deploy is rolled back on its own artifact. Imports of the release in service (imports.<name>.current) take artifact too, required when the application has more than one artifact in that environment.

Permissions and governance per artifact#

Bindings, rules and freezes accept an optional list of patterns on artifact.name:

manent.yml
rbac:
  bindings:
    - groups: [web-team]
      role: deployer
      applications: [shop]
      environments: ["*"]
      artifacts: ["shop-web*"]       # only the deploys of these artifacts
governance:
  rules:
    - name: migrations
      applications: ["*"]
      environments: [prod]
      artifacts: ["*-db"]
      approvals: {required: 2}
  freezes:
    - name: frontend-freeze
      applications: [shop]
      environments: [prod]
      artifacts: [shop-web]
      from: 2026-12-20T00:00:00Z
      to: 2027-01-07T00:00:00Z
  • Bindings with artifacts apply only to the deploys of those artifacts, never to the actions on the whole environment (freezes, schedules listing): those need a binding without artifacts. The same field is accepted in the grants of a permission policy (data.manent.rbac.bindings, grants).
  • Rules with artifacts apply only to those artifacts; in Rego the library reads input.artifact.name.
  • Freezes with artifacts block only those artifacts; where the artifact is unknown (e.g. custom steps checking the environment) a partial freeze still applies. manent freeze add -A shop-web creates one at runtime.

Renaming an artifact#

A new artifact.name is a new release, without history. To keep it, rename the artifact in the history:

manent-server -c manent.yml admin rename-artifact [-t <tenant>] -a shop --from api --to shop-api [--dry-run]

It changes the artifact attribute of the ended deploys (and of their approvals and waits): inventory, rollbacks and promotions follow the new name, and a rollback releases the old version under the new name. Workflows not ended are listed in pending and left unchanged: run the command again when they end. The API processes rebuild their inventory within 10 minutes. Schedules keep the descriptor they were created with.