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

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

技术手册>更多

  • SOA环游地球之旅 八大精彩案例集锦

    世界之大, SOA IN ACTION。放眼全球,面向服架构已经开始了较为广泛的应用,我们搜集了相关的精彩案例,在此与读者分享,一起关注SOA的发展动向以及其业务价值。让我们开始这段SOA环球之旅。

  • JBoss实用技术手册

    JBoss是一个同时运行Web及EJB的J2EE应用服务器。它是开放源代码的项目,遵循最新的J2EE规范。从JBoss项目开始至今,它已经从一个EJB容器发展成为一个基于的J2EE的一个web操作系统(operating system for web),它体现了J2EE规范中最新的技术,无论是学习还是应用,JBoss为我们提供了一个非常优秀的平台。

  • BPM和业务集成分析指南

    随着时间的推移,技术在企业活动中的影响日渐深入。受这种趋势的影响,我们有时会把技术当成业务流程管理(BPM)架构、系统和应用的替代品。做BPM的朋友经常与实际的项目打交道,可能经常听到一些组织中的BPM项目负责人会说:“我们的项目失败了,但是我们不知道为什么,或者我们能做点什么呢?”如何才能让BPM和我们的业务更好地集成成为很多专业人士思考的问题。在这本分析指南中,我们将会就BPM项目失败原因、业务流程实现中的陷阱如何规避以及云端的BPM进行相应的探讨,也欢迎您参与到我们的探讨中来。

  • SOA生命周期

    服务生命周期管理是SOA治理向SOA及SOA服务的实际构建中的一个应用。然而,治理属于业务涉众,管理是技术人员(负责“实现”的团队)的权限。服务生命周期管理必然与SOA治理紧密结合,因为在软件交付的每个步骤(从业务分析人员到架构师到开发人员到测试人员,再到操作)上,确认了将要构建的内容结合了企业的明确业务需求是关键的。 

TechTarget

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