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

我正在为一个项目设置Fastlane。现在，我仅将其安装在本地计算机上，但我想在CI环境中进行设置（在我的情况下为GitLab-CI，但我认为它并不那么重要）。

公开，我不仅是设置Fastlane的新手，而且还是我自己设置CI的人（虽然我已经使用了它们，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. 它要求此Appfile具有app_identifier，apple_id等，或者至少是我首次设置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，元数据...（https://github.com/fastlane/examples）。这太棒了，但是，没有通用的模式，我看不出他们采用这种方法的原因。

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

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

• 安全性，实用性和易于使用/设置。这些概念是紧贴一种方法还是另一种方法？

• 什么情况下最好？ （想想大型团队还是小型团队；每个人都应该可以使用它，而应该有一些安全性约束；需要CI集成； ...）

• 最后但并非最不重要... CI环境中是否有关于代码签名的特殊注意事项？

  • 曾经提示我输入正在使用的Apple ID的凭据。当然，在CI环境中，由于它在某处的构建服务器上运行，因此您不能提示输入任何凭据