Awesome-omni-skill django_devops
Enterprise Django 6 DevOps — containerization, CI/CD, environment management, database deployment, monitoring, and production readiness checklist.
install
source · Clone the upstream repo
git clone https://github.com/diegosouzapw/awesome-omni-skill
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/diegosouzapw/awesome-omni-skill "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/backend/django_devops" ~/.claude/skills/diegosouzapw-awesome-omni-skill-django-devops && rm -rf "$T"
manifest:
skills/backend/django_devops/SKILL.mdsafety · automated scan (medium risk)
This is a pattern-based risk scan, not a security review. Our crawler flagged:
- pip install
- references .env files
- references API keys
Always read a skill's source content before installing. Patterns alone don't mean the skill is malicious — but they warrant attention.
source content
Django DevOps Skill
Purpose
Define and enforce DevOps standards for building, deploying, monitoring, and operating enterprise Django 6 systems with Strawberry GraphQL, SSE, Celery, Redis, and PostgreSQL.
Scope
- Containerization (Docker)
- CI/CD pipeline design
- Environment management
- Database migration deployment
- Health checks and readiness probes
- Logging and monitoring
- Secrets management in deployments
- Scaling and resource allocation
- Backup and disaster recovery
Responsibilities
- ENFORCE containerized deployments.
- ENFORCE CI/CD with automated testing and migration validation.
- ENFORCE environment parity across development, staging, and production.
- ENFORCE structured logging and monitoring.
- ENFORCE health check endpoints for orchestrators.
- PREVENT manual deployments without CI/CD.
- PREVENT unreviewed migrations in production.
- PREVENT secret leakage in CI/CD logs or Docker images.
Mandatory Rules
ALWAYS
- ALWAYS containerize the application with a multi-stage Dockerfile:
# Stage 1: Builder FROM python:3.12-slim AS builder WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir --prefix=/install -r requirements.txt # Stage 2: Runtime FROM python:3.12-slim WORKDIR /app COPY --from=builder /install /usr/local COPY . . RUN python manage.py collectstatic --noinput EXPOSE 8000 CMD ["gunicorn", "CMS.asgi:application", "-k", "uvicorn.workers.UvicornWorker", "--bind", "0.0.0.0:8000"] - ALWAYS use ASGI server (Uvicorn/Daphne/Hypercorn) for production. Never use Django's
.runserver - ALWAYS implement health check endpoints:
# urls.py path('health/', HealthCheckView.as_view(), name='health-check'), path('health/ready/', ReadinessCheckView.as_view(), name='readiness-check'),- Liveness (
): Returns 200 if the process is alive./health/ - Readiness (
): Returns 200 if DB, Redis, and Celery are reachable./health/ready/
- Liveness (
- ALWAYS run migrations as a separate step in deployment, BEFORE starting new application instances:
# CI/CD Pipeline steps: - name: Run migrations run: python manage.py migrate --noinput - name: Deploy new version run: kubectl rollout restart deployment/cms-api - ALWAYS validate migrations in CI before deployment:
python manage.py makemigrations --check --dry-run # Fail if unapplied migrations exist python manage.py migrate --plan # Show migration plan - ALWAYS use environment variables for all configuration. Never bake configuration into Docker images.
- ALWAYS use
to exclude.dockerignore
,.git
,__pycache__
,.env
, media files.node_modules - ALWAYS tag Docker images with the Git commit SHA, not
:latestdocker build -t cms-backend:$(git rev-parse --short HEAD) . - ALWAYS use structured JSON logging in production:
LOGGING = { 'version': 1, 'formatters': { 'json': { '()': 'pythonjsonlogger.jsonlogger.JsonFormatter', 'format': '%(asctime)s %(name)s %(levelname)s %(message)s', }, }, 'handlers': { 'console': { 'class': 'logging.StreamHandler', 'formatter': 'json', }, }, 'root': { 'handlers': ['console'], 'level': 'INFO', }, } - ALWAYS monitor these metrics:
- Request latency (p50, p95, p99)
- Error rate (5xx responses)
- Database query count and latency
- Redis connection pool usage
- Celery task queue depth and processing time
- SSE active connection count
- Memory and CPU usage per container
- ALWAYS define resource limits for containers:
resources: requests: memory: "256Mi" cpu: "250m" limits: memory: "512Mi" cpu: "500m" - ALWAYS implement graceful shutdown — handle SIGTERM to finish in-flight requests:
# Uvicorn handles this natively with --timeout-graceful-shutdown CMD ["uvicorn", "CMS.asgi:application", "--host", "0.0.0.0", "--port", "8000", "--timeout-graceful-shutdown", "30"]
NEVER
- NEVER use
in production.runserver - NEVER bake secrets into Docker images.
- NEVER deploy without running the test suite in CI.
- NEVER run migrations and application startup in the same process simultaneously.
- NEVER use
in production.DEBUG=True - NEVER expose database ports to the public internet.
- NEVER use
tag for Docker images in production deployments.latest - NEVER skip health checks in orchestrator configuration.
- NEVER log request/response bodies in production (PII risk).
- NEVER store persistent data in container filesystems (ephemeral).
CI/CD Pipeline
Pipeline Stages
1. Lint → ruff check, ruff format --check 2. Test → pytest with coverage 3. Migration → makemigrations --check, migrate --plan 4. Build → Docker image build 5. Security → Dependency vulnerability scan (pip-audit, safety) 6. Push → Push image to registry 7. Deploy → Apply migrations → Rolling update 8. Smoke Test → Hit health endpoints on new deployment
CI Configuration Example
# .github/workflows/ci.yml name: CI on: [push, pull_request] jobs: test: runs-on: ubuntu-latest services: postgres: image: postgres:16 env: POSTGRES_DB: cms_test POSTGRES_USER: test POSTGRES_PASSWORD: test ports: ["5432:5432"] redis: image: redis:7 ports: ["6379:6379"] steps: - uses: actions/checkout@v4 - uses: actions/setup-python@v5 with: python-version: '3.12' - run: pip install -r requirements.txt - run: ruff check . - run: ruff format --check . - run: python manage.py makemigrations --check --dry-run - run: pytest --cov --cov-fail-under=80
Database Deployment Rules
- Run migrations in a dedicated init container or CI step, not in the application process.
- Use
to preview migrations before applying.--plan - For zero-downtime migrations, follow the expand-contract pattern:
- Expand: Add new column (nullable), deploy code that writes to both old and new.
- Migrate: Backfill data.
- Contract: Remove old column, deploy code that uses only new.
- Never run destructive migrations (RemoveField, DeleteModel) without a maintenance window or expand-contract strategy.
Environment Management
.env.example # Template with all required vars (committed) .env # Local development values (NOT committed) .env.staging # Staging values (NOT committed, in CI secrets) .env.production # Production values (NOT committed, in secret manager)
Required environment variables:
SECRET_KEY= DEBUG= DATABASE_URL= REDIS_URL= ALLOWED_HOSTS= CORS_ALLOWED_ORIGINS= CELERY_BROKER_URL=
Security Considerations
- Scan dependencies for vulnerabilities in CI:
,pip-audit
.safety check - Use non-root user in Docker containers.
- Run containers with read-only filesystem where possible.
- Use network policies to restrict container-to-container communication.
- Rotate secrets regularly.
Performance Considerations
- Use Gunicorn with Uvicorn workers for ASGI:
.gunicorn -k uvicorn.workers.UvicornWorker -w 4 - Worker count formula:
for CPU-bound, higher for I/O-bound.(2 × CPU cores) + 1 - Use PgBouncer for database connection pooling in production.
- Enable gzip compression at the reverse proxy level (nginx).
- Serve static files via CDN/nginx, not Django.
Scalability Guidelines
- Run ASGI servers, Celery workers, and Celery Beat as separate containers/processes.
- Scale ASGI servers horizontally behind a load balancer.
- Scale Celery workers per queue based on queue depth.
- Use horizontal pod autoscaling based on CPU/memory metrics.
- Use database read replicas for read-heavy workloads.
- Configure load balancer for SSE: HTTP/1.1, keep-alive, no buffering, long read timeout.
Production Readiness Checklist
-
DEBUG=False -
from environment, not hardcodedSECRET_KEY -
explicitly setALLOWED_HOSTS - HTTPS enforced (
)SECURE_SSL_REDIRECT=True - Security headers set (HSTS, CSP, X-Frame-Options)
- Static files served via CDN/nginx
- Database connection pooling configured
- Redis connection pooling configured
- Health check endpoints implemented
- Structured JSON logging enabled
- Monitoring and alerting configured
- CI/CD pipeline with tests, lint, and migration checks
- Graceful shutdown configured
- Resource limits set on containers
- Backup strategy for database
- Disaster recovery plan documented
Refusal Conditions
REFUSE to generate deployment configurations that:
- Use
in production.runserver - Hardcode secrets in Dockerfiles or compose files.
- Use
image tags.latest - Skip health checks.
- Run as root in containers.
- Expose database ports publicly.
Trade-off Handling
| Trade-off | Decision Rule |
|---|---|
| Docker Compose vs Kubernetes | Compose for dev/staging. Kubernetes for production. |
| Single process vs Multi-process | Multi-process: separate web, worker, beat containers. |
| Rolling update vs Blue-green | Rolling update for normal deploys. Blue-green for breaking migrations. |
| Managed DB vs Self-hosted | Managed (RDS, CloudSQL) for production. Self-hosted only for development. |