#1即时发布

作为iOS开发人员,您需要持续交付的3个原因

持续交付是iOS开发人员一直在寻求的解决方案,可帮助他们自动化重复执行的持续发布管理工作,也就是说,将其应用程序从Xcode移交给测试人员和用户。

尽管在功能和错误开发方面花了很多时间,但许多iOS开发人员仍继续手动构建并发布iOS应用更新到其测试人员和应用商店。 他们的发布管理策略包括在Xcode上构建并导出一个ipa,以在TestFlight上与他们的测试人员一起验证其最新版本,手动摸索其配置文件和证书,并且不得不定期处理繁琐的推送到App Store的繁琐工作,这很浪费宝贵的时间,并且在大多数情况下,可能会将人为错误引入到任务中。 这就是持续交付拯救移动开发人员的地方。 作为iOS开发人员,您需要持续交付的三个原因如下:

通过专注于他们最擅长的事情,开发人员将更少的时间花在摆弄Xcode,iTunes Connect和Developer Portal上,以处理预配置文件,证书以及准备和分发您的应用程序所伴随的所有怪癖前往TestFlight和App Store。

您可以不必依赖产品经理来更新应用程序,而可以依靠连续交付来使流程自动化,这样您就可以定期进行每日TestFlight内部分发,或者利用诸如Jenkins CI的持续集成平台,可以根据合并到存储库中的新代码来分发新的iOS应用。

从Xcode到iPhone,这可能是一个非常繁琐的过程,并且允许自动化系统按逻辑顺序执行这些任务,您的产品经理感到高兴,您的客户也很高兴能立即期待您的应用程序有全新的构建。

无论其他更改的大小和范围如何,Facebook都会定期向App Store发行版本,无论更改的大小和范围是每周还是每隔一周,这都是很重要的,因为它调整了客户的期望,可以征求即时响应

产品所有者可以验证功能的唯一方法是实际使用该应用程序。 将您的应用众包到Beta测试人员可以进一步验证概念和想法,还可以捕获由于您离项目太近而可能未发现的模糊错误。

持续交付可确保您的产品所有者,Beta测试人员和实际用户获得定期的定期更新,而无需开发人员每次都手动发布该应用程序,从而在应用程序中修复或功能重新开发方面具有即时响应能力。 持续集成的相同方式使开发人员可以立即对代码错误做出反应。

在过去的五年左右的时间里,当代的开发实践已朝着连续性方向发展,使团队具备了连续测试代码的能力。 在新兴企业需要即时反馈的市场中, 持续集成已进入确保新代码推送不会破坏现有功能的阶段。 在微观层面上,开发人员还一直追求连续测试的口号,将其作为测试驱动开发的一部分,这使每个开发人员都有责任确保代码在通过一系列测试用例和套件之前无法通过。

能够通过更短的周转时间快速解决问题,获得用户的反馈,从而降低了发行周期较长时通常预期的风险。 必须依靠带有大量更改的大版本发布仪式,这意味着您将把开发时间和精力投入到未经验证的计划中,实际上,您可能会通过无法控制的代码更改记录和更广泛的代码覆盖范围掩盖技术上的债务和问题。 较短的迭代次数等于较低的风险周期。

Doron Katz是《 使用Fastlane进行移动持续交付 》一书的作者,这是 学习从代码签名,持续测试,构建,部署和发布应用程序的持续部署和自动化的精典指南