tonic-system-deploy_skill

This skill guides secure dual-environment deployments (UAT and PROD) with flow selection, approvals, and rollback readiness to minimize risk.

Python

2.5k

GitHub Stars

2

Bundled Files

2 months ago

Catalog Refreshed

3 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill openclaw/skills --skill tonic-system-deploy

_meta.json292 B
SKILL.md18.6 KB

Overview

This skill implements a dual-environment deployment workflow for systems with separate UAT and PROD environments. It codifies two deployment flows (UAT-first and PROD-first), emergency hotfix handling, rollback procedures, scheduled nightly pipelines, and Telegram notification templates. Use it to standardize approvals, automation nodes, and human checkpoints across scheduled and urgent releases.

How this skill works

The workflow starts with a version check and severity assessment to choose between Flow 1 (UAT-first, when UAT and PROD are aligned) and Flow 2 (PROD-first, when UAT is ahead). Scheduled cron jobs run Phase 1 (T1) and Phase 2 (T2) deploys, while human approval gates control promotion to PROD or UAT merges. Emergency hotfixes bypass cron windows for immediate deploys. Rollbacks follow a documented checklist with git/tag and DB migration steps, and Telegram messages keep stakeholders informed at each node.

When to use it

Planning a bug fix when UAT and PROD run the same version (choose Flow 1)
Fixing a PROD bug while UAT is ahead (choose Flow 2 / PROD-first)
Executing an emergency high/critical hotfix that cannot wait for T1/T2
Rolling back a deploy that introduced functional regressions or data risk
Designing an automated nightly deploy pipeline with human approval gates

Best practices

Always run the version check and severity assessment before selecting a flow
Keep T1 and T2 separated by at least 1–2 hours to allow human validation
Treat high/critical issues as emergency hotfixes — do not queue them
Maintain clear Telegram templates and notify stakeholders at each status change
Run a pre-deploy checklist (DB backup, monitoring, rollback path) before T1/T2
Document rollback steps and test them in UAT before relying on them in PROD

Example use cases

Nightly automated deploys: schedule Phase 1 at 20:00 and Phase 2 at 22:00 with approval buttons
Bug reported in PROD while UAT is two versions ahead — apply Flow 2 and cherry-pick fix to UAT later
Critical outage: perform an emergency hotfix, deploy to PROD immediately, then update UAT manually
Post-deploy regression detected: execute rollback to previous tag and run smoke tests
Onboarding a new project: define T1/T2, severity policy, notification channels, and status enums

FAQ

Flow 2 is used when UAT is ahead of PROD by any version or when validating in newer UAT would give false confidence for PROD fixes.

When should we perform an emergency hotfix?

Use emergency hotfixes for high or critical severity issues that cannot wait for scheduled T1/T2 windows; follow the hotfix checklist and notify stakeholders.

How are rollbacks executed?

Rollbacks use a verified previous tag/commit, apply down migrations if needed, run docker/service commands to revert, then perform a 5–10 minute smoke test and document findings.