Skip to content

Other Features

Staging

Staging

During multiple phases of using aeppic it is helpful to setup a well environment. With specific data, or a new version of the aeppic server without interfering with the active deployment.

In aeppic this feature is called Staging and it allows to start a new server instance accessing the same data (with some visibility policies applied). Changes done inside the staged environment are NOT visible or in any way transported back to the production deployment.

Prerequisites
  • The server must be reachable by subdomains
  • If https is used the subdomains must have valid certificates
  • The server must run in an environment with podman
  • The server must be able to access a repository server if staging requests a different aeppic-server version
  • The server must have enough resources (CPU, RAM, Storage) to run the stages.

Alternatives

In a full cloud setup staging can be manually accomplished some of the abilities of staging can be handled by fully cloning a machine and/or syncing data back, but even in this case it will be handy to boot with limited data visibility or stopping the import at a fixed point in time.

Example Use Cases

  • During development, to run business rules, workflows, commands, custom actions, etc. against reproducible data
  • During regression testing, to validate that updated designs or code still results in the same behavior
  • In production, to have a point-in-time look at an entire system in the past
  • For auditing, to have a point-in-time look at a system, but with certain non-audit relevant data removed

Architecture

The aeppic api has an interface under /v4/staging/ to inspect and interact with the stages.