运行

Tuist 采用持续发布系统，每当有意义的变更合并到主分支时，系统就会自动发布新版本。这种方法可确保改进内容迅速送达用户，而无需维护人员进行人工干预。

概述

我们持续发布三个主要组件：

• Tuist CLI - 命令行工具
• Tuist 服务器 - 后台服务
• Tuist 应用程序 - macOS 和 iOS 应用程序（iOS 应用程序仅持续部署到 TestFlight，请参阅 此处）。

每个组件都有自己的发布管道，每次推送到主分支时都会自动运行。

工作原理

1.承诺公约

我们使用 Conventional Commits 来构建提交信息。这样，我们的工具就能理解变更的性质，确定版本升级，并生成适当的变更日志。

格式：类型（范围）：描述

承诺类型及其影响

类型	描述	版本影响	示例
绝技	新功能或能力	小版本升级（x.Y.z）	feature(cli)：添加对 Swift 6 的支持
定格	错误修复	补丁版本的提升（x.y.Z）	fix(app): 解决打开项目时崩溃的问题
文档	文件更改	未发布	文档：更新安装指南
风格	代码样式更改	未发布	style：用 swiftformat 格式化代码
重构	代码重构	未发布	重构（服务器）：简化认证逻辑
敷衍	性能改进	补丁版本提升	perf(cli): 优化依赖关系解析
测试	测试增加/更改	未发布	测试：为缓存添加单元测试
苦差事	维护任务	未发布	苦差事：更新依赖关系
ci	CI/CD 变化	未发布	CI：为发布添加工作流程

突破性变化

破坏性修改会触发主要版本升级（X.0.0），应在提交正文中注明：

feat(cli): change default cache location

BREAKING CHANGE: The cache is now stored in ~/.tuist/cache instead of .tuist-cache.
Users will need to clear their old cache directory.

2.变化检测

每个组件都使用 git cliff 来运行：

• 分析自上次发布以来的提交情况
• 按范围（客户端、应用程序、服务器）过滤提交
• 确定是否存在可发布的变更
• 自动生成更新日志

3.释放管道

检测到可释放更改时：

1. 版本计算 ：流水线确定下一个版本号
2. 更新日志生成 ：git cliff 从提交信息中创建更新日志
3. 构建过程 ：构建和测试组件
4. 发布创建 ：创建包含工件的 GitHub 发布版本
5. 发布 ：更新推送至软件包管理器（如用于 CLI 的 Homebrew）

4.范围过滤

每个组件只有在有相关变更时才会发布：

• CLI: 提交范围为(cli) 或无范围
• 应用程序 ：包含(app) 的提交 范围
• 服务器 ：(服务器) 范围的提交

编写良好的提交信息

由于提交信息会直接影响发布说明，因此编写清晰、描述性强的信息非常重要：

做：

• 使用现在时态："添加功能 "而不是 "增加功能"
• 简明扼要，但要有描述性
• 当更改是针对特定组件时，应包括范围
• 适用时引用问题：fix(cli)：解决构建缓存问题 (#1234)

不要

• 使用 "修复错误 "或 "更新代码 "等含糊不清的信息
• 在一次提交中混合多个不相关的更改
• 忘记包含中断更改信息

突破性变化

对于破坏性更改，请在提交正文中包含BREAKING CHANGE: ：

feat(cli): change cache directory structure

BREAKING CHANGE: Cache files are now stored in a new directory structure.
Users need to clear their cache after updating.

发布工作流程

发布工作流程在

• .github/workflows/cli-release.yml - CLI 版本
• .github/workflows/app-release.yml - 应用程序版本
• .github/workflows/server-release.yml - 服务器版本

每个工作流程：

• 通过推动主电源运行
• 可手动触发
• 使用 git cliff 进行变更检测
• 处理整个发布流程

监测释放情况

您可以通过以下方式监测发布情况：

• GitHub发布页面。
• 工作流程运行的 GitHub 操作选项卡
• 每个组件目录中的更新日志文件

益处

这种持续发布方法提供了

• 快速交付 ：更改合并后立即送达用户
• 减少瓶颈 ：无需等待手动发布
• 清晰的沟通 ：从提交信息中自动生成更新日志
• 一致的流程 ：所有组件的发布流程相同
• 质量保证 ：只发布经过测试的更改

故障排除

如果释放失败：

1. 检查 GitHub 操作日志，查看工作流程是否失败
2. 确保提交信息遵循常规格式
3. 验证所有测试通过
4. 检查组件是否成功构建

用于需要立即发布的紧急修复：

1. 确保您的承诺有明确的范围
2. 合并后，监控发布工作流程
3. 如有需要，触发手动释放装置

应用商店发布

虽然 CLI 和服务器遵循上述持续发布流程，但iOS 应用程序 是一个例外，因为苹果公司的 App Store 审核流程是这样的：

• 手动发布 ：iOS 应用程序的发布需要手动提交到 App Store
• 审核延迟 ：每个版本都必须通过苹果公司的审核流程，可能需要 1-7 天的时间
• 批量更改 ：在每个 iOS 版本中，通常会将多个更改捆绑在一起
• TestFlight ：测试版可在应用商店发布前通过 TestFlight 发布
• 发布说明 ：必须专为应用程序商店指南编写

iOS 应用程序仍然遵循相同的提交约定，并使用 git cliff 生成更新日志，但实际向用户发布的频率较低，而且是手动发布。