在iOS应用中管理环境
对于开发团队来说，每个项目都有多个环境是很常见的事情。 开发人员使用服务器的开发版本。 质量检查先检查开发版本，然后再检查暂存版本，简称为候选发布版本。 然后，所有这些都最终发布。
对于iOS应用程序，您可以在为每种环境创建单独的应用程序以及自定义一个应用程序以提供环境切换选项之间进行选择。
这两种方法都有优点和缺点。
每个环境“ + ”的单独应用：
- 您可以完全控制每个环境设置
- 您可以同时安装3–4-N个应用程序，只需在一个应用程序之间切换即可测试它们（无需重新登录或执行任何其他操作）
- 通过在构建时修改显示名称或图标，您可以轻松了解哪个应用程序实例适用于哪种环境
每个环境“ – ”的单独应用：
- 您将必须处理每个应用程序的配置文件和证书，并使其保持最新状态
- 如果您使用推送通知并且仍然不使用通用身份验证密钥，则最终将导致混乱的推送通知证书和沙箱/生产问题
- 构建版本将很难处理。 每个构建都是唯一的，您将无法检查确切构建在所需环境中的行为。
- 同时至少3个应用实例。 您添加了另一个环境（具有长期功能）–您将拥有另一个应用程序
- Fabric / HockeyApp / TestFlight会很拥挤
现在，让我们看一下“一个应用程序-N环境”方法。 您可以通过在应用程序内部实现自己的模块（通过摇动手势/双击屏幕上的某个位置来调用/只需根据服务器上的策略显示一个按钮）来调用该模块。
或者，您可以简单地使用Settings.bundle和标准应用程序设置。 无论哪种方式，让我们总结一下优缺点。
一个适用于不同环境“ – ”的应用程序：
- 您将无法同时使用同一应用的多个实例来检查相同的行为
- 每次环境更改后，您都必须重新登录（即使执行此过程）
- 如果从开发者切换到产品，反之亦然，推送通知可能仍无法正常工作
- Fabric临时版本无法再安装在发布/临时版本上，您必须删除该应用程序的现有实例，然后从Fabric Beta应用程序重新安装
- 您必须管理发行版本的环境首选项可用性，如果您使用testflight进行登台，这可能会很棘手（有人可能会错误地发布错误的版本）
一个适用于不同环境“ + ”的应用程序：
- 不用担心配置文件
- Appstore Connect和Fabric / HockeyApp中的苗条和简单项目结构
- 轻松的环境管理（具有预定义的选项和/或URL的自定义选项）
- 您具有一个长期功能，该功能在开发过程中仍然存在于另一个分支上，仍然需要对其进行测试吗？ 只需将新配置添加到您的设置中，然后进行重建即可开始
- 您可以检查您的开发版本如何与当前的生产API一起使用，或者您的暂存（候选版本）版本将如何管理仍在开发中的新API更改
- 简单的CI＆CD脚本
自定义应用程序模块可以派上用场，但需要一些开发。
让我们关注一种更简单的方法-iOS设置中的应用程序首选项。
首先，您需要为项目创建并注册一个Settings.bundle文件。 然后，您将需要一个Services.plist文件。
然后，使用以下环境填充Services.plist文件：
和Settings.bundle是这样的：
但这还不是全部。 您还必须在应用程序中注册设置。
但是我该如何使用呢？ 我们Actonica的Swagger使用API，并通过swagger-codegen工具为平台生成API层。 它生成一个这样的类：
因此，我们要做的就是从设置中读取并在应用启动时更改basePath属性。
只要我们对所有项目都使用这种方法，我们最终会创建一个小的swift库和一个示例项目，从中可以复制Settings.bundle和Services.plist并将其粘贴到新项目中。 现在，我们与您分享。
actonica / environmenthelper.ios
通过在GitHub上创建一个帐户，为actonica / environmenthelper.ios开发做出贡献。
github.com
您可以在此处找到阅读首选环境的方法和完整文档。
EnvironmentHelper类参考
帮助程序类，用于检测当前环境并从iOS应用程序设置中检索它
actonica.github.io
我们如何确保发行版本不会向用户透露开发人员的东西？
对于CI＆CD，我们使用gitlab和fastlane。 因此，对于发布版本，这些行在实际构建之前执行：
感谢您的阅读，希望对您有所帮助。 如有任何疑问或优惠，请随时与我们联系！