Ohhnews

分类导航

$ cd ..
Jetbrains Blog原文

设计 Kotlin Multiplatform 与 TeamCity 集成

#kotlin multiplatform#teamcity#ci/cd#ios 发布#开发工具

在本文中，我将分享我们如何为 Kotlin Multiplatform 设计并构建全新的 TeamCity 集成。我们的引导式入门流程可帮助面向 iOS 开发的 KMP 开发者从第一次 Git 推送开始，一路完成经过测试的构建、TestFlight 发布和全自动流水线，而且这一切都能在他们的 IDE 内完成。

[LOADING...]

让 iOS 发布更易上手

发布 iOS 应用通常是开发中最困难的环节之一。在与开发者交流并了解他们的工作流程时，我们不断听到同样的挑战：

  1. iOS 构建需要 macOS 基础设施，这对许多跨平台开发者来说既昂贵又陌生。
  2. Apple 签名与描述文件配置是首次发布到 App Store 时公认的障碍。
  3. 从 IDE 到运行 CI 之间没有引导路径，这意味着开发者完成应用后，不得不在开发环境之外从头摸索 CI/CD。

我们也注意到自身产品的一个缺口：当开发者刚推送到 GitHub 并心想“也许我该设置 CI 了”的那一刻，TeamCity 却完全不见踪影。

面对所有这些痛点，我们的目标很简单：让 KMP iOS 开发者无需事先了解 CI/CD，也无需 Mac，就能以最少配置从第一次推送走到运行 iOS 流水线。TeamCity Cloud 提供托管的 macOS 代理，以及带有每月构建分钟数额度的免费入门套餐，因此无需自行准备任何资源，试用也不花钱。

[LOADING...]

概念探索

我们的指导原则是渐进式引导。我们只向开发者索取当前步骤所需的最少输入，并且只有当他们取得实际成果后，才进入下一步。

我们围绕这一原则构建了整个流程，共分为三个阶段，每个阶段都会给开发者留下实实在在的成果：

  1. 构建与测试——插件会生成流水线配置，创建 TeamCity Cloud 工作区，并在托管的 macOS 代理上构建和测试 iOS 应用，最终让开发者得到一个绿色的构建结果和测试结果。
  2. 发布——配置好签名后，流水线会生成已签名的构建并将其上传到 TestFlight，首次让应用运行在真实设备上。
  3. 自动化——当应用能够成功构建和发布后，我们会建议连接 GitHub 仓库。从那时起，每次推送都会自动触发流水线，CI/CD 自行运转。

在设计任何界面之前，我们先梳理了整个旅程，总计 10 个步骤。把顺序做对——该请求什么、何时请求，以及开发者能得到什么回报——比任何单个界面都更重要。

[LOADING...]

设计验证

该设计在与产品和工程团队的紧密协作下经历了多轮迭代。悬而未决的技术问题——例如签名证书将存储在哪里、Bundle ID 能否自动检测——都在相关界面定稿前与团队一起解决，而不是让设计去迁就尚未解决的技术问题。

6 月，我们与 KMP 开发者进行了约 10 场有主持人的可用性测试，让他们走完整个设计原型。这些测试验证了我们的期望：没有 CI/CD 背景的参与者也能跟随引导路径，并一路走到成功界面。测试也暴露了一些摩擦点，我们在发布前已加以解决。

设计决策

在恰到好处的时刻触达开发者

该流程恰好在问题开始的地方启动。开发者推送项目后，KMP 插件会显示一个带有 Configure CI 选项的工具提示。用户无需搜索、无需绕道查阅文档，也无需离开 IDE，即可配置 CI。

安装 TeamCity 插件成为同一流程的一部分，而不是一个独立步骤。一旦开发者开始想 “我该设置 CI 了”，TeamCity 就会在那时出现。

[LOADING...]

开发者始终掌控一切

插件会生成四个文件：teamcity.yaml（流水线定义），以及负责发布处理的 Fastfile、Appfile 和 Gemfile。在首次构建开始前，这四个文件都会展示出来供审查，并且它们保留在本地，不会被提交。

首次构建在远程运行。TeamCity 会在托管的 macOS 代理上使用这些本地文件进行构建和测试，因此开发者可以在任何内容进入版本控制之前验证流水线是否可用。整个流程的最后一步，是由开发者自己提交并推送这些配置文件。

[LOADING...]

一个表单搞定 Apple 签名

签名是大多数首次发布 iOS 应用的开发者会放弃的环节。在我们的流程中，这一步只需一个表单，要求填写 App Store Connect API 密钥详情（issuer ID、key ID 和 .p8 私钥）、团队 ID 和 Bundle ID，以及分发证书。TeamCity 会将这些信息安全地存储为部署凭据。

最终流程会把 TestFlight 庆祝界面保留到应用发布成功时，把完成状态保留到自动化完全配置好时。

[LOADING...]

我们交付了什么

该流程带领 KMP 开发者从首次推送后的 IDE 工具提示开始，经过流水线生成与审查、TeamCity Cloud 账户创建、带测试结果的绿色构建，以及 TestFlight 发布，一路走到由 GitHub 触发的自动化。

仓库连接后，每次推送都会在托管的 macOS 代理上启动构建、运行测试、对应用签名，并将其上传到 TestFlight。

Kotlin Multiplatform 文档为该流程提供了一篇教程：Configure an iOS delivery pipeline for your Kotlin Multiplatform project，它现在已是标准 KMP 发布指南的一部分。

我们还会跟踪用户如何走完整个流程，从首次推送到首次流水线运行，以便了解他们在哪里成功、在哪里流失，以及下一步该改进什么。