
Deployment Pipeline Design
Design production deployment pipelines with reusable CI workflows, container build/push, caching, and rollback-oriented launch prep on platforms like GitHub Actions.
Overview
Deployment pipeline design is an agent skill most often used in Ship (also Operate) that specifies production CI/CD pipelines, container publish flows, and advanced rollback configurations for solo builders.
Install
npx skills add https://github.com/wshobson/agents --skill deployment-pipeline-designWhat is this skill?
- Advanced reference extends core deployment patterns from the parent SKILL.md decision tables
- Includes GitHub Actions production pipeline with workflow_dispatch and OIDC-friendly permissions
- Docker Buildx build-push with ghcr.io login, metadata tags, and GHA layer cache (cache-from/cache-to mode=max)
- Reusable workflow patterns for separating build from deploy jobs
- Covers advanced rollback strategies in the extended reference doc
Adoption & trust: 8.9k installs on skills.sh; 36.5k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You can deploy manually but lack a documented production pipeline with caching, tagged images, and a safe path to roll back when a release fails.
Who is it for?
Indie SaaS or APIs using Docker and GitHub Actions who want main-branch or dispatch-driven production with registry-backed artifacts.
Skip if: Static sites with one-click host deploy and no containers, or teams with no secrets/registry story yet.
When should I use this skill?
Designing or hardening production deployment pipelines, reusable CI workflows, container publish to a registry, or advanced rollback after core patterns are chosen in SKILL.md.
What do I get? / Deliverables
You get platform-aligned pipeline configs—such as GitHub Actions build-and-push to ghcr.io—that you can wire into staged or production deploy jobs with rollback options from the reference set.
- Production-oriented workflow YAML (e.g. .github/workflows/production.yml)
- Documented deploy/rollback strategy aligned to the parent SKILL.md decision tables
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Ship Launch is the canonical shelf because the skill targets production pipeline configuration and release paths immediately before or during go-live. Launch subphase covers pipeline orchestration, registry push, and production triggers—not unit testing alone or post-launch growth work.
Where it fits
Author production.yml on main with build job outputs image_tag for a gated deploy job.
Extend rollback section from the advanced reference after a bad release.
Add Dockerfile and registry metadata steps once the API image is the deployable unit.
How it compares
Focuses on end-to-end deploy pipelines and rollback—not local test runners or application-level saga recovery.
Common Questions / FAQ
Who is deployment pipeline design for?
Solo builders preparing repeatable production releases with CI, containers, and cloud/registry authentication.
When should I use deployment pipeline design?
During Ship launch prep when authoring workflows; during Operate infra work when evolving rollback and reusable jobs; after Build when the app is ready to automate release.
Is deployment pipeline design safe to install?
Pipeline snippets touch secrets and registry credentials—review the Security Audits panel on this Prism page and harden OIDC, permissions, and secret scopes before enabling auto-deploy.
SKILL.md
READMESKILL.md - Deployment Pipeline Design
# Advanced Deployment Strategies Reference Extended configurations, platform-specific patterns, and advanced rollback strategies. Core patterns and decision tables live in [`../SKILL.md`](../SKILL.md). --- ## Platform-Specific Pipeline Configurations ### GitHub Actions — Full Production Pipeline with Reusable Workflows ```yaml # .github/workflows/production.yml name: Production Pipeline on: push: branches: [main] workflow_dispatch: inputs: skip_tests: type: boolean default: false permissions: contents: read id-token: write # for OIDC auth to cloud providers jobs: build: runs-on: ubuntu-latest outputs: image_tag: ${{ steps.meta.outputs.version }} steps: - uses: actions/checkout@v4 - name: Set up Docker Buildx uses: docker/setup-buildx-action@v3 - name: Log in to registry uses: docker/login-action@v3 with: registry: ghcr.io username: ${{ github.actor }} password: ${{ secrets.GITHUB_TOKEN }} - name: Docker metadata id: meta uses: docker/metadata-action@v5 with: images: ghcr.io/${{ github.repository }} tags: | type=sha,prefix=,format=short - name: Build and push (with layer cache) uses: docker/build-push-action@v5 with: push: true tags: ${{ steps.meta.outputs.tags }} cache-from: type=gha cache-to: type=gha,mode=max security-scan: needs: build runs-on: ubuntu-latest steps: - name: Run Trivy vulnerability scan uses: aquasecurity/trivy-action@0.28.0 with: image-ref: ghcr.io/${{ github.repository }}:${{ needs.build.outputs.image_tag }} exit-code: 1 severity: CRITICAL,HIGH - name: SAST with Semgrep uses: semgrep/semgrep-action@v1 with: config: auto test: needs: build runs-on: ubuntu-latest services: postgres: image: postgres:16 env: POSTGRES_PASSWORD: test options: >- --health-cmd pg_isready --health-interval 10s steps: - uses: actions/checkout@v4 - name: Run test suite run: make test-ci env: DATABASE_URL: postgres://postgres:test@localhost/test deploy-staging: needs: [test, security-scan] environment: name: staging url: https://staging.example.com runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Configure AWS credentials (OIDC) uses: aws-actions/configure-aws-credentials@v4 with: role-to-assume: arn:aws:iam::123456789:role/deploy-staging aws-region: us-east-1 - name: Deploy to EKS staging run: | aws eks update-kubeconfig --name my-cluster-staging kubectl set image deployment/my-app \ app=ghcr.io/${{ github.repository }}:${{ needs.build.outputs.image_tag }} kubectl rollout status deployment/my-app --timeout=5m e2e-tests: needs: deploy-staging runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Run Playwright E2E suite run: npx playwright test --reporter=github env: BASE_URL: https://staging.example.com deploy-production: needs: e2e-tests environment: name: production url: https://app.example.com runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Configure AWS credentials (OIDC) uses: aws-actions/configure-aws-credentials@v4 with: role-to-assume: arn:aws:iam::123456789:role/deploy-production aws-region: us-east-1 - name: Deploy canary to production run: | aws eks update-kubeconfig --name my-cluster-prod kubectl argo rollouts set image my-app \ app=ghcr.io/${{ github.repository }}:${{ needs.build.outputs.i