为什么需要在2018年将移动DevOps保留在内部

---

最初发布在XCBlog网站上 ，请阅读原始博客以获得更好的图形！

信不信由你，建立和管理DevOps工具是一项令人费解的活动。 对于Web和移动应用程序开发都是如此。 它需要对服务器和网络技术，具有复杂脚本的自动化，云技术和24 x 7监控支持的深刻理解。 这使许多企业家，项目或计划经理感到头疼，以至于许多人选择将此流程完全外包给其他公司或使用基于云的提供商来处理。 DevOps活动成为Web和移动应用程序开发中的大人物。 应用程序开发人员不具备处理DevOps工具的技能，并且拥有专门的DevOps团队对于企业而言过于昂贵，因为它不会直接产生业务收入。 在这篇文章中，我们将看到为什么您急需在2018年考虑内部移动DevOps。是的，在2018年，因为您可能会受到新年开始时Apple购买的BuddyBuild的影响。 希望在本文结尾处，您将看到使用内部移动DevOps的一些好处

那么DevOps到底是什么呢？ 那是一百万美元的问题，简称为“没人知道”，也就是说，DevOps在任何地方都没有具体定义。 关于DevOps的说法有很多。 有人说这是一套工具，这是新的开发方法，是管理CI / CD的团队，是职务或职位，但没有一个是正确的。 我对DevOps的理解非常简单，无论是接受还是抛出，但是我对DevOps的定义是

“您为加快免费软件发布的速度而采取的一切操守都被视为DevOps”

DevOps庞大，有数百万篇博客文章，数千篇白皮书，数百本书籍，并且有新颖的作品来解释DevOps的概念。 OMG有一个名为“凤凰计划：有关IT，DevOps和帮助您的业务成功的小说”的小说，这个名字很长，但是它包含了DevOps的细节。 我强烈建议所有想要了解DevOps的人员使用此工具。无需遵循针对DevOps实践的预定义流程，技术或工具，但是，DevOps在小说中提到了三个应该遵循的支柱，即系统思考，放大反馈循环，持续实验和学习。

开发网站和手机应用程序是两项完全不同的活动。 它们在技术，基础架构，流程，工具和技能方面各不相同，因此很难将两者融合在一起。 结果，用于Web和移动设备的DevOps实践或工具也有所不同。 管理Web和DevOps的技术和过程可以相同，但是工具上存在一些主要差异。 我们将在这里介绍5个基本差异

浏览器与设备

Web应用程序必须支持各种桌面/移动操作系统和浏览器，而移动应用程序必须支持具有多种变体的特定于平台的移动操作系统。 移动应用程序的各种环境目标。 移动必须支持多种变体。 例如，iOS在iPhone，iPhone +和iPad变体上具有各种iOS版本。

App Store与托管服务器

移动应用一旦发布，便托管在AppStore或Play商店中，但是Web应用需要在数据中心或云中托管服务器。 如今，大多数Web应用程序都托管在AWS，Azure或类似的云中。 Web应用程序始终需要操作和监视，但是移动应用程序不需要监视托管，因为AppStore或PlayStore将负责托管。

拉与推部署

Web应用程序始终具有推送部署，这意味着可以按需部署新版本的网站，并且用户无法选择接受或拒绝更新。 但是，移动应用程序具有拉式部署，除非强制执行，否则用户可以选择是否更新到新版本。 如果发布移动应用程序，则不会回滚。 另一件事是，在移动世界中没有持续的部署，因为苹果或谷歌必须在发布新版本的应用程序之前等待几天才能批准应用程序。 移动应用程序的发布比Web应用程序的风险更大。

技术领域

用于开发Web和移动应用程序的工具和技术存在主要差异。 用于移动原生开发的编程语言是Swift，iOS和Java的Objective-C或Android的Kotlin。 还有其他一些混合框架可用于一起开发Web和移动。 但是，可以使用数百万种编程语言（例如Java，Ruby，PHP，Python，JavaScript等）来开发Web应用程序。平台之间的持续集成工具也相差很大。 例如，詹金斯（Jenkins）是一种非常流行的工具，可以将Web应用程序部署到任何地方，但是对于移动持续集成而言，它并不总是一个好的选择。

后端服务

