Jean-Gabriel Gill-Couture
0b71c1031b
All checks were successful
Run Check Script / check (pull_request) Successful in 2m26s
A `harmony-fleet-operator-v*` tag builds + publishes the operator image and chart via harmony-fleet-release (tag parsing in Rust, not YAML). deployment-process.md documents the release + manual `harmony apply` + roll-forward loop. Slim variant of ci/fleet-cd-pipeline: release job only. The staging-auto / prod-gated deploy jobs are deferred to the PR that provisions cluster credentials, where they can actually run.
71 lines
2.4 KiB
Markdown
71 lines
2.4 KiB
Markdown
# Fleet operator — release & deploy
|
|
|
|
How the operator ships: build + publish a versioned image and helm
|
|
chart, then `harmony apply` (a plain `helm upgrade --install` of that
|
|
published chart). No Argo, no GitOps controller — Harmony owns the loop
|
|
(ADR-012-2). CD is **roll-forward only**: to back out a bad release,
|
|
deploy a previous good version.
|
|
|
|
## 1. Cut a release (automated on tag)
|
|
|
|
```sh
|
|
git tag harmony-fleet-operator-v0.0.2 && git push --tags
|
|
```
|
|
|
|
The `harmony-fleet-operator` workflow builds the image and the hydrated
|
|
helm chart and pushes both to `hub.nationtech.io` at `0.0.2`. No human
|
|
touches a Dockerfile, chart, or registry.
|
|
|
|
Laptop fallback (does exactly what the workflow's job does):
|
|
|
|
```sh
|
|
# docker + helm must be logged in to hub.nationtech.io first.
|
|
cargo run --release -p harmony-fleet-deploy --bin harmony-fleet-release -- \
|
|
--from-tag harmony-fleet-operator-v0.0.2
|
|
|
|
# build + package only, no push (local k3d smoke-test):
|
|
cargo run -p harmony-fleet-deploy --bin harmony-fleet-release -- \
|
|
--from-tag harmony-fleet-operator-v0.0.2 --no-push
|
|
```
|
|
|
|
## 2. Deploy a published version (`harmony apply`)
|
|
|
|
`--operator-chart-version` switches the operator to install the
|
|
published `oci://hub.nationtech.io/harmony/harmony-fleet-operator:0.0.2`
|
|
chart instead of rendering one from local source. Same command
|
|
bootstraps and upgrades; re-running with the same version is a no-op.
|
|
|
|
```sh
|
|
export HARMONY_FLEET_NATS_ADMIN_USER=… HARMONY_FLEET_NATS_ADMIN_PASS=…
|
|
export HARMONY_FLEET_NATS_DEVICE_USER=… HARMONY_FLEET_NATS_DEVICE_PASS=…
|
|
|
|
harmony-fleet-deploy \
|
|
--filter FleetOperatorScore \
|
|
--operator-chart-version 0.0.2 \
|
|
--namespace fleet-system \
|
|
--yes
|
|
```
|
|
|
|
## 3. Roll forward
|
|
|
|
Same command, a newer (or previous-good) version:
|
|
|
|
```sh
|
|
harmony-fleet-deploy --filter FleetOperatorScore --operator-chart-version 0.0.3 --namespace fleet-system --yes
|
|
```
|
|
|
|
`helm upgrade --install` applies it and fails loudly if convergence
|
|
fails — no automatic rollback. Fix the spec, bump, re-run.
|
|
|
|
## Automated vs. manual
|
|
|
|
| Step | Where |
|
|
|---|---|
|
|
| Build + push image + chart on tag | CI (`release` job) |
|
|
| Deploy a published version + roll forward | Manual `harmony apply` (above) |
|
|
|
|
A staging-auto / production-gated CD job is a follow-up — it needs the
|
|
cluster `KUBECONFIG` + NATS secrets provisioned, which is out of scope
|
|
for the initial CD branch (ADR-012-2). The release job is fully
|
|
functional today.
|