Designing the Kotlin Multiplatform and TeamCity Integration
TL;DR · AI 摘要
Designing the Kotlin Multiplatform and TeamCity Integration - The JetBrains Blog TeamCity Powerful CI/CD for DevOps-cent...
核心要点
- 主题聚焦：Designing the Kotlin Multiplatform and TeamCity
- 来源：The JetBrains Blog，建议结合原文判断细节。
- AI 分析暂不可用，本条为保底评分与摘要。
设计 Kotlin Multiplatform 与 TeamCity 集成 - JetBrains 博客
TeamCity
面向 DevOps 团队的强大 CI/CD 解决方案
关注
- 关注:
- X X
- YouTube YouTube
- RSS RSS
获取 TeamCity
设计 Kotlin Multiplatform 与 TeamCity 集成
Bozidar Rakicevic
在本文中，我将分享我们如何设计和构建 Kotlin Multiplatform 的新 TeamCity 集成。我们的引导式入门流程帮助 KMP 开发者在 iOS 开发中，从第一次 Git 提交到构建测试、TestFlight 发布以及全自动流水线，所有操作都可以在 IDE 中完成。
让 iOS 发布更易上手
发布 iOS 应用通常是开发过程中最具挑战性的部分之一。通过与开发者交流并了解他们的工作流程，我们反复听到相同的痛点：
- iOS 构建需要 macOS 基础设施，这对许多跨平台开发者来说既昂贵又陌生。
- 苹果签名和配置设置是首次发布到 App Store 的已知障碍。
- 从 IDE 到运行 CI 没有明确的指导路径，这意味着开发者完成应用后，必须完全在开发环境之外自行解决 CI/CD 问题。
我们也注意到自身存在空白：当开发者向 GitHub 推送代码并思考“我应该设置 CI”的时候，TeamCity 却完全不在视野范围内。
面对这些挑战，我们的目标非常明确。让 KMP iOS 开发者能够通过最少的配置，从第一次提交直接运行 iOS 流水线——无需任何 CI/CD 知识，也无需 Mac。TeamCity Cloud 提供托管的 macOS 代理和免费的入门层级，每月提供一定量的构建分钟数，因此无需任何配置，也无需成本即可尝试。
概念探索
我们的核心原则是渐进式引导。我们向开发者请求当前步骤所需的最小输入，只有在他们完成具体目标后才会进入下一步。
我们围绕这一原则构建了流程，分为三个阶段，每个阶段都为开发者提供可实际带走的成果：
- 构建与测试 – 插件生成流水线配置，创建 TeamCity Cloud 工作区，并在托管的 macOS 代理上构建和测试 iOS 应用，为开发者留下绿色构建和测试结果。
- 发布 – 在完成签名配置后，流水线生成已签名的构建包并上传至 TestFlight，首次将应用部署到真实设备。
- 自动化 – 当应用能够成功构建和发布后，我们建议连接 GitHub 仓库。从此之后，每次提交都会自动触发流水线，CI/CD 完全自动运行。
我们首先绘制了完整的旅程地图，共 10 个步骤，之后才开始设计界面。正确安排流程顺序（何时询问什么内容，开发者能获得什么回报）比任何单个界面都更重要。
6月，我们与KMP开发人员进行了大约10场有主持人引导的可用性测试，他们完整体验了设计原型。测试结果验证了我们的预期：没有CI/CD背景的参与者能够沿着引导路径顺利操作，直至看到成功页面。同时，测试也暴露了一些摩擦点，我们在发布前已解决这些问题。
设计决策
在恰到好处的时刻接触开发者
该流程从问题发生的起点开始。当开发者推送项目后，KMP插件会显示一个带有"配置CI"选项的提示框。用户无需搜索、无需查阅文档、无需离开IDE即可完成CI配置。
安装TeamCity插件成为流程的一部分，而非独立步骤。当开发者开始思考"我应该设置CI"时，TeamCity就会在此时出现。
开发者始终掌握控制权
插件生成四个文件：teamcity.yaml（流水线定义）以及处理发布的Fastfile、Appfile和Gemfile。在首次构建开始前，所有文件都会显示供用户审查，并且这些文件会保持本地状态且未提交。
首次构建在远程执行。TeamCity会在托管的macOS代理上构建和测试本地文件，使开发者能够在任何代码进入版本控制之前验证流水线是否正常工作。整个流程的最后一步是开发者亲自提交并推送配置文件。
苹果签名的单一表单
签名是大多数初次发布iOS应用的开发者放弃的环节。在我们的流程中，这一步仅需填写一个表单，需要App Store Connect API密钥信息（发行人ID、密钥ID和.p8私钥）、团队ID和包ID，以及分发证书。TeamCity会将这些信息存储为安全的部署凭证。
最终流程将TestFlight庆祝页面保留到应用发布时，并将完成状态保留到自动化完全配置时。
我们发布的功能
该流程引导KMP开发者从首次推送后的IDE提示，经过流水线生成与审查、TeamCity Cloud账户创建、带有测试结果的绿色构建，以及TestFlight发布，最终实现GitHub触发的自动化。
一旦仓库连接成功，每次推送都会在托管的macOS代理上启动构建，运行测试，签署应用，并上传到TestFlight。
Kotlin Multiplatform文档提供了该流程的教程《为Kotlin Multiplatform项目配置iOS交付流水线》，现已纳入标准KMP发布指南。
我们还追踪用户在流程中的行为轨迹，从首次推送至首次流水线运行，从而了解用户成功节点、流失环节以及需要改进的方面。
design
- 分享
上一篇
TeamCity 2026.2：流水线正式发布、AI助手BYOK功能及其他