不幸的是，不可能将所有必需的数据放入应用程序中，因此Web和移动应用程序都依赖某种向其提供数据的后端服务或API。 这些服务可能设计也可能不设计为同时服务于Web和移动应用程序，因此找出后端服务中的任何更改可能会影响到移动应用程序或Web应用程序或两者都必不可少。 移动应用程序也需要单独注意。

在大多数公司中，移动DevOps活动要么由云连续集成服务处理，要么由不同公司或同一公司内的部门处理。 让我们集中讨论那些活动是什么，以及为什么总是将它们弄混（不确定这是一个英语单词）还是外包。 除了正常的开发活动之外，我们可能还需要进行数百万次DevOps活动，但我们将涵盖主要的活动。

• 设置和管理用于持续集成的构建服务器
• 使用构建工具自动化构建
• 使用正确的配置文件，配置和证书来管理脚本代码签名活动（适用于iOS）
• 使用自动构建阶段设置持续交付管道
• 确保快速明确的构建执行
• 使用各种工具监视应用程序

这些活动耗时，艰巨，除了应用程序开发技能外，还需要特殊技能。 重要的是这些活动通常被视为辅助活动。 企业认为他们没有通过投资这些活动来赚钱，他们发现很难买到做这些事情。

有一些原因导致移动DevOps活动始终由基于云的提供商或其他团队来处理。

• 应用程序开发人员没有管理团队内部Mobile DevOps活动的技能。
• 应用程序开发人员编写了业余脚本，这些脚本一直在破坏构建，并且团队花费大量时间来解决CI问题。
• 应用程序开发人员对Mobile DevOps活动感兴趣，但是企业无法购买到进行这些活动。
• 缺乏在内部设置Mobile DevOps实践所需的硬件基础架构
• 企业希望专注于构建移动应用程序，而不是花钱在辅助活动上。

尽管公司选择基于云的CI解决方案来管理大多数DevOps任务。 基于云的CI服务器也有一些优点和缺点。

• 简易设定
• 更少的脚本编写，因为基于云的CI服务具有默认配置
• 灵活且可扩展。 如果我们支付更多，可能会并行构建
• 处理复杂的代码签名活动
• 无需硬件即可设置构建服务器
• 简化成本并提高开发资源利用率
• 简单易学

• 基于云的CI服务需要大量资金才能运行您的构建。 他们不便宜。
• 经常性费用。 您将每月或每年准备好巨额账单。
• 在大多数情况下，您无法通过代码控制构建设置。
• 您不能在真实设备上运行测试。
• 基于云的VM太慢了，以至于运行UI测试是噩梦
• 您已将代码，证书和所有内容授予第三方CI服务的许可。
• 您无法立即从Apple或Google获得更新。 您必须等待他们更新VM以支持新工具
• 很少，几乎没有访问运行您的构建的VM的权限
• 由于每次构建后VM都被杀死，因此难以存储构建日志
• 想象一下，您的基于云的CI提供程序在重要的发布日就崩溃了。
• 想象一下您的基于云的提供商被黑了。 考虑一下您的源代码和证书。

在这里，我们可以简单地说，隐蔽基于云的优点是自托管的缺点，反之亦然，但是我们将以不同的方式来说明

• 无经常性费用。 如果我们有硬件，我们可以节省很多钱
• 完全控制构建机器。 我们可以根据项目需求即时管理机器。
• 根据需要添加或删除软件。 我们可以灵活地在Apple或Google（甚至Beta版）发布版本后立即安装工具
• 无需在组织外部共享您的代码或发行证书。 您可以实现完全的隐私
• 将真实设备的负载连接到服务器以运行测试。 建立自己的设备云
• 在指定的期限内存储构建报告。

• 管理费用
• 开发人员的大量学习曲线，以便学习DevOps工具
• 需要硬件来设置构建服务器，而这可能会很昂贵
• 用于管理服务器的专用/已分配资源。

现在，我们已经看到了自托管以及基于云的CI都可用于管理Mobile DevOps活动的利弊。 现在该做出决定了，该选择什么是自托管的还是基于云的？ 简短的答案是“取决于”，我讨厌这个答案。 我通常会从会议发言人那里听到这个棘手问题的答案。 每当有人回答说“这取决于”时，请记住这一点，这意味着该家伙完全感到困惑，不知道真正的答案。 无论如何，但是我个人的建议是，如果您有足够的DevOps热情和技巧，那么您绝对应该选择自托管的解决方案。 这是主要原因

存钱

