EP14. "wp-ci-cd-and-release-engineering CI/CD 与发版审查"

• 你打包上传到 WordPress.org 的那个 zip，真的是审核通过的那个 commit 打出来的吗？还是本地东改改西改改再手动上传的？wp-ci-cd-and-release-engineering 就是专门抓这种「代码审查通过的版本」跟「实际发出去的版本」对不上的坑
• 这是 jorgerosal/wordpress-skills 开源 skill 包里的其中一个，专门审查 WordPress 插件/主题的 CI/CD 流水线和发版流程
• 核心原则：发版要可复现（reproducible）、打包范围要对应真正要发出去的产物、环境/权限/验证关卡要讲清楚——不能等东西发到用户手上或生产环境才发现出错
• 前置知识：先看过 Overview 系列的「Claude Code 是什么与新手上手」「进阶功能：Skills、Plugins 与 Routines」两篇，知道 Skill 是什么、怎么装

重点内容

这个 Skill 是做什么的

wp-ci-cd-and-release-engineering 审查的是「代码之外」的东西：GitHub Actions workflow、打包脚本、WordPress.org 的 SVN 发版流程、部署时的密钥/环境处理、回滚方案。跟 wp-security-review 抓的是同一批代码里有没有漏洞不同，这个 skill 抓的是「这批代码怎么变成用户手上的那个 zip 或那次生产部署」这整条链路有没有断掉、有没有漏洞。

适合用在：

• 审查 WordPress 插件/主题/headless 项目的 GitHub Actions 或其他 CI/CD workflow
• 审计打包脚本、发版脚本、部署 job
• 检查 WordPress.org 的 SVN 发版流程、产物生成、release tag
• 审查部署/构建步骤/预览环境的密钥（secret）处理
• 规划分阶段上线、回滚、发版前验证流程

不适合用在：

• 纯代码层面的插件架构审查，跟发版流水线无关（交给 wp-plugin-development）
• 只是要设置静态分析（交给 wp-phpstan-review）
• 以 WP-CLI 为主的日常运维任务（交给 wp-wpcli-and-ops）
• headless 项目的缓存/内容更新架构，跟部署流水线本身无关（交给 wp-headless-and-wpgraphql）

触发方式

审查流程六步

1. 找出发版相关的面 — CI 配置文件、发版脚本、打包成 zip 的步骤、发版文档/checklist
2. 先看产物边界 — 到底哪些文件真正发到生产环境或 WordPress.org？产物是一次构建后到处复用，还是每个环境各自重新构建（容易导致「测试的版本」跟「发出去的版本」不是同一份代码）？测试文件、source map、密钥、本地配置有没有混进发版产物
3. 审查环境与密钥处理 — 密钥有没有限制在真正需要用到的 job；生产部署有没有靠分支/tag/environment protection 卡住；预览/staging 环境是不是用了独立的密钥和目标地址
4. 审查验证与可复现性 — 打包/部署前有没有先跑过 lint/测试/构建；依赖安装够不够锁定版本；发出去的产物有没有被单独验证过，而不是想当然认为「代码库长什么样，发出去的就是什么样」
5. 审查回滚与发版操作 — 有没有写好的回滚流程；能不能追溯当前线上是哪个版本/哪个产物；重跑一次发版流程会不会导致部分重复部署
6. 给严重度分级

严重度分级

按面向抓的坑

实操示例：GitHub Actions 部署 job 的错法/对法

# ❌ CRITICAL：任何人 push 到 main 都会直接触发生产部署，密钥没有范围限制
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploying with token ${{ secrets.SVN_PASSWORD }}"
      - run: ./deploy.sh

# ✅ GOOD：用 environment protection 卡住生产部署，密钥只给需要的 job，部署前先跑验证
on:
  push:
    tags: ['v*']
jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - run: composer install --no-dev --prefer-dist
      - run: npm ci && npm run build
      - run: npm test
  deploy:
    needs: verify
    runs-on: ubuntu-latest
    environment: production
    steps:
      - run: ./deploy.sh
        env:
          SVN_PASSWORD: ${{ secrets.SVN_PASSWORD }}

# ❌ CRITICAL：发版 zip 直接打包整个工作目录，测试/本地配置一起带走
zip -r release.zip .

# ✅ GOOD：明确列出要打包的文件，排除开发用的文件
rsync -av --exclude-from='.distignore' ./ ./build/
cd build && zip -r ../release.zip .

怎么安装

这个 skill 是 wordpress-skills 这个开源仓库（jorgerosal/wordpress-skills）打包的 18 个技能之一，安装一次，18 个技能一起到位，不用逐个装：

Claude Code：

装完重启 Claude Code，进到一个 WordPress 项目里跑 /wordpress-skills:wp-release-review 验证有没有装成功（用 marketplace/submodule 方式装的话，指令前面会带插件命名空间 wordpress-skills:；用「只装这一个 skill」的方式则不带命名空间，直接 /wp-release-review）。

Claude Desktop / claude.ai： 走 Settings → Capabilities → Skills，上传技能文件夹（把 claude-skills/wp-ci-cd-and-release-engineering 这个文件夹打包上传，里面要包含 SKILL.md）——跟 Claude Code 的 git submodule/marketplace 安装方式不同，Desktop 端是手动上传 UI，装好之后同样能用自然语言或 slash 指令触发。

常见错误

• ❌ 把纯代码层面的插件架构问题（跟发版流水线无关）塞进这个 skill 审查——那是 wp-plugin-development 的活
• ❌ 把「可以加缓存」「可以用 matrix strategy 加速」这类优化建议报成 CRITICAL——这些顶多是 INFO，不影响发版安全
• ❌ 只看代码库长什么样就断定发出去的产物没问题——真正要验证的是「打包/部署出来的那个产物」本身，代码库干净不代表打包过程没有夹带垃圾文件
• 💡 判断 CRITICAL 的关键不是「有没有部署 job」，而是「有没有保护机制」——一个会自动部署到生产环境的 job 本身不是问题，没有分支保护/environment protection 卡住它才是问题

Sources

官方文档：

1. wordpress-skills（GitHub 仓库）— https://github.com/jorgerosal/wordpress-skills
2. wp-ci-cd-and-release-engineering SKILL.md — https://github.com/jorgerosal/wordpress-skills/blob/main/claude-skills/wp-ci-cd-and-release-engineering/SKILL.md