bitzorcas
中EN

Guide

Deployment Overview

Plan BitzOrcas deployment from local Aspire to production Hosts, configuration, databases, observability, and commercial GA.

Last updated

BitzOrcas does not copy its local orchestration directly into one mandatory production topology. AppHost is for development. Production deploys API, JobHost, and optional Gateway independently, while the platform supplies databases, messaging, cache, secrets, and OTLP.

Host boundaries

HostResponsibilityProduction use
BitzOrcas.ApiHTTP, authentication, authorization, endpoints, lightweight fallback schedulingIndependent deployment
BitzOrcas.JobHostQuartz, workflow, audit retention, background workIndependent deployment
BitzOrcas.GatewayOptional edge entry pointProfile/topology dependent
BitzOrcas.AppHostLocal Aspire orchestrationNot a production artifact
ServiceDefaultsOTel, health checks, service defaultsReferenced by Hosts; not a process

Typical production dependencies

Ingress / Gateway
  → API
      → SQL Server
      → RabbitMQ / CAP Outbox
      → Redis
      → S3-compatible object storage
      → OTLP Collector


JobHost
  → SQL Server / RabbitMQ / Redis / S3-compatible object storage / OTLP Collector

Profiles and enabled modules determine the actual dependencies. The repository does not declare Kubernetes or one cloud template as the only production deployment method; infrastructure code needs review and rehearsal in the target environment.

Release sequence

  1. Prepare secrets, connection strings, License public keys, and persistent DeploymentId.
  2. Back up the database and apply unapplied migrations in order.
  3. Deploy API/JobHost without production traffic.
  4. Verify liveness, readiness, License state, and OTLP.
  5. Run Commercial GA for packaged delivery or the relevant CI/acceptance for source delivery.
  6. Shift traffic gradually and watch errors, latency, queue backlog, and database signals.
  7. Roll back at stop conditions; remove the old version only after observation.

See also

Minimum release evidence

Retain source commit, image or package digest, configuration version, migration list, SBOM/provenance, gate reports, approvers, start/end time, and rollback version for every release. Keep secret values out of the packet; record only their controlled version or reference.

Terminal window
# ① Verify public health semantics before traffic; never promote when ready fails.
curl -fsS "$CANDIDATE_URL/health/live"
curl -fsS "$CANDIDATE_URL/health/ready"


# ② Record an immutable image digest rather than a movable tag.
docker inspect --format='{{index .RepoDigests 0}}' "$IMAGE"

API and JobHost should reference one release batch while scaling and rolling back independently. Database migrations do not automatically roll back with an application image; every destructive change needs a forward fix or explicit recovery procedure.

Chapter Navigation

100%

Scroll or use controls to zoom · drag when enlarged · double-click for 100% / 200%