您可能想知道我们如何通过内部DevOps节省资金？ 刚开始时很难，但是一旦团队掌握了DevOps工具，从长远来看它将便宜很多。 无论如何，构建移动应用程序的公司必须购买用于测试目的的设备，而购买另一件硬件也就不算什么了。 我认为它比每月支付巨额费用便宜得多。 我不讨论会计细节，但是如果您正在考虑长期项目和长期利益，则必须使用自托管解决方案。

省时间

云中的构建速度非常慢。 它需要引导新的VM，安装依赖项，软件包，准备钥匙串，导入证书，签出源代码等。我们必须为每个构建重复相同的步骤。 每次构建都会增加几分钟。 借助具有良好互联网速度的自托管解决方案，我们每天可以节省许多时间。 云CI给出的测试结果不一致，尤其是对于UI测试。 您最终将花费更多的时间来调查不是真正问题的问题。

完全掌控

借助自托管的DevOps解决方案，您可以完全灵活地安装任何软件或软件包。 您可以对整个构建和基础结构进行编码，并使用配置管理工具在任何计算机上的任何位置使用它。 通过自托管解决方案，我们可以从最新的Beta版工具和真实设备测试中受益。 我们可以尝试在自己的服务器上尝试新事物。 您应该能够定义和管理构建配置，只要出现问题，就可以了结。 我们可以轻松修复它或重建整个服务器。 在云的情况下，如果出现问题，那么您将花费数天的时间来修复可能导致云提供商出现问题的问题。 您可能需要他们的支持团队来帮助您解决构建问题。 为什么要去找别人解决正在构建的软件问题？ 你应该创造自己的命运。

隐私权与安全性

隐私和安全必须处理任何组织的优先事项。 如果您是大型公司，并希望将您的敏感数据移交给外包公司或基于云的提供商。 并非总是如此，但始终存在潜在的风险。 您能想象一下您的基于云的启动提供商遭到黑客入侵的情况吗？ 谁将对此损失负责？ 你明白我的意思吧？ 让我们继续前进。

从课程中学习，例如BuddyBuild

如果您在一开始就听到有关苹果购买BuddyBuild的消息，这可能已经影响了buddyBuild的许多Android用户。 现在，他们将在2个月内取消对Android的支持。 结果，许多Android团队可能正在寻找另一种选择XYZ。 如果XYZ明天卖了怎么办，您应该在云提供商之间跳来跳去。 相反，要聪明，建立自己的政权。

您可以用来在移动团队中成功实施内部移动DevOps的一些技巧。

• 对于其他DevOps工具，自托管CI解决方案有多种选择。 确保选择适合您团队的合适人选。 使用Apple或Google的本机CI工具，而不是第三方的。
• 向您的团队询问他们过去的经验，并相应地选择工具，以减少培训工程师的麻烦。
• 雇用具有持续集成和DevOps基础知识的工程师。 如今，仅凭开发应用程序的经验是不够的。
• 聘请短期合同专家以建立CI流程并共享知识。
• 通过将配置文件，bash脚本或类似文件放在源代码中，可以控制构建配置。 基础架构即代码是成功进行配置管理的关键。 避免在CI服务器上进行手动配置。
• 获得快速可靠的服务器以进行持续集成； 避免使用便宜的服务器。 使用快速互联网（ethernet）加快构建速度。
• 提升管理层中DevOps做法的重要性，并向他们解释业务价值

2018年开始的消息可能会影响BuddyBuild的许多Android用户，这表明公司正在考虑其Mobile DevOps策略。 拥有自助内部解决方案始终比第三方服务更适合移动应用程序开发。 您可能一开始就很难学习DevOps工具，但是它将带来一些长期的好处。 您如何看待自托管解决方案？ 在下面的评论中分享您的想法或对我发誓。

像XCBlog的 XCTEQ 发布的帖子一样 ？ 您可能还喜欢我们的一些服务，例如访客博客或Mobile DevOps（CI / CD）或测试自动化。 在 Github 上 搜索我们的 服务 ，开源项目， 或者在 Twitter ， Facebook ， Youtube 和 LinkedIn 上关注我们 。 下载我们的 XCBlog iOS应用程序以离线阅读博客。

X CTEQ 是一家专门从事基于Mobile DevOps，CI / CD，Mobile，AI / ML的测试自动化Checkout XCTEQ产品和服务的公司， 网址 为 http://www.xcteq.co.uk 或写信给我们[e-mail]。英国..