在RedMart发售iOS

每个人都喜欢运输软件! 有什么比在AppStore上发布代码更好呢?
在本博文中,我们将简要介绍如何改进iOS应用的构建和发布过程。

工具和基础设施:

TL; DR: TravisCI + Fastlane

过去,我们的iOS应用发布过程涉及通过Xcode / Application-loader上传软件包。 我们以前有shell脚本来自动执行此操作,但是由于一段时间未使用/维护,因此它们不适用于最新版本的Xcode。

因此,我们可以选择理解和修复这些脚本,但是我们意识到,最好投资以下内容:

1)易于理解和使用。
2)易于构建。
3)从长远来看,每当Xcode和iTC进行更改时,维护都很容易。

Fastlane是我们要考虑的问题,因为它似乎可以选中复选框,而我们的开发人员也可以根据以前的经验对它说好话。

通过在Fastlane中使用Match获得的另一个好处是,我们不再需要为每个开发人员管理多个证书和配置文件,因为单个副本已加密并存储在其自己的存储库中,从而易于维护开发人员端口且没有依赖性在开发人员/计算机上进行发布。

至于硬件,Travis与GitHub集成良好,我们将其用于RedMart的其他项目,因此我们决定使用它。

处理:

TL; DR:发布计划。 一点点纪律会让每个人都开心。

有时候我们一周内要发布多个版本,如果我们计划好发布并更好地管理期望,回想起来可以避免。

因此,我们引入了发布时间表。 这使我们的发布周期可预测,从而使我们的质量检查人员可以相应地计划其日历,还可以使其他利益相关者对何时可以启用某个特定功能有清晰的了解。

因此,我们的发布时间表如下所示:

1)我们在每个星期五将RC进行质量检查,并将其狗食化
2)团队在周末使用此RC进行购物。 这有助于我们及早获得反馈/关注。
3)我们的质量检查人员会在星期二早上批准我们,并进行自动回归测试并根据更改日志进行手动检查。
4)如果一切顺利,我们将发布所有更改。 否则,我们将还原错误的提交并继续进行发布。

由于iOS App版本在批准/上线时间(通常为12小时)和构建版本在用户设备上的分散性方面相对昂贵,因此,我们尝试为母版上的代码留出足够的时间以供质量检查和测试使用内部测试小组上线之前。

总而言之,这种设置节省了我们无数小时的时间和精力。 现在,我们只需要触发构建并接一位同事玩桌上足球🙂

摘要:

最初发布在geeks.redmart.com