agentleFS
Sign inStart free
xenitV1xenitV1/Antigravity-Workflows/skills/deployment-procedures/SKILL.md

deployment-procedures

Skill130 starsChanged 10 months agoMITView on GitHub

Production deployment principles and decision-making. Safe deployment workflows, rollback strategies, and verification. Teaches thinking, not scripts.

  • Commits and pushes

We split this skill into the rules it gives an agent

3 rules. 3 are common, 0 are distinctive, and 0 are very specific to this project.

  • 3

    Common

    Most of the 7 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Common:

    Every deployment is unique

    line 18
  2. Common:

    Rollback: If restart doesn't help

    line 190
  3. Common:

    Test rollback: before you need it

    line 237

“Common” is measured: kept by at least 6 in 10 of the 7 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Deployment Procedures

Deployment principles and decision-making for safe production releases. Learn to THINK, not memorize scripts.

⚠️ How to Use This Skill

This skill teaches deployment principles, not bash scripts to copy.

  • Every deployment is unique
  • Understand the WHY behind each step
  • Adapt procedures to your platform

1. Platform Selection

Decision Tree

What are you deploying?
│
├── Static site / JAMstack
│   └── Vercel, Netlify, Cloudflare Pages
│
├── Simple web app
│   ├── Managed → Railway, Render, Fly.io
│   └── Control → VPS + PM2/Docker
│
├── Microservices
│   └── Container orchestration
│
└── Serverless
    └── Edge functions, Lambda

Each Platform Has Different Procedures

PlatformDeployment Method
Vercel/NetlifyGit push, auto-deploy
Railway/RenderGit push or CLI
VPS + PM2SSH + manual steps
DockerImage push + orchestration
Kuberneteskubectl apply

2. Pre-Deployment Principles

The 4 Verification Categories

CategoryWhat to Check
Code QualityTests passing, linting clean, reviewed
BuildProduction build works, no warnings
EnvironmentEnv vars set, secrets current
SafetyBackup done, rollback plan ready

Pre-Deployment Checklist

  • All tests passing
  • Code reviewed and approved
  • Production build successful
  • Environment variables verified
  • Database migrations ready (if any)
  • Rollback plan documented
  • Team notified
  • Monitoring ready

3. Deployment Workflow Principles

The 5-Phase Process

1. PREPARE
   └── Verify code, build, env vars

2. BACKUP
   └── Save current state before changing

3. DEPLOY
   └── Execute with monitoring open

4. VERIFY
   └── Health check, logs, key flows

5. CONFIRM or ROLLBACK
   └── All good? Confirm. Issues? Rollback.

Phase Principles

PhasePrinciple
PrepareNever deploy untested code
BackupCan't rollback without backup
DeployWatch it happen, don't walk away
VerifyTrust but verify
ConfirmHave rollback trigger ready

4. Post-Deployment Verification

What to Verify

CheckWhy
Health endpointService is running
Error logsNo new errors
Key user flowsCritical features work
PerformanceResponse times acceptable

Verification Window

  • First 5 minutes: Active monitoring
  • 15 minutes: Confirm stable
  • 1 hour: Final verification
  • Next day: Review metrics

5. Rollback Principles

When to Rollback

SymptomAction
Service downRollback immediately
Critical errorsRollback
Performance >50% degradedConsider rollback
Minor issuesFix forward if quick

Rollback Strategy by Platform

PlatformRollback Method
Vercel/NetlifyRedeploy previous commit
Railway/RenderRollback in dashboard
VPS + PM2Restore backup, restart
DockerPrevious image tag
K8skubectl rollout undo

Rollback Principles

  1. Speed over perfection: Rollback first, debug later
  2. Don't compound errors: One rollback, not multiple changes
  3. Communicate: Tell team what happened
  4. Post-mortem: Understand why after stable

6. Zero-Downtime Deployment

Strategies

StrategyHow It Works
RollingReplace instances one by one
Blue-GreenSwitch traffic between environments
CanaryGradual traffic shift

Selection Principles

ScenarioStrategy
Standard releaseRolling
High-risk changeBlue-green (easy rollback)
Need validationCanary (test with real traffic)

7. Emergency Procedures

Service Down Priority

  1. Assess: What's the symptom?
  2. Quick fix: Restart if unclear
  3. Rollback: If restart doesn't help
  4. Investigate: After stable

Investigation Order

CheckCommon Issues
LogsErrors, exceptions
ResourcesDisk full, memory
NetworkDNS, firewall
DependenciesDatabase, APIs

8. Anti-Patterns

❌ Don't✅ Do
Deploy on FridayDeploy early in week
Rush deploymentFollow the process
Skip stagingAlways test first
Deploy without backupBackup before deploy
Walk away after deployMonitor for 15+ min
Multiple changes at onceOne change at a time

9. Decision Checklist

Before deploying:

  • Platform-appropriate procedure?
  • Backup strategy ready?
  • Rollback plan documented?
  • Monitoring configured?
  • Team notified?
  • Time to monitor after?

10. Best Practices

  1. Small, frequent deploys over big releases
  2. Feature flags for risky changes
  3. Automate repetitive steps
  4. Document every deployment
  5. Review what went wrong after issues
  6. Test rollback before you need it

Remember: Every deployment is a risk. Minimize risk through preparation, not speed.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free