CI失败的5大原因

没有有效的持续集成流程,敏捷软件开发就无法完美。 CI是一个不断分析,构建,测试和部署软件的过程。 持续集成在发布产品之前,会检查代码的内部质量并测试产品的业务逻辑。

理想情况下,当构建中断时,我们不应允许将软件部署到生产环境。 但是,持续集成并不总是适用于每个敏捷团队。 一些敏捷团队非常重视CI实践,一些团队是为了敏捷而这样做,一些团队完全忽略了它,有些还没有设置CI服务器。

团队中可能会忽略CI实践的各种原因。 企业具有不同的优先级,产品负责人并不总是了解内部质量,测试流程和整洁产品的重要性。 技术经理无法花时间实施CI实践或修复损坏的CI。 生产和技术管理部门无法理解彼此的优先级,最终他们将损坏的版本部署到最终用户。 生产人员很高兴–他们以残破的CI交付了商业价值。

这种方法可以使您暂时满意,但这是非常危险的。 以后可能会将严重的错误投入生产,这可能严重影响业务。 影响的严重性是无法预测的,从金钱损失到声誉损失,或者在极端情况下,甚至是企业的完全损失。

但是,即使生产和技术团队同意花费时间和金钱来实施或解决CI问题,有些团队也无法成功。 让我们讨论CI失败的五个主要原因以及克服这些问题的潜在解决方案。

如果您的自动测试依赖于在单个无头浏览器上运行的Selenium测试,则您的测试不稳定,不可靠并且会不断发布错误就不足为奇了。

不要听那些顽固地坚持为自动化测试编码和维护整个内部基础结构的开发人员,这种趋势已经过时且危险。

趋势是在云端。 就像公司用AWS替换了旧的裸机服务器一样,他们也用下一代的多合一平台(例如Endtest)替换了旧的内部测试。

使用Endtest,您可以在跨浏览器的基础设施和移动设备实验室上创建和运行自动测试。 您无需编写任何代码即可完成所有这些操作,这意味着即使您的产品负责人也可以快速编写一些测试。

福特,万事达卡,荷航,卡塔尔航空,戴尔,Under Armour只是依靠Endtest的一些知名公司

还有其他选择,您可以编写自己的测试,然后使用BrowserStackSauceLabs运行它们,但它更昂贵,并且不会获得相同的稳定性。

市场上有各种持续集成工具。 CI服务器解决方案可以是自托管的,也可以在云上。 您可以在此处获得带有建议的CI服务器的完整列表。

Jenkins是流行的CI服务器之一,人们倾向于盲目使用它。 我们必须调整项目以与Jenkins合作,并且团队必须在Jenkins提供的服务中妥协。 现在,这种情况已经改变,市场上有各种有前途的CI服务。 考虑到市场上各种CI服务器,选择适合我们项目需求的CI服务器具有挑战性。

设置CI服务器的过程需要时间和金钱。 如果您在没有进行任何研究的情况下选择CI服务器,并且对团队而言效果不佳,那么您为获得CI服务器所做的所有努力都是徒劳的。 管理层经常犯的一个错误是,为所有平台选择通用的CI服务器或服务并不能很好地工作。 假设您的应用程序有一个网站,iOS应用程序和Android应用程序; 寻找通用解决方案可能效果不佳。 我们在选择CI服务器时必须非常小心。

  • 仔细研究市场并评估试点项目的选择。 Slant已经评估了主要CI服务器的优点和缺点。
  • 在评估CI服务器时,查找诸如管线支持,管线作为代码,Docker容器支持,平台支持,易用性,可用性等功能。
  • 不要试图为所有平台找到通用的解决方案以降低成本。 每个平台都有不同的技术要求和挑战。
  • 与团队讨论并询问过去的经验,这样我们就无需再次培训工程师。

在敏捷团队中工作的工程师应该具有出色的编码技能,但是交付有效的软件不仅仅是编写和测试代码。 它还涉及设置适当的环境,以确保我们可以轻松交付它。 这需要构建自动化的强大命令行和脚本技能,以及对构建自动化工具和依赖项/程序包管理工具的全面了解。

