在 CI 上使用 Fastlane 进行代码签名的最佳方式

Question

在您对我的问题生气之前，我知道没有一种最佳方式来设置 Fastlane，但我想更好地了解您可以使用的不同方法开始使用时服用。

我正在为一个项目设置 Fastlane。现在我只在我的本地机器上拥有它，但我想在 CI 环境中设置它（在我的情况下是 GitLab-CI，但我想它并不那么重要）。

披露，我不仅是设置 Fastlane 的新手，而且也是自己设置 CI 的新手（不过我都用过，????）

阅读代码符号 (https://docs.fastlane.tools/codesigning/getting-started/) 的文档后，我可以看到不同的替代方案，但我不确定它们在 CI 环境中的限制是什么。总之，在以下情况下签署构建的最佳做法是：提交到 Testflight、运行单元测试、提交到 AppStore 等等。

选项有：

• match
• cert 和 sigh
• Xcode 的代码设计功能
• 手动

到目前为止我的论文：

• match:

  • 设置和使用比其他选项更难，但有一个指南：https://codesigning.guide/
  • 在我看来，这是最“专业”的选择。
  • 我知道，对于现有项目，它会撤销当前证书。
    1. 是第一次吗？
    2. 如果 Fastlane 已经在使用新证书，那么当前证书被吊销的陷阱是什么？我看到很多人试图阻止这种情况（例如this）。但是，现在只有我作为开发人员，我们没有任何 CI，所以我猜它不会对我造成太大影响。不过，这对于其他项目设置来说很方便。
  • 对于此设置，您需要一个私有存储库来存储加密证书。
    1. 当我与我的 Android 同事讨论这个问题时，他对使用版本控制系统来存储证书感到非常惊讶。
    2. 究竟是什么原因？我的理解（也许我错了）是，通过这种方式，团队中的所有开发人员都可以从match 中受益，从而拥有一个有效的开发配置文件。不确定发布到 Testflight/Appstore 的好处。

• cert 和sigh：

  • 使用它只需要在 build_app 之前写几行：

    get_certificates         # cert
    get_provisioning_profile # sigh
    build_app
    

  • 它将证书和配置文件下载到项目的根目录中。

    1. 我想应该有一种方法可以指定将它们放在哪里而不是那里，也许吧？
    2. 之后我们应该忽略这些文件或清理存储库。我认为不应该将它们提交到存储库。
    3. 它需要这个带有 app_identifier、apple_id 等的 Appfile，或者至少是我第一次设置 Fastlane 时 Fastlane 自动创建的那个。

• Xcode 代码设计功能：

  • 给 build_app 额外参数：

    build_app(workspace: "Chordify.xcworkspace", scheme: "Chordify", export_xcargs: "-allowProvisioningUpdates")
    

  • 这相当于在 Xcode 上自动管理签名（但在命令行上默认禁用）

    1. 此设置对 CI 有意义吗？
    2. 我猜它还需要这个带有 app_identifier、apple_id 等的 Appfile。

• 手动：

  • 我对此的唯一结论是手动设置并不容易。我不确定自己做错了什么，但我无法使用此设置构建（甚至从 Xcode 构建），因此我放弃了此选项。

Fastlane 有一组真实示例，因此您可以看到他们的 Fastfile、Appfile、Gymfile、Metadata，... (https://github.com/fastlane/examples)。这很棒，但是，没有共同的模式，我看不出他们采用这种或那种方法的原因。

关于使用 Fastlane 进行代码签名的其他一般性问题：

• 我们需要带有苹果 ID 的 Appfile 吗？在这种情况下，为此目的创建一个特定的 ID 是有意义的，对吧？例如，开发人员角色？

• 安全性 vs 实用性 vs 易用性/设置。这些概念是否与一种方法紧密相关？

• 在什么情况下什么是最好的？ （想想大团队和小团队；每个人都应该能够使用它，而应该有一些安全限制；需要 CI 集成；...）

• 最后但同样重要的是...对于 CI 环境是否有任何关于代码签名的特殊注意事项？

  • 曾经提示我输入我正在使用的苹果 ID 的凭据。当然，在 CI 环境中，您无法提示输入任何凭据，因为它在某个构建服务器上运行

Answer 1

尽管这是很久以前提出的并且问题非常广泛，但我建议阅读我写的这篇文章，涵盖了您的大部分问题：https://medium.com/revelo-tech/setting-up-automatic-ios-release-with-fastlane-and-match-on-ci-cd-server-16c3f1d79bc5

但让我强调一些问题和答案：

我知道，对于现有项目，它会撤销当前证书。 是第一次吗？

通常是的，但您可以随时重新生成它们（例如，当您的证书泄露时）。

如果 Fastlane 已经在使用新证书，那么当前证书被吊销会有哪些陷阱？

这没什么大不了的。这些证书与 Android 签名密钥库的工作方式不同，它们可以轻松交换。

当我与我的 Android 同事讨论这个问题时，他对使用版本控制系统来存储证书感到非常惊讶。

这对我来说也很奇怪，但上面的答案有助于解释它。 android 签名配置不会经常更改，如果泄漏也不容易更换。除此之外，iOS 证书的工作方式不同，因为如果将新设备添加到允许安装应用程序的设备列表中，则需要重新生成它们。

我想应该有一种方法可以指定将它们放在哪里而不是那里，也许吧？ 之后我们应该忽略这些文件或清理存储库。我认为不应该将它们提交到存储库。

“配置文件安装在 ~/Library/MobileDevice/Provisioning Profiles 中，而证书和私钥安装在您的钥匙串中。” (from the fastlane docs) 因此，无需清除 repo 或担心它。

Xcode 代码设计功能：

使用 fastlane match 时最好的方法是使用手动配置的签名并参考上面的文章。基本上在从 repo 获得证书后，您可以在 Xcode 上选择它们。通常以match ...开头