Tag: 贾斯汀·辛格

使用Fastlane从疯狂中拯救您的手机

当您开始编写iOS应用程序时，通常会专注于构建和交付该应用程序。 这意味着要编写代码，也许要进行一些单元测试以确保您的逻辑能够按预期工作，并需要一个或两个脚本来在持续集成系统中构建和运行您的应用程序。 然后，如果碰巧，您的应用程序将受到青睐，您将获得很多客户。 很多很多很多客户。 也许像我们一样，您的客户将需要您的应用以自己的艺术品品牌化。 因此，您编写了一个小的Bash脚本，可以在需要时将其替换为您的图稿。 然后，您的某些客户需要其他客户不想要的特殊一次性功能。 这些客户对您的公司至关重要，因此您可以编写功能并通过特殊的属性文件与另一个启用或禁用该功能的小型Bash脚本组合来对其进行管理。 一段时间后，您的客户群将增长，您的团队将像我们一样增长，并且小型Bash脚本的规模和复杂性将会增长。 很快，其他团队成员将无法理解所有内容如何融合在一起，一个小的更改可能以意想不到的方式破坏其他内容，并且每当需要在构建中进行某些更改时，每个人都会畏缩。 使用Bash构建的复杂构建系统就是这种痛苦。 在Appian，我们的构建系统陷入了这种悲惨的境地。 在几次事件要求我们争先恐慌地修复构建系统更改以重新启用我们无意间破坏的功能之后，我们对系统的信心一直处于低位，压力水平超出了预期。 退后一步，我决定必须做些事情。 我们的构建系统需要修复。 我在团队中提出来，我们考虑使用Python，Swift或Ruby构建我们自己的系统，以便获得高级语言的好处。 我们决定不这样做，因为我们不想重新发明轮子，这将花费很长时间。 那就是我们开始寻找更好的东西的时候。 值得庆幸的是，我的一位同事找到了快车道。 我马上就知道快车道很特别。 它为安装不同版本的Xcode提供了支持； 它承诺会自动上传到TestFlight； 它使自动化测试的输出看起来如此简洁明了。 它是用高级语言Ruby编写的，它使我们能够构建模块化，可理解且可测试的构建系统。 我使用Appian的IndieTime（类似于Google的20％的时间）将整个构建系统转换为使用fastlane，结果是纯粹的欢乐 。 现在，我们可以依靠为所有不同的构建选项获得正确的结果。 我们的开发人员发现，它更易于理解和更改构建系统，而复杂的项目更改则更容易实现。 使用新系统，我们获得了很多好处。 这三个最突出： 1.使用RSpec的自测试构建系统 当我们在构建系统中使用Bash脚本时，很难确保仍正确构建所有配置。 当我们添加新功能或修改系统时，很容易犯一个错误并引入一个错误，该错误有时几个月都不会出现，直到我们需要向客户提供其自定义版本为止。 当确实出现此类错误时，可能需要很长时间才能确定根本原因，然后正确解决。 有了基于Ruby的fastlane工具集和RSpec，我就能够对整个系统进行单元测试。 现在，每当我们添加涉及对构建系统进行更改的新功能时，我们都会添加单元测试。 我们的持续集成系统运行160多个测试，以确保我们正确构建不同的iOS配置。 2.使用快速通道的简化逻辑 使用Bash，为了不破坏我们现有的构建脚本并节省时间，开发人员将复制Bash脚本并调整副本。 我们的iOS代码库最终以许多几乎相同的脚本以及晦涩，纠结和难以理解的代码为结尾。 过渡到Fastlane时，我们的一位开发人员建议将每个构建都视为自定义构建。 因此，现在，每个构建都遵循相同的自定义路径： 我们的App Store应用， 我们内部的应用程序 我们的HockeyApp 和为我们的客户定制品牌的应用程序。 这样，我们可以确保我们所有的构建工作正常进行，或者我们可以很快发现是否损坏了某些东西。 例如，这对我们有何帮助：Apple刚刚添加了一项新要求，即我们需要将iTunes图稿与应用程序捆绑在一起。 为了进行更改，我们仅添加了6行以支持所有不同的版本： 我们的产品经理无法相信为我们提供的所有构建配置支持此功能多么容易 。 3.使用Xcodeproj进行简单但复杂的项目操作 通过对自定义属性（也称为功能切换）进行运行时检查，可以轻松管理客户在应用程序中所需的一些独特功能，而其他功能则需要对项目进行更基本的更改。 有时，这些更改与我们其他客户的需求不兼容。 […]