PUBLIC ALPHABiztraak is now in public alpha. Share feedback
Biztraak
Core Concepts
Projects Components Component Settings Service Providers Deployments Domains Build Reviews Federated Apps

Deployments

Deployments in Biztraak are about moving work from change to running state with visibility, review, and operational context attached. The platform keeps infrastructure execution, code rollout, build reviews, and release status closer together than a typical fragmented delivery stack.


What a Deployment Means in Biztraak

A deployment is not only “push code live.” It is the recorded delivery workflow for application changes and, where relevant, the infrastructure those changes depend on.

Application deployments move code through build, review, and production workflows.

Infrastructure deployments provision or update the resources a system needs to run.

Operational visibility stays attached through logs, outputs, deployment state, and related project context.

Deployment pipeline and status view in Biztraak
Biztraak keeps build progression, deployment state, and supporting outputs attached to the same workflow.

Two Related Deployment Layers

Biztraak separates infrastructure execution from application rollout, but keeps them connected.

Infrastructure Deployments

Provision or update the cloud resources, networking, storage, identities, and supporting services a system relies on.

Application Deployments

Build, review, release, and operate the code that runs on top of that foundation.

That distinction matters because most teams change application code more often than they change infrastructure. Biztraak keeps both parts visible without forcing them into the same exact release rhythm.

Typical Deployment Flow

A common project flow looks like this:

  1. Change code or configuration inside a project component.
  2. Create a build review or release candidate so the change can be validated in context.
  3. Promote or deploy once the change is ready for a longer-lived environment.
  4. Track status and outputs through logs, deployment state, and project views.
  5. Follow related infrastructure state if the workload depends on resource changes.

The key idea is traceability: you should be able to see what changed, where it was deployed, and which environment it now belongs to.

What users usually Watch during a Deployment

Users typically care about a few practical signals during rollout:

  • whether the deployment is still running, succeeded, or failed
  • which component and environment the rollout belongs to
  • what logs or outputs are available from the run
  • whether the release is a review environment or production path
  • whether supporting infrastructure changes were part of the same broader delivery event

Deployments connect those signals back to the project that owns the work.

Deployment workflow map

Use the related pages for deeper deployment workflows:

Together, these pages cover the main deployment lifecycle from validation through runtime operation.

Next steps

Build Reviews

Preview and validate changes before promoting them into longer-lived environments.

Infrastructure Deployments

Understand the provisioning layer that supports running workloads.

Build &. Deploy

See how source changes move through pipeline workflows.

Deploy Web Services

Follow the runtime path for hosted application workloads.