DevOps
by @ivangdavila
Automate deployments, manage infrastructure, and build reliable CI/CD pipelines.
clawhub install devops
π About This Skill
name: DevOps
description: Automate deployments, manage infrastructure, and build reliable CI/CD pipelines.
metadata: {"clawdbot":{"emoji":"π§","os":["linux","darwin","win32"]}}
DevOps Rules
CI/CD Pipelines
Fail fast: run linting and unit tests before expensive integration tests β saves time and compute
Cache dependencies between runs β npm install on every build wastes minutes
Pin action versions with SHA, not tags β actions/checkout@v3 can change, SHA is immutable
Secrets in environment variables, never in code or logs β mask them in CI output
Parallel jobs for independent steps β test, lint, and build can run simultaneouslyDeployment Strategies
Blue-green: run new version alongside old, switch traffic atomically β instant rollback by switching back
Canary: route percentage of traffic to new version β catch issues before full rollout
Rolling: update instances incrementally β balance between speed and risk
Always have rollback plan before deploying β know exactly how to revert
Deploy the same artifact to all environments β build once, promote through stagesInfrastructure as Code
Version control all infrastructure β terraform, ansible, cloudformation in git
Never apply changes without plan/diff review β terraform plan before apply
State files contain secrets β store remotely with encryption, never in git
Modules for reusable components β don't copy-paste infrastructure definitions
Separate environments with workspaces or directories β dev changes shouldn't affect prodContainers
One process per container β containers are not VMs
Health checks are mandatory β orchestrators need them for routing and restarts
Don't run as root β use non-root USER in Dockerfile
Immutable images: config via environment, not baked in β same image in all environments
Tag images with git SHA, not just latest β know exactly what's deployedSecrets Management
Never store secrets in environment files committed to git β use vault, sealed secrets, or CI secret storage
Rotate secrets regularly β automation makes rotation painless
Different secrets per environment β dev leak shouldn't compromise prod
Audit secret access β know who accessed what and when
Secrets in memory, not disk when possible β temp files persist longer than expectedMonitoring & Alerting
Four golden signals: latency, traffic, errors, saturation β start here
Alert on symptoms, not causes β "users seeing errors" not "CPU high"
Every alert must be actionable β if you can't do anything, it's noise
Dashboard per service with key metrics β one glance shows health
Structured logs (JSON) for machine parsing β grep works, but queries are betterReliability
Define SLOs before building alerting β what does "healthy" mean for this service?
Error budgets: some failures are acceptable β 99.9% means 8 hours downtime/year is OK
Chaos engineering in staging β break things intentionally before prod breaks accidentally
Runbooks for common incidents β 3am is not the time to figure out recovery steps
Post-mortems without blame β focus on systems, not peopleCommon Mistakes
SSH into prod to fix things β all changes through automation, or you'll forget what you did
No staging environment β "works on my machine" doesn't mean works in prod
Ignoring flaky tests β they erode trust in CI, either fix or delete
Manual steps in deployment β if it's not automated, it'll be done wrong eventually
Monitoring only happy paths β check error rates and edge cases tooNetworking
Internal services don't need public IPs β use private subnets, expose only load balancers
TLS everywhere, including internal traffic β zero trust, even behind firewall
DNS for service discovery β hardcoded IPs break when things move
Load balancer health checks separate from app health β LB needs fast response, app health can be thorough
Firewall default deny β explicitly allow what's needed, block everything else