KiteDocs
Guides

CI/CD and environment delivery

Validate, review, deploy, and roll back Customer Success configuration.

Test and live have isolated API keys, data, and active config versions. Treat a config change like an application change: review source, validate deterministically, exercise representative events, and require an explicit production approval.

Pull request checks

.github/workflows/kite-config.yml
name: Kite config
on: [pull_request]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: pnpm
      - run: pnpm install --frozen-lockfile
      - run: pnpm exec kite validate --strict

Run unit tests for event producers in the same pull request. For changes to historical definitions, deploy the branch to test and run kite recompute --all --dry-run; attach the impact summary to the review.

Headless CLI jobs authenticate with KITE_ACCESS_TOKEN and KITE_ORGANIZATION. Set KITE_API_URL when not using the default API. Store all three as protected CI secrets or variables, never in .kite/config.json or source control.

When kite deploy runs in GitHub Actions, the CLI automatically records the repository, commit, ref, workflow run, actor, and pull request when available. The config history in Kite links each deployment back to its commit and workflow. This provenance is audit metadata supplied by the authenticated workflow; keep the access token restricted to protected environments and trusted branches.

Delivery sequence

kite validate --strict
kite deploy --env test
kite config versions --env test
kite config diff
kite deploy --env live
kite config versions --env live

There is currently no immutable test-to-live promotion operation. deploy --env live recompiles the checked-out local source and creates a separate live version; it does not copy the tested version. To minimize drift:

  1. Deploy test and live from the same reviewed commit and locked dependencies.
  2. Do not rebuild from a mutable branch after approval.
  3. Archive the commit SHA and the returned test and live version IDs.
  4. Require a protected live environment and manual approval in the CI provider.
  5. Compare the deployed versions and run smoke events with the correct environment keys.

Live deployment always requires typing live, including when --yes is supplied. --force bypasses validation warnings, never compiler errors.

Configuration expressions receive the environment from .kite/config.json during compilation. Before deploying environment-dependent source, ensure defaultEnvironment matches the target; prefer definitions that do not branch by environment.

Rollback and state

kite config diff v12 v13
kite config rollback --env live --version v12

Rollback activates an existing version with an optimistic active-version check. It changes the definition used for future evaluation but does not reverse raw events or automatically rebuild customer state. Run a dry-run recompute, then a persisted recompute if existing state must conform to the restored version.

On this page