[Github] 从手动到自动：利用GitHub Actions实现发布流程自动化

1. 为什么需要自动化发布流程每次手动发布新版本时我都得重复执行十几个步骤创建release分支、打tag、编写变更日志、上传构建产物...稍不留神就会漏掉某个环节。最崩溃的是有次半夜发布困得手抖把v1.2.0打成了v2.1.0直接导致下游团队集体炸锅。GitHub Actions的自动化发布完美解决了这些问题。我最近给团队项目配置后发布流程从原来的30分钟缩短到3分钟错误率降为零。想象一下当你把代码推送到特定分支时系统会自动完成版本号递增、生成变更日志、创建GitHub Release页面上传二进制文件甚至还能给Slack频道发送通知。2. 基础工作流配置2.1 创建你的第一个发布工作流在项目根目录创建.github/workflows/release.yml文件这是我们的自动化核心。下面这个配置是我经过20多次迭代验证的稳定版本name: Release Automation on: push: branches: [ main ] # 只在main分支推送时触发 tags: [v*] # 监听v开头的tag jobs: build-and-release: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: Setup Node.js uses: actions/setup-nodev3 with: node-version: 18 - run: npm install - run: npm run build - name: Create Release id: create_release uses: actions/create-releasev1 env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} with: tag_name: ${{ github.ref_name }} release_name: Release ${{ github.ref_name }} draft: false prerelease: false - name: Upload Artifact uses: actions/upload-release-assetv1 env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} with: upload_url: ${{ steps.create_release.outputs.upload_url }} asset_path: ./dist/*.zip asset_name: build-${{ github.ref_name }}.zip这个配置做了几件关键事情监听main分支的推送和v*格式的tag自动构建项目假设是Node.js项目使用官方actions/create-release创建Release页面将构建产物打包上传到Release资产2.2 权限配置要点第一次运行时很多人会卡在权限问题上。你需要在仓库Settings Actions General中确保Workflow permissions开启读写权限。更安全的做法是专门创建一个Fine-grained token只赋予以下权限Contents: Read and writeMetadata: Read-onlyPull requests: Read-only3. 高级发布策略3.1 语义化版本自动递增手动维护版本号太容易出错。我推荐使用semantic-release这个神器它会根据commit信息自动决定版本号升级- name: Semantic Release uses: cycjimmy/semantic-release-actionv2 env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} with: extra_plugins: | semantic-release/git semantic-release/changelog这套配置会自动分析feat:、fix:、BREAKING CHANGE:等commit前缀决定是主版本、次版本还是修订号升级生成CHANGELOG.md文件创建对应的git tag3.2 多环境发布控制我们的项目需要区分测试版和生产版发布。这是经过实战检验的多环境配置jobs: release: strategy: matrix: include: - env: production condition: startsWith(github.ref, refs/tags/v) prerelease: false - env: staging condition: github.ref refs/heads/release prerelease: true steps: - name: Create ${{ matrix.env }} release if: ${{ matrix.condition }} uses: actions/create-releasev1 with: prerelease: ${{ matrix.prerelease }}当推送到release分支时会创建带Pre-release标记的版本只有正式tag才会生成稳定版发布。4. 实战中的坑与解决方案4.1 大文件上传超时问题当构建产物超过500MB时默认上传经常会超时。我的解决方案是- name: Upload large artifacts uses: actions/upload-release-assetv1 timeout-minutes: 30 # 默认是10分钟 with: upload_url: ${{ steps.create_release.outputs.upload_url }} asset_path: ./large-asset.bin asset_content_type: application/octet-stream同时建议超过2GB的文件使用Git LFSgit lfs track *.psd git add .gitattributes4.2 依赖缓存加速每次从头安装依赖太耗时。这是我优化后的缓存配置- name: Cache node modules uses: actions/cachev3 with: path: | ~/.npm node_modules key: ${{ runner.os }}-node-${{ hashFiles(**/package-lock.json) }} restore-keys: | ${{ runner.os }}-node-实测可以使构建速度提升60%特别是对于像React这种依赖多的项目。5. 全链路自动化示例最后分享一个我正在生产环境使用的完整案例实现了从代码提交到发布的完整自动化name: Full Release Pipeline on: push: branches: [ main ] pull_request: branches: [ main ] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - run: npm install - run: npm test build: needs: test runs-on: ubuntu-latest outputs: build_id: ${{ steps.build.outputs.build_id }} steps: - uses: actions/checkoutv4 - run: npm install - run: npm run build - id: build run: echo build_id$(date %s) $GITHUB_OUTPUT release: needs: build if: github.ref refs/heads/main runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: marvinpinto/action-automatic-releaseslatest with: repo_token: ${{ secrets.GITHUB_TOKEN }} automatic_release_tag: latest prerelease: false title: Release ${{ needs.build.outputs.build_id }} files: | dist/*.js package.json这套系统每天要处理我们团队30次提交稳定运行了8个月零故障。关键点在于严格的流水线阶段测试→构建→发布每个环节都有明确的输入输出使用build_id确保每次发布唯一可追溯