platform-infrastructure

Files (7)

• SKILL.md
• nextjs-postgres-aws.yml · references/cicd-pipeline-templates/
• nextjs-postgres-vercel.yml · references/cicd-pipeline-templates/
• python-fastapi-railway.yml · references/cicd-pipeline-templates/
• environment-management.md · references/
• iac-guide.md · references/
• secrets-management.md · references/

SKILL.md (first lines)

# Platform & Infrastructure

You handle CI/CD pipelines, containerization, IaC, environment management, secrets, DNS/SSL, and CDN configuration. This skill covers everything between writing code and running it reliably in production.

## When this skill triggers

This skill activates when a developer asks about setting up deployment pipelines, writing Dockerfiles, configuring Terraform, managing environment variables across stages, handling secrets securely, setting up custom domains with SSL, or configuring CDN caching.

---

## CI/CD Architecture

Reference: `references/cicd-pipeline-templates/`

### Recommended stack: GitHub Actions

GitHub Actions is the default recommendation for CI/CD. It integrates natively with GitHub, has a generous free tier, and has the largest ecosystem of reusable actions.

### Pipeline stages

Every pipeline should follow this order:

```
checkout → install → lint → typecheck → test → build → deploy
```

| Stage | Tool | Fails build? |
|-------|------|-------------|
| Lint | ESLint / Ruff | Yes |
| Typecheck | `tsc --noEmit` / mypy | Yes |
| Test | Vitest / pytest | Yes |
| Build | `next build` / Docker build | Yes |
| Deploy | Vercel / AWS / Railway | Yes (on prod) |

### Branch strategy

```
main (production) ← PR merge only, protected
  ├── staging ← auto-deploy on merge to staging
  └── feature/* ← preview deploys (optional)
```

**Branch protection rules for `main`:**
- Require PR reviews (1 minimum)
- Require status checks to pass (lint, typecheck, test, build)
- Require branches to be up to date before merging
- No direct pushes

<!-- beginner -->
**What is CI/CD?** CI (Continuous Integration) automatically runs your tests every time you push code. CD (Continuous Deployment) automatically deploys your code after tests pass. Together, they prevent you from shipping broken code and eliminate manual deployment steps.
> Time: ~30 min to set up with GitHub Actions
> Template: See `references/cicd-pipeline-templates/`

<!-- intermediate -->
**CI/CD pipeline (GitHub Actions)** — lint, typecheck, test, build, deploy. Branch protection on main. Use `concurrency` groups to cancel stale runs. Cache `node_modules` and `.next/cache` between runs.
> ~30 min

<!-- senior -->
**CI/CD** — GHA: lint/type/test/build/deploy gates. Concurrency groups. Dependency caching. Matrix builds if multi-platform. OIDC for cloud auth (no long-lived secrets). Reusable workflows for shared org patterns.

### Deploy gates

Before deploying to production, require:
- All CI checks green
- At least one PR approval
- No `FIXME` or `TODO: BEFORE_DEPLOY` markers in diff
- Database migrations reviewed (if any)
- Bundle size within budget (fail if > 10% increase)

---

## Container Strategy

### Dockerfile best practices

```dockerfile
# Multi-stage build for Node.js/Next.js
# [CUSTOMIZE] Change node version and package manager as needed

# Stage 1: Install dependencies
FROM node:20-alpine AS deps
WORKDIR /app
COPY package.json pnpm-lock.yaml ./
RUN corepack enable && pnpm install --frozen-lockfile

# Stage 2: Build
FROM node:20-alpine AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
ENV NEXT_TELEMETRY_DISABLED=1
RUN corepack enable && pnpm build

# Stage 3: Production
FROM node:20-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production
ENV NEXT_TELEMETRY_DISABLED=1

RUN addgroup --system --gid 1001 appgroup && \
    adduser --system --uid 1001 appuser

COPY --from=builder /app/public ./public
COPY --from=builder --chown=appuser:appgroup /app/.next/standalone ./
COPY --from=builder --chown=appuser:appgroup /app/.next/static ./.next/static

USER appuser
EXPOSE 3000
ENV PORT=3000
CMD ["node", "server.js"]
```

**Key rules:**
- Always use multi-stage builds (smaller images, no dev deps in prod)
- Pin base image versions (`node:20-alpine`, not `node:latest`)
- Run as non-root user
- Use `.dockerignore` to exclude `node_modules`, `.git`, `.env*`
- Order `COPY` statements from least-changed to most-changed for layer caching

From harmansidhudev/shipwise, MIT.

More from harmansidhudev/shipwise