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

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

技术手册>更多

  • REST开发者RESTful资源指南

    维基百科把表述性状态转移(Representational State Transfer ,REST)定义为“分布式超媒体系统、如万维网的一种软件架构形式”。Web服务的RESTful方案被广泛视为SOAP的一个更简单的替代方案。许多大型的Web服务提供商如亚马逊、Twitter和谷歌都在广泛地使用它。在这本技术手册中,我们将为您提供一些RESTful资源和技巧。

  • 敏捷开发技巧指南

    敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。关于瀑布方法和敏捷方法的分析已经探讨过多次,但瀑布方法在某些项目和开发团队中还存在价值。《敏捷宣言》声明指出,个人和交互高于流程和工具。由于开发项目的利益攸关者已经变得越来越分散,遍布在全球各地,甚至经常横跨了几个时区,基于云的开发环境已成为必备之选而非锦上添花。TT SOA在这本技术手册中将介绍敏捷开发的一些技巧以及瀑布方法和敏捷方法的对比,同时还涵盖了云对于敏捷开发所起到的作用。

  • SOA与敏捷开发实战演练

    SOA是一种架构,敏捷是一种方法论,架构和方法论是可以一同使用的,它们本质上是互补的。而且,SOA和敏捷的目标相同,它们都承认(1)变化是必然的(2)组织需要有效地应对变化。所以,我们期望在构建SOA时,能够选择敏捷方法论,反之亦然。本技术手册给出了二者结合的完美之道。

  • 云集成实践基础教程

    随着面向服务和基于云的架构脱颖而出,IT部门越来越重视良好的集成设计。为了避免过快的云应用集成的潜在危险,需要精心策划架构。随着应用集成需要更多的灵活性和普遍的可适用性,优化设计比以往便得更加重要。在即将到来的云计算应用集成中,以集成为中心的云计算,像iPaaS,显示了云应用者数量的快速增长,未来也将面临着更加复杂的集成和实际挑战。在这本技术手册中,我们将重点关注云集成实践。

TechTarget

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