• CI 经常失败?可能是这 5 大原因…


    本文翻译自文章 Top 5 Reasons for CI Failure,主要介绍了 CI 失败的五个原因,包括 CI 服务的错误选择、CI 工程师的不专业性、随意更改CI服务器配置、CI服务器性能差、缺乏管理等。由 flow.ci-Meng 编译整理。


    敏捷开发不可能完美,必须有 CI 实践的助力。CI 是持续进行分析、构建、测试和部署的自动化流程,在正式发布到生产环境之前,CI 会检查代码质量和测试产品的业务逻辑。

    理想情况下,在构建失败时不能让项目或软件部署到生产环境。但是,持续集成的理念并不被每一个敏捷团队适用。一些敏捷团队非常重视 CI 实践,有的只是为了做敏捷而做,而有些团队完全忽视CI,更有甚者从未配置过 CI 服务器。

    在团队中导致CI实践被忽视有各种原因。 我们都知道企业具有不同的优先级,产品经理可能并不理解内部质量、测试流程和完整构建的重要性。 技术经理不能分配时间来实施 CI 实践或修复出现问题的 CI 系统。 产品和技术经理无法了解彼此的优先级,导致部署了一个失败的产品交付给终端用户,并传递了一个非常糟糕的商业价值。

    这种方法看似没有问题,但其实非常危险。可能不久的将来会导致严重的产品缺陷,从而严重影响业务运作。这种影响是不可预知的,一开始是金钱的损失,直至影响到企业声誉,最后可能直接导致整个业务完全失败。

    然而,即使产品经理和技术团队同意投入更多的时间和金钱实施或修复 CI 问题,一些团队仍未成功。 这篇文章我们讨论了 CI 失败的五大原因,并提供一些潜在解决方案,希望能够帮助你。

    1. CI 服务的错误选择

    市场上有各种持续集成工具,CI 服务器解决方案可以是本地搭建也可以云端托管。这里列出了一堆的CI服务器解决方案

    Jenkins 是目前流行的 CI 服务器之一,大家都倾向于盲目使用它。为了使用 Jenkins 的服务,我们不得不调整项目。现在,市场上出现了一些不错的CI服务(国内如 flow.ci),选择适合自己适合需求的CI服务确实是一个挑战。

    推荐解决方案:

    • 仔细调研市场并通过实验权衡各种需求,Slant上已经对主流的各种CI产品进行了很详细的优劣评估,可参考一下;

    • 关注特性,例如管道支持,容器支持,平台支持,易用型,可用性等等;

    • 不要为了节省开支而选择一款通用的适应所有平台的CI产品,每个平台都有不同的技术需求和挑战;

    • 和团队讨论并借鉴过去的经验。

    2. 业余的 CI 工程师

    敏捷团队的工程师应该具有出色的编码能力,但仅仅写代码和测试代码是不够的,还涉及搭建配置环境的能力,运行命令行和编写脚本的技能,还要有对自动化构建工具和依赖/包管理工具的知识储备。

    最近,很多公司开始把基础设施​​转移到云端,所以还需要学习DevOps的技能,比如AWS,Azure 和 Heroku 等云服务。配置工具,如bash,Ansible和Chef;以及 Docker 和 Kubernetes 等容器服务。最重要的是掌握至少一种脚本语言,即Bash,Ruby或Python。

    这并不意味着你应该学习世界上的所有东西,但你需要了解平台上的东西。假设一名 iOS 开发工程师,可能需要知道Cocoapods,Carthage 和 Swift 等依赖管理工具。

    还有用于构建的自动化工具,如在 APPLE 命令行工具之上的Fastlane,Rake和Make,并关注最新技术发展。

    每个工程师都会有擅长的东西,有的擅长编写基本编程代码(即Java,Objective-C和Swift),并对 DevOps 相关的构建自动化工具非常熟悉。有的工程师习惯于使用IDE环境开发(比如Eclipse、IntelliJ和Xcode),有些工程师擅长构建工具但写程序代码则弱一些。

    这里说的CI业余工程师是那些无法脱离IDE,不会使用命令行和脚本工具的人。他们只喜欢GUI工具,拒绝使用命令行或脚本。但是,CI服务器并没有GUI界面,所有的流程必须通过脚本完成。

    如果你的团队有这类人,那CI实践永远不会成功。 他们可能写出一些低质量的自动化脚本,大家的时间都浪费在改进构建自动化以及CI服务器之间的切换上,而不是真正构建对业务有用的功能。

    推荐解决方案:

    • 招聘具有CI和DevOps基础知识的工程师;

    • 培养CI业余工程师,最好的办法是去外部培训或者请内部有经验的CI专家培训;

    • 短期招聘一些CI专家来建立CI流程和分享经验。

    3. 随意更改CI服务器配置

    大多数的CI服务器允许用户通过 Web 界面更改构建的配置。 这种方法使工程师轻松创建和编辑 CI 工作流。 但是经常更改构建配置可能会产生很多问题,例如忽略的一些重要的构建步骤。 还有,每个人都有访问构建机器的权限,这可能会导致混乱, 搞不清楚谁在什么时间做了什么更改。当互相不知道更改配置的内容,可能需要花费很长时间才能定位到构建失败的原因。频繁更改 CI服务器可能会导致团队内的混乱。

    推荐解决方案:

    • 配置文件,bash脚本或其他相关的文件放在代码库中集中管理;
    • 避免手动更改CI服务器上;
    • 控制CI服务器的访问权限,并由专人负责管理;
    • 不允许用户修改特定的构建步骤;

    4. CI服务器性能差

    在项目开发过程中,开发人员经常需要更新代码,这会触发CI服务器上的构建流程。 这意味着CI服务器需要持续运行大量任务,例如从远程服务器下载相关文件,备份数据库,运行Docker容器等,因此CI服务器必须快速可靠 ,并且稳定。 性能差的 CI 服务器不但浪费大家的构建时间,导致测试结果断断续续,也会影响让工程师们士气沮丧。

    推荐解决方案:

    • 选择更好更高配的服务器;
    • 不要把CI服务器挂在Wifi上;
    • 不要在CI服务器上安装不必要的软件;
    • 科学调度CI服务器资源;
    • 不要手动安装任何软件;
    • 避免使用GUI访问机器,使用 SSH 访问即可。

    5. 缺乏管理

    项目管理在整个CI实施中起着关键作用,必须对整个构建流程设定严格的指引,同时对任何不遵守指引的行为零容忍。在任何情况下都不能发布CI流程中断的软件。任何构建中断都要被视为紧急事件并以最高优先级进行修复。很多技术经理可以做到这一点,但一些没有CI经验的管理人员可能会命令继续开发而不顾代码质量。在这样的管理下,CI实施不可能成功。

    推荐解决方案:

    • 建立团队的CI流程并严格执行;
    • 培训项目经理并用于CI实施。

    结语

    在敏捷团队中实施CI是非常有挑战的,但遵循一些严格的规则并避免常见错误更有效地实施CI流程。你在CI实践中有什么样的经验?你觉得CI流程有效吗?欢迎分享你的观点!


    flow.ci ,融入了 workflow 机制的持续集成(CI)服务,也可以理解为自动化流程平台,除了集成代码、编译、测试之外,还可以集成常用的工具、灵活自定义流程。本文由 flow.ci-Meng 翻译整理,想阅读更多技术文章,请访问 flow.ci 官方技术博客

  • 相关阅读:
    HDU 1394 Minimum Inversion Number
    LA 3938 动态最大连续和(线段树)
    HDU 1754 I Hate It(线段树)
    HDU 1166 敌兵布阵(线段树 or 二叉索引树)
    《乞力马扎罗的雪》读书笔记
    LA 3266 田忌赛马
    UVa 11235 频繁出现的数值
    《月亮与六便士》读书笔记
    LA 3135 阿格斯(优先队列)
    LA 3027 合作网络
  • 原文地址:https://www.cnblogs.com/fir-im/p/6879837.html
Copyright © 2020-2023  润新知