你好！我叫Mikhail Bulgakov（不，不是亲戚），我是Badoo的发布工程师。五年前，我从事了iOS应用程序发行版的自动化工作，在本文中对此进行了详细介绍。然后，我开始使用Android应用程序。
今天，我将总结一些结果：我将告诉您在这段时间里我们得到了什么。长话短说：参与此过程的任何员工都只需单击几下即可在两个平台上至少发布我们所有的应用程序-无需头痛，费时，注册和SMS。因此，我们的发布工程师部门在2019年节省了大约830小时。
有关详细信息-欢迎切入！
移动版本的背后是什么
Badoo上的应用程序发布分为三个阶段：
- 发展。
- : , — , App Store Google Play.
- , -.
当应用程序完全准备就绪并且已通过第一阶段时，重要的是不要在发布阶段对其进行修复并将产品带到“柜台”。最后一个阶段似乎是最简单的，但实际上这需要很多时间，其成功取决于少数人。
大部分时间都花在准备在App Store或Google Play中的应用展示上：您需要上传漂亮的屏幕截图，进行诱人的描述，针对更好的索引进行优化，选择要搜索的关键字。应用程序的普及程度直接取决于这项工作的质量，也就是说，实际上，开发人员，测试人员，设计师，产品经理，市场人员的活动都是产品创建过程中的结果。
如果应用程序必须以多种语言存在，则至少需要一个人或什至数名员工来准备展示：产品经理将编写描述文字，组织翻译成所有语言并准备用于创建屏幕截图的技术规范，设计师将从屏幕截图中提取屏幕截图文本覆盖，设备轮廓等，当然还有将所有屏幕截图和文本翻译成不同语言的翻译人员。
工作的最后一部分是发布过程本身。一个小型发布工程团队需要花费大量时间。在这个至关重要但相当常规的阶段，我们尝试将错误的数量和人为因素的影响降至最低。为此，首先必须自动加载元数据（应用程序展示柜的文本和图形设计）：这可以使您显着减少时间成本并快速实施业务发布（例如，为情人节设计应用程序样式）。
由于质量检查工程师团队决定在Badoo中准备发布应用程序，因此我们决定赋予他们按发布发布的“红色按钮”的权利。同时，我们希望甚至可以从移动设备访问它（以可视方式显示脚本进度）。
自动化的第一步：下载元数据
最初的工作方式：每个版本都在Google表格中创建了一个表格，产品经理在表格中填写了经过验证的英文主文本，翻译人员针对特定国家/地区，方言和受众进行了修改，然后由发布工程师转移了所有信息从App Store或Google Play中的此表中获取。
我们朝着自动化迈出的第一步是将文本翻译集成到我们的整体翻译过程中。我不会对此进行详细介绍-这是一个单独的大型系统，您可以在我们最近的文章中阅读有关该系统的信息。。要点是，翻译人员不会在平板电脑上浪费时间，并且可以使用界面方便手动加载（阅读：ctrl + c ctrl + v）str中的翻译版本。此外，还有版本控制和基础结构即代码的基础。
同时，我们添加了从数据库中卸载现成的翻译并将它们嵌入到收集的IPA文件（iOS应用程序文件扩展名）中的功能。我们在TeamCity中构建应用程序。因此，应用程序的每个版本始终具有全新的翻译，而无需在构建过程中进行人工干预。
有一段时间，我们像这样生活，总的来说，一切都适合我们。但是，应用程序的数量增加了，并且准备每个版本的时间也增加了。
截至2015年的现实
平均而言，在当前版本的屏幕快照存在的情况下，发布一个应用程序的时间大约是iOS的发布工程师花了一个半小时到两个小时，而Android的则大约是半个小时。造成这种差异的原因是，iOS应用程序必须经历所谓的“处理”，这会花费一些时间（在处理成功完成之前，无法将应用程序发送到“审阅”）。此外，对于大多数操作，App Store本身比Google Play慢得多。
很明显，我们需要一个额外的工具来将应用程序交付到商店。就在那一刻，一种名为Fastlane的产品开始在开源市场上获得普及。尽管当时他仍然很潮湿，但他已经可以解决我们的很大一部分问题...
我将对他说几句话，以便更清楚地讨论什么。
快速通道一览
如今，Fastlane是一款产品，几乎可以完全自动化从开发完成到在App Store和Google Play中发布应用程序之间的所有操作。这不仅涉及下载文本，屏幕截图和应用程序本身，还包括证书管理，Beta测试，代码签名等等。
我们在Fastlane的“青春”和不稳定时期遇到了他。但是现在，它已成为许多移动应用程序开发团队中一个充满自信地工作和不可或缺的组成部分，它们面临着将产品交付给用户的巨大耗时问题。最有趣的是，它可以为主要组件编写自己的插件，并使用社区编写的插件。对于这样的特定产品，这是一个很好的解决方案，这（很重要）有助于避免在DevTools中产生“额外”技术。
这也激发了人们对Fastlane的创始人和主要开发人员被Google雇用的信心：现在，该组件不仅支持社区，还支持自身。
随着时间的推移，我们已经在应用程序的构建，签名，填充等系统中实现了Fastlane提供的大多数功能。他们对此感到非常高兴。当您一次编写一个可以在CI / CD系统中旋转的统一脚本时，为什么还要重新发明轮子，甚至保持其正确的形状？
自动化iOS版本
由于Google Play对开发人员更友好，因此只需几分钟即可发布Android应用程序：无需更新文本，视频和屏幕截图。因此，不需要自动化。但是在App Store中，问题非常明显：提交申请到Review花费了太多时间。因此，决定使用iOS启动自动化。
我们考虑过系统与App Store（甚至是原型）之间自动进行交互的系统的相似性，但是我们没有资源来完成和更新。同样，苹果公司也没有或多或少有足够的API。好吧，我们的自定义解决方案的棺材中最后钉钉子的是App Store及其机制的定期更新。总的来说，我们决定尝试Fastlane-然后是2015年的另一个版本。
第一步是编写一种机制，以将应用程序的翻译文本上载到所需的结构，作为我们常见的AIDA（自动交互式部署助手）内部系统的组成部分。该系统是一种枢纽，是Badoo中使用的所有系统，技术和组件之间的链接。它可以在以Golang和MySQL实现的自写队列系统上工作。维护和改进它主要是部门发布工程。我们在2013年的文章中更详细地讨论了此问题，此后发生了很多变化。我们保证再次谈论它-AIDA很酷！
在下一阶段，由Fastlane提供下载的文本，然后将其上传到App Store。之后，您必须转到App Store界面，手动选择所需的下载版本，然后发送应用程序进行验证（如果此时处理已完成）。
这将发布的准备时间从几个小时减少到了大约30分钟，其中只有一分半钟的时间可以完成一些操作！剩下的时间就是等待。等待处理结束。该机制在当时是一项突破，因为它几乎完全使我们免于准备发布AppStore的手动工作。我们为脚本创建了一个存储库，我们可以访问与发布直接相关的人员（项目经理，发布工程师）。
在这种模式下，我们生活了一段时间。但是在某种程度上，这种方案导致了许多“神圣知识”的积累，这些知识的所有者以及由此产生的事件的总体情况变成了一个人，这不好。特别是对于这个人：没有笔记本电脑，您甚至无法度假。
另外，这种机制周围有很多分散的基础架构组件，实际上彼此之间没有关联。
- 您必须去TeamCity进行全新构建，从那里下载IPA文件，然后通过应用程序管理器将其上传到App Store。
- 然后转到AIDA中带有翻译的界面，查看所有翻译是否已准备就绪，运行脚本，确保脚本正确运行（毕竟，Fastlane当时还是很潮湿）。
- App Store , Processing.
- Review.
每个应用程序都是如此。让我提醒您，当时我们只有八个。
下一步是将脚本传输到我们的AIDA，同时将所有步骤组合并自动化，直到发送应用程序为止：检查翻译的准备情况，从TeamCity收集数据，通知，日志记录以及21世纪的所有其他好处。与此同时，我们在构建阶段就开始将所有组装的版本加载到TestFlight中。
TestFlight是第三方应用程序，Apple曾经购买它来在几乎生产环境中（即具有推送通知等）由外部测试人员测试完成的应用程序。
AIDA做得好，就像AIDA！
所有这些都将所有内容的时间从半小时减少到了半分钟：在质量检查工程师团队批准发布该版本之前，IPA文件已通过处理。尽管如此，我们仍然必须去App Store，选择正确的版本并将其发送给Review。
此外，还绘制了一个简单的界面：我们都喜欢单击。
这样，一个接一个地按，Ctrl + C Ctrl + V ...
Android发布自动化
然后，出现了有关Android应用程序发布自动化的问题。尽管此过程要快得多，但是有必要手动做很多事情：
- 转到Google Play控制台，以确保先前版本已100％推出或冻结。
- 使用更新的文本和屏幕截图（如果有的话）创建发行版的新版本。
- 下载APK文件（Android软件包），下载Mapping文件。
- 转到HockeyApp（用于记录当时的崩溃），然后在其中上传APK文件和Mapping文件。
- 转到聊天并取消订阅发布状态。
每个应用程序都是如此。
是的，Google Play有自己的API。但是，如果我们已经使用Fastlane for iOS版本，那么为什么要包装，监视协议的更改，维护协议并不必要地生成实体呢？此外，它可以舒适地存在于我们的服务器上，以自己的汁液酿造，并可以进行一般更新。到那时，他还学会了充分发布Android应用程序。星星聚在一起！
首先，我们从任何地方切掉了所有旧的东西：单独的脚本，自动化草图，旧的API包装器-这些都是作为实验创建的，并没有特别的价值。此后，我们立即向AIDA添加了一个团队，该团队已经知道如何从TeamCity获取我们需要的东西，将我们需要的东西加载到HockeyApp中，发送警报，记录活动，并且通常它是该团队的成员。
Fastlane负责将APK和Mapping文件上传到Google Play。我必须说，走人迹罕至的路要容易得多：它以最少的努力就足够快地实施。
在实现自动化的某个阶段，从APK存档过渡到了AAB（Android应用程序捆绑包）。同样，我们很幸运，在紧追中很快就解决了所有问题，但是在这种过渡过程中增加了“娱乐性”。例如，我搞砸了HockeyApp，后者不知道如何在准备自动锯切时使用AAB档案。因此，为了舒适地继续使用它，有必要在AAB组装后拆解组装好的档案文件，从中获取映射文件，该文件会飞到HockeyApp，并且必须从AAB单独收集APK文件，然后再将其上传到同一个HockeyApp。听起来很有趣。同时，Google Play本身可以完美地分解AAB，从那里取出Mapping文件，然后将其插入到需要的位置。因此，我们摆脱了一步，增加了几步，但是并没有绕开它。
编写了一个界面（同样，类似于iOS），该界面能够下载新版本，前后检查版本，管理当前活动版本（例如，增加推出比例）。通过这种形式，我们将其交给了Android质量检查小组的发布小组成员，开始收集反馈，修复错误，完成逻辑（以及1.0版之后还会发生什么？）。
顺便说一句，在将来，自动化使我们有机会按计划自动将Beta版本的应用程序上载到Google Play，从而极大地加快了自动和回归测试的过程。
移动发布流程的统一
到Android版本自动化时，Fastlane终于了解了如何发送iOS应用程序的版本以供审核。并且我们对AIDA中的版本检查系统进行了一些改进。
是时候让QA工程师团队来发布iOS版本了。为此，我们决定绘制一个漂亮的表格，该表格可以完全满足iOS应用程序发布过程中出现的需求：可以根据预定义的参数在TeamCity中选择所需的版本，选择加载的文本选项，更新或不选择可选字段（例如，Promotional Text） ...
说到做到。千篇一律的小甜饼刀看起来非常漂亮，完全可以满足所有要求。此外，通过其实现，可以使用所有必需的参数一次选择所有必需的应用程序，从而最大限度地减少了与界面的交互。根据命令，AIDA将链接发送到构建日志，通过该链接，您可以跟踪发生的错误，确保一切正常，获取某种调试信息，例如下载的IPA文件的版本，发行版等。这就是iOS发行版的精美程度。并转移到iOS质量检查小组。
好吧，很可爱吗？
我们非常喜欢这个想法，因此我们决定在Android版本中也这样做。鉴于我们有一个完全用React Native编写的应用程序，并且该应用程序的质量检查团队负责iOS和Android版本。
Android质量检查团队已经使用的界面以类似的形式与更改集成在一起，该流程适应了新的现实-一切都尽可能与iOS团队的流程接近。这激励人们最终为两个平台最终草绘或多或少的最终版本的文档（在不断变化的过程中，我们绝对不希望这样做），并且还使发布过程与历史上发展而导致非标准情况下不必要的手势的所有人为限制脱钩。发布工程师团队的行为。
输出量
以这种无聊的方式，在大约五年的时间里（从我们开始开发移动导航的那一刻到今天），我们使构建，测试和发布流程完全自动化，使它们尽可能高效，并将发布的职责移交给了质量检查小组成员，他们接受了决定应用程序准备程度。
除了明显的优势之外，我们还完全摆脱了分散的脚本，与一个人捆绑在一起的各种“秘密知识”，将一个新组件集成到了我们的生态系统中，并由一小组发布工程师提供支持。
很好的是，现在可以自动执行大多数常规操作，工程师可以在需要时编写代码，并且第三方开发人员可以支持任何代码，而不必浪费宝贵的时间来研究复杂的接口。要弄清楚“我应该在哪里打勾？”之类的东西，尤其困难，当时钟是午夜时分，没有人在办公室，并且需要在此处和现在上载修补程序。
5年。为什么这么久？首先，移动发布离我们的小型团队唯一负责的领域很远。其次，当然，开发新的开源项目Fastlane需要花费时间。我们的发布系统也随之发展。
我们在这方面已经走了很长一段路。也许这不是最有效的方法，也许可以预见并绕过一些耙子。但这是事实。开始时，没有类似的文章-我们以自己的方式。如果您现在正面临类似的任务，并且本文对您有所帮助，我将非常高兴。但是，即使您还没有从根本上学到新信息，我也希望至少有空阅读是很有趣的。并且，也许与您的经验进行比较。如果您对此话题有任何意见，欢迎发表评论！