我们如何改进Conichi的iOS发布过程

我一直在为conichi工作，目前正在领导iOS开发团队。 最近，我们大大改进了发布过程，从而节省了合理的时间并降低了人为错误的可能性。

目前，我们的团队正在研究两个iOS应用程序： guest和商人 ，以及我们与合作伙伴共享并在guest虚拟机应用程序中使用的SDK 。 因此，现在，当您获得一般概述时，让我们转到有趣的部分-发布过程的演变。

回到过去

专注于访客和商家应用程序，初始发布过程非常简单：

一旦我们不得不从来宾应用程序的master分支调试应用程序商店版本，并且很难找到正确的提交，我们就开始为iOS应用程序和SDK使用github版本。 这对我们控制应用程序每个版本的代码库有很大帮助。

我们决定对github发行版和Fabric构建同时发布发行说明，这迫使我们的发行流程进行了下一次更改。 通过在特定时间段内查看已解决的JIRA问题，可以手动完成此操作。 没什么大不了的，但是最终浏览所有问题并从中创建摘要很烦人。

如您所见，它在“推入织物”上循环了6个步骤。 因为如果我们的测试人员发现错误，我们需要修复它并再次重复所有步骤。 您可以想象我们花了多少时间。

我们的CI仅在一个模拟器上的每个PR上运行测试，并且在遇到几个特定于平台/ iOS SDK的错误之后，我强制要求在将新版本发布到Fabric或App Store之前，在所有受支持的设备上运行测试。 因此，最终我们发布iOS应用程序所采取的所有步骤是：

这最终使我发疯，我开始寻找使所有这些自动化的东西。

如今

快车道

幸运的是，我几个月前读了有关fastlane的书，这对我来说是一个很好的机会。 我从项目的自述文件开始，也发现此回购与其他团队的fastfile示例非常有用。 我从附庸风雅的iOS项目中汲取的大部分灵感。

由于我们有两个应用程序： 来宾和商人，所以我最终得到了共享的fastfile和实用程序操作，并为每个应用程序指定了项目特定的fastfile。 我不会在这里深入介绍fastfile的实现，相反，我开放了我们的示例，并提供了其中大部分通道的描述。

危险

这是一个很好的开始，但是比起我们如何将CHANGELOG文件保持最新面临一个问题。 再说一次，最近一些很酷的家伙创建了一个名为Danger的项目。 其目的是为团队规范拉取请求规则。 因此，我为PR创建了一条规则-如果修改/添加/删除了50行以上，并且没有特定的标记可以跳过更改日志验证，则它必须包含CHANGELOG文件修改。