🎁 Get the FREE AI Skills Starter Guide β€” Subscribe β†’
BytesAgainBytesAgain
πŸ¦€ ClawHub

DevOps

by @ivangdavila

Automate deployments, manage infrastructure, and build reliable CI/CD pipelines.

Versionv1.0.0
Downloads7,423
Installs65
Stars⭐ 5
TERMINAL
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 simultaneously
  • Deployment 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 stages
  • Infrastructure 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 prod
  • Containers

  • 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 deployed
  • Secrets 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 expected
  • Monitoring & 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 better
  • Reliability

  • 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 people
  • Common 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 too
  • Networking

  • 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