Back to Details

ci-cd-architecture

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

CI/CD & Deployment

CI/CD与部署

Overview

概述

Covers CI/CD pipeline design, deployment platform selection, and production infrastructure. Focuses on GitHub Actions with hardened security (OIDC, permission scoping, action pinning), Bun-first build optimization, and deployment patterns from MVP to enterprise scale.
When to use: Setting up GitHub Actions workflows, choosing deployment targets, configuring OIDC for cloud providers, optimizing CI performance, planning multi-environment pipelines.
When NOT to use: Application-level architecture decisions (use framework-specific skills), Kubernetes cluster management (use dedicated IaC tools), cloud provider console configuration.
涵盖CI/CD流水线设计、部署平台选择及生产基础设施相关内容。重点介绍具备强化安全机制（OIDC、权限范围限定、Action版本锁定）的GitHub Actions、基于Bun的构建优化，以及从MVP到企业级规模的部署模式。
适用场景：搭建GitHub Actions工作流、选择部署目标、为云服务商配置OIDC、优化CI性能、规划多环境流水线。
不适用场景：应用级架构决策（请使用框架专属技能）、Kubernetes集群管理（请使用专用IaC工具）、云服务商控制台配置。

Quick Reference

快速参考

NeedSolution
MVP deploy (< 1K users)Vercel, Netlify, Railway, Cloudflare Pages
Growing product (1K-100K)AWS Amplify, Cloud Run, Fly.io, Render
Enterprise (100K+)AWS ECS/EKS, GKE, DigitalOcean App Platform
Static siteVercel, Netlify, Cloudflare Pages
Full-stack + DBRailway, Render, AWS Amplify
Global low latencyCloudflare Workers, Vercel Edge, Fly.io
Compliance (HIPAA, SOC 2)AWS, GCP, Azure
Cloud auth from CIOIDC roles (never long-lived keys)
Action pinningPin to commit SHA, not tag
Bun CI caching
~/.bun/install/cache
keyed on lockfile
Pipeline securityStepSecurity Harden-Runner for egress control
Container buildsMulti-stage Dockerfile: builder + runtime stage
Docker layer caching
--cache-from
+ 
actions/cache
for buildx
Multi-platform builds
docker buildx
targeting 
linux/amd64,linux/arm64
Image scanningTrivy or Snyk in pipeline before push
Registry pushGHCR (
ghcr.io
), ECR, Docker Hub
Pipeline stagesbuild → test → security scan → deploy
DORA: deploy frequencyTrack deployments per day/week per service
DORA: lead timeCommit-to-production time; target < 1 hour
DORA: change failure rate% of deploys causing incidents; target < 5%
DORA: MTTRMean time to restore; target < 1 hour
需求解决方案
MVP部署（用户量<1000）Vercel, Netlify, Railway, Cloudflare Pages
成长型产品（1000-100000用户）AWS Amplify, Cloud Run, Fly.io, Render
企业级（用户量>100000）AWS ECS/EKS, GKE, DigitalOcean App Platform
静态站点Vercel, Netlify, Cloudflare Pages
全栈+数据库Railway, Render, AWS Amplify
全球低延迟Cloudflare Workers, Vercel Edge, Fly.io
合规要求（HIPAA、SOC 2）AWS, GCP, Azure
从CI进行云认证OIDC角色（绝不使用长期密钥）
Action版本锁定锁定到提交SHA值，而非标签
Bun CI缓存以
~/.bun/install/cache
为缓存键，基于锁定文件
流水线安全使用StepSecurity Harden-Runner进行出口流量控制
容器构建多阶段Dockerfile：构建阶段 + 运行时阶段
Docker层缓存结合
--cache-from
与
actions/cache
用于buildx
多平台构建使用
docker buildx
，目标架构为
linux/amd64,linux/arm64
镜像扫描在推送前于流水线中使用Trivy或Snyk
镜像仓库推送GHCR (
ghcr.io
), ECR, Docker Hub
流水线阶段构建 → 测试 → 安全扫描 → 部署
DORA：部署频率按服务统计每日/每周的部署次数
DORA：前置时间从提交到生产环境的时间；目标<1小时
DORA：变更失败率引发故障的部署占比；目标<5%
DORA：平均恢复时间（MTTR）平均恢复时间；目标<1小时

Common Mistakes

常见错误

