如何加速持续集成与交付流水线并实现快速开发?

日期:2016-9-29作者:Valerie Silverthorne翻译:杨华军来源:TechTarget中国 英文

【TechTarget中国原创】

Abraham Marin Perez是一位独立的Java开发者以及演讲家。他在旧金山举行的2016年JavaOne大会上发表了讲话,内容涉及如何保持持续集成和持续交付(CI/CD),以及尽可能实现流水化。

根据你的经验,公司对自己的CI/CD流水线失去控制是不是很常见?有没有办法从一开始就设立好这条流水线来避免问题发生?

Abraham Marin Perez:在某种程度上来说,是的。他们不会称之为“失去控制”,不过我认为,尽管有一些真正富有创新精神的公司拥有一些非常复杂的CI/CD流水线,大多数公司仍然还处在努力实现完全功能性自动化生成的阶段。我见过一些地方制作可部署软件包甚至还没有可再生成的手段,一切都是靠手册,需要把一个个独立的建构块拼凑起来……你可以想象所需的试错数量。对于这些公司来说,仅仅是在不需要关心生成需要花多长时间的情况下实现自动化就已经是巨大胜利。

实现快速生成的问题在于这属于一种相对比较新的做法,而且我们还没有找到一种标准化或者规范化的流程来处理。仔细看看不同地方、不同CI/CD流水线时,你会意识到一切都是相当定制化的。不过,还有就是如果这种办法可行的话,我并不认为现在大家普遍担心这个问题,首要事情是确保你能自动化生成,然后才会考虑让这个过程加快的事情。

你的流水线并没有期望的那么快。你能不能大概介绍一下诊断流程?

Perez:诊断过程实际上跟任何其他表现相关任务都相当类似,要做的第一件事情是建立可靠手段来衡量你的CI/CD流水线,这样你就可以讨论具体数字而不仅仅是印象。大家抱怨往往是因为他们感觉生成很慢,但实际上却没有衡量具体的数据。衡量本身本来就是一项任务,因为一次生成往往需要不同的时间,取决于实际进行了哪些变更,所以必须关注平均时间、最大时间这些数据。

一旦团队对生成需要多久有了可靠评估之后,下一步就是建立阈值:生成应该花多久时间?这里仍然有许多变量会影响到决定;也许你希望设定一个最大的生成时间,以便能足够快地对关键bug做出响应,或者也许你只是担心平均生成时间,避免开发者等得心烦。做出决定可能会比较棘手,但一旦确定下来之后,你只需要定期将实际生成的时间跟阈值进行比较:如果实际时间低于阈值,很好;如果超过,你的生成就太慢了,需要采取行动。

另一方面,采取行动也跟其他表现相关的任务类似。如果你已经下结论说自己的生成太慢,那么显然你就得在某方面做出改变才能让它更快。但从哪儿开始呢?这里你就需要对流水线进行更细致的分析,看看每一个独立步骤的时间都花在了什么地方。通过这样你也许可以找出一些瓶颈,或者至少找到什么部分耗时更多。对这些地方进行修改的话就能得到最好的结果。

一旦你已经决定在什么地方采取行动,那就进入到以下改进循环中:进行修改,重新衡量表现,直到对结果感到满意。

这一切的挑战性表现在什么地方?是什么导致大多数公司跌跌撞撞呢?

Perez:我觉得主要问题是,尽管大家都很理解衡量——改变——评估的一般原则,但却还没有把这个原则应用到CI/CD流水线这一领域,这意味着他们实际上还不知道如何进行衡量。

为了让CI/CD流水线运作顺畅,测试扮演的是什么角色?

Perez:这实际上是一个非常有趣的问题。我近年来注意到了一件事情,就是团队内部的角色越来越专业化:有测试员,显然他的角色就只关注测试;然后,还有开发者,他只关心代码;还有业务分析师,UX(用户体验)设计师等等。有时候开发者还会进一步拆分为子角色,比如后端开发者和前端开发者,每个都有自己的知识领域。这类多学科团队是非常有利的,尽管他们还有一个重要的缺点:由于每个人都太过专注于特定的职责范围,一旦新的挑战出现时,就不清楚该由谁来处理了……

在这类团队内部,测试员的角色改变了很多。在一些团队里面,测试员关心的是整个用户体验,而在一些团队,他们编写了主要的端到端的自动化测试,他们需要跟开发者保持同步,确保其与开发者的单元和组件测试端到端的平衡,因为重复发生得很频繁,实际上测试是可以进行合并去重的。类似地,我认为测试员的角色可以扩张到跟DevOps工程师协调一起监督生成流水线,去理解测试时如何影响整体生成性能的,然后试着在需要时找出提高效率的地方。

老实说我认为测试员的角色有些被高估了,测试员应该逐步集成到团队的其他职责里面。测试员的工作相对于团队其他人来说太过孤立了,他们只是在认为自己发现了bug时才跟别人沟通。实际上,我认为其他团队成员应该在测试过程中一起协作来确保该活动更好地集成到一起。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

评论
查看更多评论

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

作者>更多

Valerie Silverthorne
Valerie Silverthorne

Valerie Rice Silverthorne是SearchSoftwareQuality网站编辑、作家。

企业应用集成(EAI)>更多

技术手册>更多

  • BPM资源指南

    业务流程管理BPM究竟是怎么回事?BPM资源指南涵盖了BPM工具的最新消息、举措和平台。了解业务流程建模符号、如何采用SOA影响的BPM建模工具,以及如何得到改善,以致业务分析师可以发挥重大作用的BPM举措。

  • “软件+服务”SaaS和SOA

    SaaS和SOA 号称“大小S”,软件架构是面向服务的SOA,软件应用出现SaaS新模式,中国软件与服务市场可谓是世界IT市场潜藏着的最大“蓝海”。应用软件开发厂商向SOA领域涉及的程度越来越深,SOA已经无处不在。随着SaaS的愈发火热,SOA的继续深入,业界出现了“软件+服务”(S+S)战略,旨在打通“内部业务整合(SOA)+外部业务拓展(SaaS)+丰富用户体验”等多重资源,实现SaaS和SOA“鱼和熊掌兼得”。

  • 移动中间件服务技术手册

    移动中间件是连接不同的移动应用,程序和系统的一种软件。移动中间件实际上隐藏了多种复杂性:在移动环境下工作的复杂性,允许设备对设备的流畅交互的复杂性,移动与计算机集成的复杂性和移动应用开发的复杂性。和其它的中间件一样,移动中间件也是通过提供信息服务来使不同的应用之间进行通话的一个典型。随着多样化的平台和设备进入到移动空间,移到中间件已经变得越越重要。随之而来的结果就是,众多移动中间件厂商纷纷提供开发服务,以解决快速增长的移动硬件与移动软件市场。本技术手册将介绍移动开发对于面向服务架构的影响,以及未来移动中间件可以实现哪些功能,在这个过程中我们有哪些经验和技巧可以参照。

  • 开源PaaS技术手册

    开源业界向来不太平,关于诸多技术的开源未来足以让很多粉丝兴奋躁动起来。商业软件开始揉进开源技术,开源技术也成为IT大佬们得基础架构,这一种趋势蔓延的缓慢有有力。在广告漫天飞得云计算中,开源的分量有多重?是否走向云端就意味着走向开源?开源的PaaS如何选择?如何为开源项目选择PaaS厂商?哪些服务平台值得我们关注,下面我们一一来揭晓。

TechTarget

最新资源
  • 安全
  • 存储
  • CIO
  • 数据库
  • 服务器
  • 云计算