在 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 环境中是否有任何关于代码签名的特殊注意事项？

  • 我曾被提示输入我正在使用的 Apple 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 中，而证书和私钥安装在您的钥匙串中。” （来自 fastlane 文档） 因此无需清除存储库或担心它。

Xcode 协同设计功能：

使用 fastlane 匹配的最佳方法是使用手动配置的签名并参考上面的文章。基本上从存储库获取证书后，您可以在 Xcode 上选择它们。它通常开始于match ...