专栏名称: 分布式实验室
最专业的Docker文章,最权威的Docker新闻。关注容器生态圈的发展。
目录
相关文章推荐
51好读  ›  专栏  ›  分布式实验室

CI 失败的五大原因

分布式实验室  · 公众号  · 后端  · 2017-06-11 08:02

正文

敏捷软件开发必须辅以有效的持续集成(CI)。CI就是持续进行分析、构建、测试和部署的流程。在发布到生产系统之前,CI会检查代码质量和测试产品的业务逻辑。


理想情况下,当构建失败时,我们是不能允许软件继续发布到生产上。但是,持续集成的理念并未贯彻到每一个敏捷团队。有些团队非常严肃地对待CI实践,有些只是为了敏捷而做,有些则完全忽略CI流程,甚至有的连CI服务器都没有搭建。


有很多种原因导致团队忽视CI流程。工作有不同的优先级,产品经理不理解代码质量,测试流程和完整构建的重要性。技术经理无法分配足够的时间实施CI或者修正出问题的CI。产品和技术管理层互相不理解各自的优先级以至于最后部署的是构建失败的产品。


这个方法短期看没什么问题,但其实非常危险。可能会导致产品有严重的缺陷,从而影响业务运作。这种影响是不可预测的,可能是金钱的损失,也可能是企业声誉,最极端的可能导致整个业务完全流失。


然而,即使产品经理和技术团队愿意投入时间和金钱来实施CI和修正CI问题。一些团队还是从未成功。我们在这里讨论一下CI失败的5大原因和克服这些困难的推荐解决方案。


1. 错误地选择CI服务器


市场上有很多种持续集成工具。CI服务器可以在云端也可以在本地。这里可以推荐一堆CI服务器(https://www.slant.co/topics/799/~continuous-integration-tools)。


Jenkins是其中之一,但过去人们都盲目地使用它。为了适应Jenkins,我们时常不得不更改项目妥协。现在,情况有所改变,市场上出现了多种不错的CI服务器。面对如此众多的产品,选择适合自己所需的的确是一项挑战。


搭建CI服务器需要耗费大量的时间和金钱。如果没有提前研究就贸然决定,那么前期的投入都付之东流。管理层经常犯的一个错误就是选择一款通用型CI服务器或者适用于所有平台的服务。设想一下,你的应用包含Web网站、IOS app、Android app,用一个通用CI并不是一个很好的办法。我们必须非常小心来选择CI服务器。


推荐解决方案


  • 仔细研究市场并通过实验权衡各种选项。Slant上已经对主流的各种CI产品(https://www.slant.co/topics/799/~continuous-integration-tools)有优劣评估。

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

  • 不要为了试图省钱采用一款通用的适应所有平台的CI产品,每一个平台都有不同的技术需求和挑战。

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



2. 业余工程师


在敏捷团队的每一位工程师都有很强的编程能力。但仅仅是是写代码和测试代码是不够的,还需要搭建环境的能力,运行命令行和编写脚本的技能,还要具有对各种构建工具和软件包管理工具的扎实的知识。


最近,很多公司都开始讲IT架构迁移上云,所以还需要 Devops 技能。例如,AWS、AZure、Heroku,各种配置工具例如:bash、Ansible和 Chef,还有容器Docker and Kubernetes。最重要的是要具备至少一种脚本编程能力,比如Bash、Ruby或者Python。


这当然并不意味者你需要学所有的东西,但你需要了解平台上的所有东西。假设一位从事IOS开发的工程师,他就需要了解各种相关的工具例如:Cocoapods、Carthage和Swift Package Manager。


还有用于构建的工具,例如在APPLE 命令行工具之上的Fastlane、Rake和Make。


术业有专攻,有些工程师擅长基本编程语言,比如 Java、Objective-C和Swift,并且对DevOps相关的各种工具相当熟悉。 有些工程师则习惯于使用IDE环境开发(比如Eclipse、IntelliJ和Xcode),他们不太熟悉使用终端敲入命令。还有些工程师擅长构建工具但写程序代码则弱一些。


所谓业余工程师是指那些只会在IDE环境下编程,不会使用命令行和脚本工具的人,他们只喜欢使用GUI去做事而抗拒使用命令行或脚本。但是,CI服务器并没有GUI,所有的事情都只能用脚本来完成。


如果你的团队有这类人,那CI就永远不可能成功,他们可能会开发一些质量低劣的自动化脚本,然后大家的时间都花在差错,该机和CI服务器切换上,而不是真正构建对业务有意义的功能。


推荐解决方案


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

  • 培训工程师,最好的办法是送他们去外面培训或者请内部有经验的CI专家培训。

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


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


许多CI服务器允许用户通过Web界面去更改CI服务器配置。这个方法对工程师而言的确比较方便。但是经常更改CI配置也会产生很多问题,比如把一些很重要的步骤错误地忽略掉。而且,如果每个人都有权限在上面更改的话,最后就搞不清楚谁,什么时间做了什么更改。当查错的时候,都需要花费大量的时间。经常性地更改CI服务器会导致很多问题。


推荐解决方案


  • 把配置文件,脚本和其他相关文件都放到代码库集中管理。

  • 避免手工更改CI 服务器的配置。

  • 控制访问CI 服务器的权限。

  • 不允许用户更改一些特定的构建步骤。


4. CI服务器性能差

在开发过程中,程序员需要经常更新代码,这会不停地在CI服务器上触发重构流程。这意味着CI服务器需要不断地运行大量作业。例如从远端服务器下载,备份数据库,运行Docker容器等等,所以CI服务器必须快速,可靠,网络稳定。低配的CI服务器会影响整个构建流程,导致时间延长,测试时断时续,从而浪费大量的时间。


推荐解决方案


  • 采用高配服务器。

  • 不要在CI服务器上安装不必要的软件。

  • 不要把CI服务器挂在Wifi上。

  • 科学地调度在CI服务器上跑的作业。

  • 不要手工安装软件。

  • 避免使用GUI连接 CI 服务器,使用SSH足够了。


5. 缺乏管理

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


推荐解决方案


  • 建立CI流程并严格执行。

  • 培训项目经理并用于CI实施。


总结


在敏捷团队中实施CI是非常有挑战的,但是遵循严格的规则并避免一些常见错误可以有效地实施CI流程。你的经验如何?你觉得CI流程有效吗?欢迎大家评论!


原文链接:https://dzone.com/articles/top-5-reasons-for-continuous-integration-failure


Docker精品训练营


随着Docker技术被越来越多的人所认可,其应用的范围也越来越广泛。本次培训我们理论结合实践,从Docker应该场景、持续部署与交付、如何提升测试效率、存储、网络、监控、安全等角度进行。点击识别下方二维码加微信好友了解具体培训内容。


点击阅读原文链接即可报名。