设计 Kotlin Multiplatform 与 TeamCity 的集成
内容提要
JetBrains 为 Kotlin Multiplatform 开发者推出 TeamCity 集成，解决 iOS 发布依赖 macOS 环境、签名配置复杂、缺少 IDE 内 CI 引导等痛点。流程分三阶段：构建测试、发布至 TestFlight、GitHub 自动化。插件生成四个配置文件供审查，首次构建在云端 macOS 代理运行，签名仅需一个表单。经可用性测试验证后发布。
延伸解读
渐进式引导的设计逻辑
文章强调“渐进式引导”原则：每一步只要求开发者提供当前所需的最小输入，完成具体成果后再进入下一步。三阶段分别产出绿色构建、TestFlight 发布和 GitHub 自动化，让开发者始终有可验证的阶段性成果。这种设计降低了首次接触 CI/CD 的认知负担，也避免了因一次性配置过多而中途放弃。
本地文件与远程构建的信任机制
插件生成四个配置文件（teamcity.yaml、Fastfile、Appfile、Gemfile），首次构建在云端 macOS 代理上运行，但文件保持本地且未提交。开发者可先验证流水线是否工作，再决定是否提交到版本控制。这一设计把控制权留给开发者，同时利用 TeamCity Cloud 的托管代理消除了对本地 Mac 硬件的依赖。
签名环节的简化与凭证管理
Apple 签名和描述文件配置是首次发布 iOS 应用的主要障碍。该集成将签名简化为一个表单，要求填写 App Store Connect API 密钥信息（issuer ID、key ID、.p8 私钥）、团队 ID、Bundle ID 和分发证书。TeamCity 将这些存储为安全的部署凭证，减少了手动配置的复杂度和出错概率。
可用性测试验证与后续迭代
设计经过多轮迭代，并与产品和工程团队协作解决技术问题（如证书存储位置、Bundle ID 自动检测）。2024 年 6 月进行了约 10 次有主持的可用性测试，参与者无 CI/CD 背景也能跟随引导完成流程。测试还发现了摩擦点并在发布前修复。发布后团队持续追踪用户从首次推送到首次流水线运行的转化，以识别成功与流失环节。
Q&A
Kotlin Multiplatform 与 TeamCity 集成主要解决了哪些痛点？
主要解决三个痛点：iOS 构建需要 macOS 基础设施，成本高且对跨平台开发者不熟悉；Apple 签名和配置文件设置是首次发布 App Store 的常见障碍；从 IDE 到运行 CI 缺乏引导路径，开发者完成应用后必须在开发环境之外自行摸索 CI/CD。
这个集成的工作流程分为哪几个阶段？
分为三个阶段：构建和测试（生成流水线配置、创建 TeamCity Cloud 工作区、在托管的 macOS 代理上构建和测试 iOS 应用）；发布（配置签名后生成签名构建并上传到 TestFlight）；自动化（连接 GitHub 仓库，每次推送自动触发流水线）。
集成如何确保开发者保持控制权？
插件生成四个文件：teamcity.yaml（流水线定义）以及处理发布的 Fastfile、Appfile 和 Gemfile。所有文件在首次构建前都会展示供审查，并保持本地未提交状态。首次构建在远程托管的 macOS 代理上运行，开发者可以验证流水线是否正常工作，最后一步由开发者自己提交并推送配置文件。
Apple 签名步骤需要提供哪些信息？
签名步骤只需一个表单，要求提供 App Store Connect API 密钥详情（颁发者 ID、密钥 ID 和 .p8 私钥）、团队 ID 和捆绑包 ID，以及分发证书。TeamCity 将这些存储为安全的部署凭据。
这个集成经过了怎样的设计验证？
设计经过多次迭代，与产品和工程团队紧密合作。2026 年 6 月，进行了约 10 次有主持的可用性测试，让 KMP 开发者走完整个设计原型。测试确认没有 CI/CD 背景的参与者也能遵循引导路径，并一直进行到成功屏幕，同时也发现了摩擦点并在发布前解决。
集成发布后，开发者如何获得相关文档？
Kotlin Multiplatform 文档提供了该流程的教程：“为你的 Kotlin Multiplatform 项目配置 iOS 交付流水线”，该教程现在是标准 KMP 发布指南的一部分。
