ZuloOne
English
CabinetAccount
Sign in
Menu

Lifecycle Portal: package, Test, Production

Updated

Click-path for shipping a .zulopkg is in User docs: Ship a package. This page is why the doors are split, what the CLI may do, and what breaks if you skip Test.

The portal is lcp.getzulo.com. The UI is English. It ships with Business and Enterprise. A smaller plan still has the stand; the Test–Production cycle is on those two.

Two doors#

A person signs in to a stand with their own account. That is where the models and the data are.

A pipeline talks to Lifecycle Portal with the tenant's CI credentials (left menu). That secret uploads a package and can install it on Test or Development. It must not be a stand login: a CI secret that could also read Production data is a wider grant than the job needs.

zulo package build makes the file. zulo release can upload it and install it on an environment the credential is allowed to touch. Production releases are not in the tool — a person presses Release {version} in the portal after Mark Ready for production. See the zulo guide.

What the package is#

A .zulopkg is a zip. On Upload a package the portal checks every file against the manifest and every model.json against what the manifest says, then stores it. The hint on the form names zulo package build or the GitHub Action.

NuGet packages that a developer restores so dotnet build succeeds are a different artifact. They never reach a tenant. Conflating them looks like “deploy a NuGet to Production”, which does not exist. The contour is in Shipping a model.

Why Test is the Ready evidence#

On the package page:

  1. Install on Test — validated against the environment, snapshotted, installed while it runs, rolled back if the models do not compile. Then the package's own tests run there. A successful Test install, tests green, is what a Ready mark rests on. Development installs change nothing for that mark.
  2. Mark Ready for production — an Owner or Release manager. With the two-person rule on (default, Release settings), it must be someone other than the person who uploaded it (or who created the CI credential that did). Turned off, the mark is stamped self-approved and stays so on the history.
  3. Release {version} — type the version to confirm. Production is validated, snapshotted, installed; rolled back if the models do not compile. Production has no rebuild-or-delete buttons.

CI cannot mark Ready. A pipeline that installed on Test still waits for a person.

A package that carries no tests can still be marked; the notice is that the mark signs an install that compiled.

Environments beside Production#

+ Deploy an environment creates Test or Development. Production is never deployed from that form. Data is Empty or A copy of production (mail and outbound switched off on the copy). Quota is on the plan; when it is full, delete or redeploy one before another.

Development can Open the workspace so a laptop mirrors the folder. Test is for proving a package. Do not treat a Development install as Ready evidence.

Logs are newest first and stay readable when the environment is stopped. Tests run the integration tests installed on that stand; a run rolls back what it writes, and it does load the environment while it runs.

People, roles, CI#

Left menu People and roles. An Owner invites by e-mail. The four roles and what they may do are listed on that page: Owner, Release manager, Developer, Viewer. Developer and Viewer may be limited to projects (Viewer on Production, nothing of the other projects). A tenant keeps at least one owner. A credential acts as the person who created it.

CI credentials (Owner or Release manager): GitHub Actions with no stored secret (trust a repository and ref) or a client secret shown once. Scopes: packages:write, environments:read, environments:write, releases:write, releases:production. The form says no scope marks Ready. releases:production only starts a release of a package already marked Ready.

Updates from Zulo#

On the environment: Update to {version} snapshots and restarts; if it does not come back healthy it is moved back. Production asks you to update Test first. After a Production platform bump, Ready packages are installed on Test again on the new image before the next Release. Install Zulo's model updates is a separate button, snapshot first, while the stand runs.

Backups and deletes#

Back up now on an environment (Production included) writes into Asset library → Database backups. Restore is onto Test or Development only, with the slug typed to confirm. Tenant backups are not auto-pruned. Copies Zulo took before an upgrade or an install sit under Taken by Zulo; they do not count against the limit.

Delete this package appears only when Installed on is nowhere. Type the version. Deleting the library row does not uninstall a stand.

What's not there yet#

  • No restore onto Production from the library. A Production backup is rehearsed on Test. Going back on Production is an upgrade rollback or a support path, not the Restore button.
  • No package delete while any stand still runs it. Install a newer version everywhere first, or delete the Test/Development stand that still holds it.
  • No production release from zulo. Deliberate: two people and a typed version live in the portal, not in CI.

Where next#

Was this page helpful?