CyberStrikeAI/docs/en-US/release-process.md

Release Process

中文

Use this guide for maintainers and operators preparing upgrades or releases.

Pre-Release Checklist

• README and docs updated.
• config.yaml sample includes new fields.
• OpenAPI includes new endpoints.
• i18n updated when frontend text changed.
• Security docs updated for high-risk capabilities.

Release Risk Tiers

Change	Risk	Must test
Docs/assets	low	links/rendering
Frontend	medium	login, page states, API errors
Handler/API	medium	OpenAPI, auth, errors
Config struct	high	old config compatibility, ApplyConfig
DB schema	high	old DB migration, rollback
Agent/MCP/HITL	high	tools, approvals, streaming
C2/WebShell/Terminal	critical	authorized lab, audit, disable switch

Release notes should call out risk, not just features.

Config Compatibility

New fields should:

• have safe defaults;
• allow old configs to start;
• be documented in sample config.yaml;
• not cause Web settings to delete unknown fields;
• be tested via restart and hot-apply paths.

Avoid default-enabling high-risk capabilities.

Database Changes

SQLite migrations must be:

• compatible with old versions;
• idempotent after interruption;
• careful with nullable/default fields;
• mindful of large indexes and locks;
• documented with backup instructions.

Build and Test

go test ./internal/...
go test ./cmd/...
go build -o cyberstrike-ai ./cmd/server

Manual smoke:

login -> model test -> new chat -> tools -> HITL -> KB -> external MCP -> C2 enable/disable

Rollback

Restore binary/code, config.yaml, and data/ together. If a new version changed DB schema, replacing only the binary is not a reliable rollback.