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

日期: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)>更多

  • 企业架构模型:最大化地实现移动授权

    几乎每一家企业都希望通过移动改进员工生产力,然而大多数调查表明,他们对自己努力的效果并不满意的。企业对移动员工需要什么并不是很清楚。第一个解决方案应该考虑企业架构。

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

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

  • 企业架构师角色转变:有失也有得

    云和移动时代的到来已经改变了公司应用IT的方式,也因此改变了企业架构师的角色。他们跟业务的协作也越来越紧密,而不是仅仅专注于IT。

  • 开发人员:构建API时先自己试试

    为已有产品构建API的挑战是,业务需求总是最重要的。为了跟上业务需求的脚步,我们通常被强迫在产品质量上作出让步,也绝对是API开发的最差方式。

技术手册>更多

  • SOA数据治理与管理指南

    在现今包围SOA的所有诉求和术语中,对团体而言,最寻常的仍是寻求如何将面向服务架构集成到他们的IT框架中,以避免他们设计中的数据整合、处理、管理等相关问题。他们开始学着与SOA并存,然而,他们经常发现与其他系统的协同工作、解决方案引起了令人觉得好奇的问题。本专题为企业架构师和开发人员提供了SOA数据治理与管理的基本知识和最佳做法。

  • OSGi模块化技术手册

    最近有一些争论,主要是关于是否完全成熟的OSGi模块化是严格意义上必须的东西,或者Jigsaw是否一种足够好的“更简单”的方法。但是也许关键点在于对于任何既定的组件在哪里适合什么模块化。OSGi是Java领域里无可辩驳的最成熟的模块系统,它与Java几乎是如影相随。在这本技术手册中我们将分三部分来和大家聊聊OSGi模块化以及它和Java千丝万缕的关系。

  • 云应用性能管理和测试教程

    云里来雾里去的云计算讲了好多年,其实对于大众来讲对这个概念仍然是有些摸不着头绪。那么对于已经应用了云服务的企业而言,在实践中有哪些技巧可以参考或者有哪些经验可以分享呢?在这期技术手册中,我们将一起来关注云应用的可用性,如何进行云应用的监控,云服务中间件如何?同时我们将侧重于云应用性能管理以及云应用测试的内容。

  • 业务流程执行语言BPEL(升级版)

    BPEL即业务流程执行语言,是一种使用XML编写的编程语言。用于自动化业务流程,也曾经被称作WSBPEL和BPEL4WS。广泛使用于Web服务相关的项目开发中,优点为具有可移植性和有效保护了投资。

    BPEL是一门用于自动化业务流程的形式规约语言。用XML文档写入BPEL中的流程能在Web服务之间以标准化的交互方式得到精心组织。这些流程能够在任何一个符合BPEL规范的平台或产品上执行。 所以,通过允许顾客们在各种各样的创作工具和执行平台之间移动这些流程,BPEL使得他们保护了他们在流程自动化上的投资。

TechTarget

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