最近,公司已将基础架构迁移到云中,因此需要学习DevOps技能,即AWS,Azure和Heroku等云服务; bash,Ansible和Chef等配置工具; 以及Docker和Kubernetes等容器服务。 最重要的是了解一种脚本语言,即Bash,Ruby或Python。

这并不意味着您应该学习世界上的所有内容,而是应该学习平台的所有内容。 假设一名工程师正在从事iOS应用程序开发。 工程师应该了解Cocoapods,Carthage和Swift Package Manager之类的工具来进行依赖项管理。

此外,构建自动化工具(如Fastlane,Rake和Make)对Apple的本地命令行工具具有强大的命令。 工程师应了解与相关平台有关的最新工具。

市场上有不同类型的工程师。 他们中的一些人擅长编写本地语言代码(例如Java,Objective-C和Swift),并且对DevOps和构建自动化工具有深入的了解。 一些工程师只能在IDE中编写代码(例如Eclipse,IntelliJ和Xcode),而这些代码无法运行来自终端的命令。 一些工程师擅长于构建自动化工具,但是不擅长编写本地语言代码。

CI业余爱好者是那些不能脱离IDE并且不能使用命令行(脚本)工具的人。 他们比命令行或脚本更喜欢GUI工具而不是所有工具。 但是,CI服务器没有与之交互的GUI界面,因此所有内容都必须编写脚本。

如果团队中有CI业余工程师,则CI实践永远不会成功。 CI业余开发人员最终可能会写出质量低下的构建自动化脚本,这些脚本会一直中断。 团队最终将时间花在学习,改善构建自动化以及在CI服务器之间切换上,而不是构建对业务有用的功能。

  • 雇用具有持续集成和DevOps基础知识的工程师。
  • 培训CI业余工程师。 一个好主意是将他们发送到外部培训或与内部CI专家一起培训。
  • 聘请短期合同专家以建立CI流程并共享知识。

大多数CI服务器允许用户从Web界面更改构建配置。 这种方法使工程师可以轻松创建和编辑CI版本。 但是,经常更改构建配置会导致很多问题,例如禁用重要的构建步骤。 此外,每个人都有访问构建机器的权限,这可能会引起混淆,即谁做了什么以及何时做。 如果工程师不了解构建设置更改,那么花很长时间才能确定构建失败。 CI服务器计算机上的频繁更改可能导致团队内部出现问题和混乱。

  • 通过将配置文件,bash脚本或类似文件放在源代码中,可以控制构建配置。
  • 避免在CI服务器上进行手动配置。
  • 将CI服务器计算机的访问权限限制为只有少数人,并赋予他们管理服务器的责任。
  • 不允许用户修改特定的构建步骤。

团队中的开发人员经常在源代码控制系统中检入代码,这会触发CI服务器上的构建。 这意味着CI服务器计算机将连续运行作业,其中可能涉及繁重的任务,例如从远程服务器下载依赖项,备份数据库,运行Docker容器等。为了有效地执行这些任务,CI服务器必须快速,可靠,并连接到网络。 使用质量低下的服务器会浪费所有人的时间,因为构建时间太长,无法完成,从而导致测试结果断断续续,并使工程师感到沮丧。

  • 获得快速可靠的服务器以进行持续集成; 避免使用便宜的服务器。
  • 切勿将CI服务器计算机留在WiFi上。
  • 切勿在CI服务器计算机上安装不必要的软件。
  • 通过分配特定作业来智能共享CI服务器计算机。
  • 切勿手动安装任何软件。
  • 避免授予GUI对计算机的访问权限。 SSH访问应该足够。
  • 与团队一起建立CI实践,并将其严格应用于团队中。
  • 对项目经理进行CI实践方面的培训。

在敏捷团队中实施持续集成实践是一项挑战,但是遵循一些严格的规则并避免常见的错误可以使CI流程更加有效。 您对CI服务器有什么经验? 您认为您的CI实践是否运作良好? 在下面的评论中称呼!