Skip to content

Guided tour

FabrCore 2.0 · Release and package availability

These guides track the current 2.0 source. Stable 2.0.0 publication is pending; package commands show the release target. Until it is published, follow the source quick start or use a matching available prerelease set. Release migration · Runtime modes

MODULE 13 · LESSON 13.10

Complete the deployment and operations runbook

Deploy with a repeatable rollout and recovery procedure.

Lesson 83 of 86 · FabrCore 2.0

Overview

A successful application build is only one part of a deployment. Cluster networking, schema, protected keys, environment configuration and readiness all participate. Rollback must account for data/schema compatibility as well as binaries.

A rollout changes several coupled resources

Binaries, schema, model configuration, provider settings and protected keys must describe a compatible application. Stage those changes in a known order and distinguish publishing configuration from restarting consumers. A binary rollback cannot automatically reverse a schema migration or an external business effect.

Readiness needs an application-level check

A live HTTP process is useful but insufficient. The actual product may require agent discovery, chat, a durable record, knowledge retrieval and one external integration. Choose the checks that match enabled features and preserve the evidence of what passed. A restore rehearsal should include key material and operation reconciliation, not just database import.

Write the deployment and recovery runbook

  1. Deploy matching Host/SDK/agent versions to staging, apply supported database changes and load secrets/certificates through protected infrastructure.
  2. Check health/readiness, effective config, agent discovery, chat, knowledge and external integrations. Exercise a controlled restart and restore before production rollout.
  3. Roll out in bounded groups, monitor errors/usage and preserve a tested rollback path. Configure retention, backups and incident ownership; use Azure hosting/storage/Key Vault when appropriate to your environment.
SQL · reference snippet 
{
  "ConnectionStrings": {
    "FabrCore": "Server=localhost;Database=fabrcore;Integrated Security=true;TrustServerCertificate=true"
  }
}
SQL · reference snippet 
{
  "FabrCore": {
    "Database": {
      "ConnectionStringName": "FabrCore",
      "AutoInitialize": false
    }
  }
}

Rehearse a bounded staging rollout

  1. Deploy the declared package/schema/configuration baseline to staging and record readiness plus an echo request. Then run the enabled AI, persistence, knowledge and external integration checks appropriate to the product.
  2. Restart deliberately and verify the records/grants expected to persist. Exercise the documented rollback/restore path in an isolated environment before approving production rollout.
  3. Record target identifiers, versions, verification results, known gaps and recovery ownership in the runbook. Stop expansion when a required check fails instead of treating it as an unrelated warning.

The useful artifact is a repeatable sequence with observable gates and recovery instructions. It describes the actual enabled application rather than every optional feature in the tour.

If the result is different

A config rollback does not roll back a schema migration or external side effect. Do not proceed based solely on a green process health endpoint.

Go deeper

Explore the related documentation.