MistakeCorrect Pattern
Storing long-lived AWS/GCP/Azure keys as GitHub secretsUse OIDC roles with 
id-token: write
permission for zero-trust cloud auth
Pinning GitHub Actions to tags instead of commit SHAsPin third-party actions to full commit SHA to prevent supply chain attacks
Leaving 
permissions
as default (broad) on workflows		Explicitly scope permissions at the job level; default to 
contents: read
Running full CI on every branch pushUse 
on.pull_request
filters and path-based triggers to avoid wasted compute
Over-engineering infrastructure before product-market fitStart with managed platforms (Vercel, Railway); scale to AWS/GKE only when needed
Using outdated action versions (v3 or older)Use current major versions: checkout@v6, cache@v5, configure-aws-credentials@v5
Caching only 
bun.lockb
without considering 
bun.lock
Bun 1.2+ uses text-based 
bun.lock
; hash whichever lockfile format the project uses
Skipping preview deployments for PRsEvery PR should get a preview URL for testing before merge
错误正确做法
将AWS/GCP/Azure长期密钥存储为GitHub密钥使用带有
id-token: write
权限的OIDC角色实现零信任云认证
将GitHub Actions锁定到标签而非提交SHA值将第三方Action锁定到完整提交SHA值，以防止供应链攻击
工作流中保留默认的（宽泛）
permissions
权限		在任务级别显式限定权限；默认设置为
contents: read
每次分支推送都运行完整CI流程使用
on.pull_request
过滤器和基于路径的触发器避免不必要的计算资源浪费
在产品-市场匹配前过度设计基础设施从托管平台（Vercel、Railway）起步；仅在需要时扩展到AWS/GKE
使用过时的Action版本（v3或更早版本）使用当前主版本：checkout@v6, cache@v5, configure-aws-credentials@v5
仅缓存
bun.lockb
而未考虑
bun.lock
Bun 1.2+使用基于文本的
bun.lock
；根据项目使用的锁定文件格式进行哈希计算
跳过PR的预览部署每个PR都应生成预览URL，以便合并前进行测试

Relationship to Other Skills

与其他技能的关联

If the 
github-actions
skill is available, delegate detailed workflow authoring, matrix strategies, and composite actions to it. This skill covers CI/CD architecture and platform selection; 
github-actions
covers workflow syntax depth. If the 
deployment-strategy
skill is available, delegate deployment pattern selection (blue-green, canary, rolling) to it. This skill covers platform selection and CI pipeline mechanics.
若
github-actions
技能可用，将详细的工作流编写、矩阵策略及复合Action相关工作委托给该技能。本技能负责CI/CD架构与平台选择；
github-actions
负责工作流语法的深度实现。 若
deployment-strategy
技能可用，将部署模式选择（蓝绿部署、金丝雀部署、滚动部署）委托给该技能。本技能负责平台选择与CI流水线机制。

Delegation

委托事项

  • Audit existing CI workflow security and permissions: Use 
    Explore
    agent to scan workflow YAML files for broad permissions, unpinned actions, and exposed secrets
  • Set up multi-environment deployment pipelines: Use 
    Task
    agent to create dev/staging/prod workflows with environment protection rules
  • Plan migration from managed platform to containerized infrastructure: Use 
    Plan
    agent to evaluate current deployment, define migration steps, and select target architecture
  • 审计现有CI工作流的安全性与权限设置：使用
    Explore
    代理扫描工作流YAML文件，检查是否存在宽泛权限、未锁定版本的Action及暴露的密钥
  • 搭建多环境部署流水线：使用
    Task
    代理创建带有环境保护规则的开发/预发布/生产环境工作流
  • 规划从托管平台到容器化基础设施的迁移：使用
    Plan
    代理评估当前部署情况、定义迁移步骤并选择目标架构

References

参考资料

  • GitHub Actions workflows, OIDC, matrix builds, and security hardening
  • Deployment patterns: Jamstack, serverless, traditional, microservices
  • Platform selection framework, database needs, and cost optimization
  • Monitoring, observability tiers, and deployment checklists
  • Container builds: multi-stage Dockerfiles, layer caching, buildx, image scanning, and registry push
  • GitHub Actions工作流、OIDC、矩阵构建及安全强化
  • 部署模式：Jamstack、无服务器、传统架构、微服务
  • 平台选择框架、数据库需求及成本优化
  • 监控、可观测性层级及部署检查清单
  • 容器构建：多阶段Dockerfile、层缓存、buildx、镜像扫描及镜像仓库推送