heroku_san持续部署auto_taggerGit标签实现ci→staging→production自动晋级【免费下载链接】heroku_sanHelpful stuffs for Heroku.项目地址: https://gitcode.com/gh_mirrors/he/heroku_sanheroku_san 是一款面向 Heroku 的 Ruby 部署工具用 Rake 任务统一管理多环境应用。本文带你用 heroku_san 的 tag 配置与官方示例 auto_tagger通过 Git 标签把一次 CI 构建自动晋级到 staging 和 production实现安全可靠的持续部署告别手动复制提交号的混乱操作。为什么需要标签晋级式部署 多环境部署时新手常遇到三个痛点环境靠手敲staging 和 production 各部署一个 commit复制 SHA 容易出错晋级无保证production 可能部署了一个从未在 staging 验证过的版本版本说不清出问题时你甚至不知道线上跑的到底是哪次构建。heroku_san 的思路很优雅给每个版本发一张标签通行证。CI 通过后打ci/标签staging 只认ci/*标签production 只认staging/*标签。环境只能部署上一级已验证的版本晋级链路天然安全。工作原理一条标签链串起三个环境 整个持续部署流程只有三步步骤动作产生的标签1️⃣ CI 构建测试通过后在 HEAD 打标签ci/N2️⃣ 部署 staging读取最新的ci/*标签并部署成功后打标签staging/N3️⃣ 部署 production读取最新的staging/*标签并部署成功后打标签production/N关键机制在config/heroku.yml的tag字段格式可参考模板文件lib/templates/heroku.example.ymlstaging: app: awesomeapp-staging tag: ci/* production: app: awesomeapp tag: staging/*部署时heroku_san 会执行git tag -l匹配通配符取最新的标签把该标签指向的提交推送到对应环境的 Heroku 应用。由于 production 只认staging/*标签而staging/标签只在 staging 部署成功后才会创建——production 永远不会跑未经 staging 验证的代码这就是自动晋级的安全底线。快速上手三步配置完整晋级流程 第一步安装 heroku_san在Gemfile中加入仅限开发环境group :development do gem heroku_san end然后生成配置文件rails generate heroku_san # Rails 3 项目 rake heroku:create_config # 其他项目第二步为每个环境配置 tag 规则编辑config/heroku.yml按上文为 staging 和 production 分别写上tag: ci/*与tag: staging/*。这一步是整套方案的灵魂让每个环境只接受指定前缀的标签。第三步接入 auto_tagger 自动打标签把项目自带的示例文件examples/auto_tagger.rake加入你的 Rake 任务需在 Gemfile 引入auto_tagger依赖并在 CI 构建脚本末尾追加一行rake ci-test-target autotag:create[ci]含义是只有测试任务ci-test-target成功后才为 HEAD 创建并推送ci/N标签测试任务名请替换成你自己的。此后部署就变得极其简单rake all deploy # 一次部署所有已选环境 # 或分步执行 rake staging deploy rake production deployauto_tagger 的四个关键钩子 examples/auto_tagger.rake的精髓在于挂接了 heroku_san 内置的部署回调回调机制定义在lib/heroku_san/tasks.rbbefore_deploy部署前执行git fetch --tags确保本地拿到远端最新标签解析出的最新版本才准确after_deploy每个环境部署成功后调用create_and_push(stage.name, stage.revision)在该环境实际部署的版本上打stage/N标签并推送远端——staging 部署完就有了staging/Nproduction 才有资格晋级create_and_push用AutoTagger::Base创建标签refs_to_keep: 100保留最近 100 个历史标签方便回溯和回滚autotag:create[stage]/autotag:list手动为指定阶段补打标签、查看各阶段完整标签历史。这套钩子让打标签完全融入部署流程不需要任何人工干预。追踪每个环境正在跑的版本 持续部署的闭环还要能说清楚版本heroku_san 提供了现成手段rake autotag:list输出每个阶段的当前标签及其提交摘要例如** AUTO TAGGER: release tag history: ** ci a1b2c3d 新提交说明 ** staging 9f8e7d6 新提交说明 ** production none此外rake all heroku:apps可列出每个应用当前部署的 revision。想更直观examples/push_revision.rake提供了一个小技巧在after_deploy中把当前版本号写入 Heroku 的环境变量REVISION让应用自己也能在页脚或监控里显示我跑的是哪个版本。核心源码在哪看 想深入理解实现重点看这几个文件lib/heroku_san/stage.rbStage#push如何把 tag 规则解析成具体提交并推送lib/heroku_san/git.rbgit_tag如何用git tag -l通配匹配最新标签lib/heroku_san/tasks.rbheroku:deploy任务与before_deploy/after_deploy回调的触发时机examples/deploy_strategies.md部署策略模式说明教你如何定制 push 之外的部署动作如跳过数据库迁移README.md完整 Rake 任务清单涵盖维护模式、远程日志、控制台等运维能力。实践建议 ✅标签创建必须放在测试之后——autotag:create[ci]依赖前序任务成功这是晋级链条的第一道闸门标签前缀可自由定制但务必保持下级环境只读上级标签的单向依赖回滚也很简单给旧版本的提交重新打一个staging/标签再部署即可让 production 退回到已知好版本结合rake stage logs、rake stage console等任务部署前后随时可观测、可调试。总结heroku_san 用一份heroku.yml加几十行 Rake 任务就把CI 通过 → staging 验证 → production 晋级的持续部署链路自动化了Git 标签是版本的通行证tag 通配符是环境的守门员after_deploy钩子是自动打章的盖章机。配置一次之后每次发布只需一条命令还能随时用autotag:list说清楚每个环境跑的是哪次构建——这正是多环境部署该有的样子。【免费下载链接】heroku_sanHelpful stuffs for Heroku.项目地址: https://gitcode.com/gh_mirrors/he/heroku_san创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考