自动上线测试已经不潮了,你有跟上DevOps的潮流吗?


相信大家一定都(没)有使用过Facebook的经验,一定对他的快速改版私毫不陌生,可能早上醒来时发现「赞」的图案突然从实心变从空心,或是开始多了一些缤纷酷炫的功能(像是直播、限时动态..等等),但你能想像一下吗?在过去十年前,大部份软件服务上的版本更新,都只能像是Office每年的一期一会来做推陈出新,但新的功能可能没解决到用户的痛处,反而增添了更多不必要的麻烦。

所以在快速变迁的时代里,这种快速、持续发布新版本的特性,俨然成为了适性生存的不二法则。你能想像Flicker每天至少会有10次以上的服务发布吗?如果在传统的开发方式,一旦有新功能的释出,如果使用者体验不好需要改进就算了,但如果有BUG的话,却需要等待一个月或一整年的时间才能解决,这样的产品你还会想用吗?

所以与传统开发方法那种大规模的、低频繁的发布,敏捷方法为基础的DevOps,目的就是为了提升了发布频率的速度与效率,从过去的「年」、「季」,提升到「月」、「周」,甚至是「日」。

但快速发布的概念,并非是「开发团队」的步调快速紧凑起来就可以达到的方式,因为每一个新版本的Release,除了靠开发团队的努力外,也需要「维运团队」、「测试团队」的努力,才有办法相辅相成,但通常在公司里「开发」和「维运」都是隶属于不同的部门的业务,开发目标是推陈出新,但维运部门在乎的是系统稳定性及可靠性,在这样两者恒相冲突的状况下,又该如何透过整合来达到「快速」的目的呢?

所以DevOps开发方法最主要改善的是开发团队以及维运团队的关系,并透过Agile「敏捷式开发」的概念,让交付可以达到「透明化」、「持续化」以及「自动化」等目标。

关于DevOps

先介绍一下DevOps吧,DevOps是来自Development和Operations这2个英文字的缩写组合,跟Agile一样,他并非是使用特定的工具或技术来做为解决方案,而是一种具备文化、哲学、实务与工具于一身的概念结合,主要目的是提升组织快速交付应用程式和服务的能力,仅管相较于使用传统软件开发的「瀑布式」的管理程序,这种作法能更有效率的快速开发和改进产品,并提供更具竞争力的服务。

但很多文章中会将DevOps翻成 「快速交付」 、「持续交付」,但这并非完全正确。因为针对传统端对端开发流程,每一个部门都有可独立切割的功能,开发团队专注软件开发,维运团队做软件发布(或软件部属),而测试团队就是做上线前后的测试。是当功能被明显切割后,仅管遵循公司开发流程,但团队间讯息上的同步势必会有所影响,例如当开发团队递交的软件,不符合部署环境,或是因功能更改软件规格时,维运团队可能就因为资讯落差而退回交付;又或是开发团队交付功能给测试团队后,却因为不甚熟悉造成测试漏洞,当然也有开发环节测试不过的可能性,但综合以上的案例,就会拖累软件交付速度。

所以DevOps最核心的概念就是为了解决跨部门与跨团队间的冲突,透过透明度的提高以及一些机制的导入,来做有效率的整合,来完成提高上限速度的目的。他的核心概念可以用"CALMS"来做解释。

"C"ulture-文化:

因为DevOps并非是一种技能或是工具,而应该要三个部门一起对齐的文化,透过同理心的互惠,多位其他部门的人去思考,在着手开发,一来可以解决资讯上的同步问题,更可以解决因为部门落差造成时间成本损失。例如开发团队应该要在程式的设定档上,设计的更易管理..等。透过共识、理解和沟通,进而改善部门间的整合问题,才是"C"代表的真正意涵。

"A"utomation-自动化:

A通常就是开发团队最重视的问题,像是中间提到每一个容易造成Delay的环节,像测试及部属等等,若是都可以透过自动化来做排程,不仅可以减少沟通落差造成的问题,更可以让需求开发及整合上更为快速,想像如果使用自动化测试和自动化部属,那开发完成后的需求,就可以一下进入上线准备,这不就是「持续交付」的真谛吗?

"L"ean-精益开发:

因为DevOps也隶属于敏捷式开发上的内容之一,所以也必须套用精实开发上的一些原则,像是消除浪费(eliminate waste)、尽快交付(deliver as faster as possible)等,来符合Agile的精神。

"M"easurement-数据分析:

不断的精进是需要依据,而M的重点就是在透过数据上的反应,来给团队正向及改进的回馈,例如新功能上线后减少了多少客诉量、缩短多少作业时间等,甚至是每次上线后的BUG率及修复率等,都是可以被测量出来的基本指标,来反应出开发者的量与质是否正比。

"S"hare-分享:

既然有了数据,就应该把成效分享给DevOps间的所有参与者,来做下次检讨、改进的目标,而分享不仅是文化的根,也是增加团队透明度的好方法。而DevOps的好处,就是透过CALMS的方式,来达到提高发布速度及可靠性,而透过分享的回馈机制来改进,当这些观念结合在一起之后,才有助于组织可以更有品质及效率的交付产品给客户,而除了武功心法外,在实务概念上还有下列几点:

1、 持续交付及持续整合:

持续整合是软件开发实务,在自动化测试及自动化发布的机制建立后,透过自动化流程来让程式码上到测试/正式环境,因此如果导入DevOps开发方法中的自动化部署,便可由开发团队设定部署环境,由工具做自动化部署,减少手动以及传递的时间,且可以避免人为错误,改善软件交付品质。除交付作业可以有效的「持续化」,并透过「持续整合」来更快速的发现及整合错误,进而改善交付品质。

2、 服务微型化:

一项产品若是架构过于巨大,不仅在更板上会绑手绑脚,更容易会有签一发而动全身的状况发生,而若是采用DevOps概念的产品,为了持续交付和整合,通常化把产品的分工切的更为细微,让纵向的产品变成横向发展,把产品服务从多功取向,变成个别单一的服务(或API),而每个服务的用途也尽可能的单一化。从过去大而久的发布频率,变成小而快,这就必须要依赖把服务微型化这个任务了。

3、 基础设施即程式码:

基础设施即程式码是透过使用程式码和软件开发技术,来做部属与管理基础设施的实务,例如透过云端服务或API的导入,让开发人员和维运人员可以透过程式设计的方式,来和产品及基础设施做互动,来取代过去手动设定的繁杂手续,进而实现持续整合的目标。而这样的好处就是让所有的定义都透过程式码,来标准化作业模式完成快速部属的目标。

而DevOps和传统的开发方式,最大的差别就是在实务上是透过更细微的分工切割、更一致性的作业流程,以及更频繁的发布,来取代过去更版不易,耗时后久以及组织平行沟通的问题。透过小而频繁的改进,才有机会让产品更贴近使用者的意见和心声,也可以有效率的让产品进行成长。而自动化的导入更可以减少沟通落差造成的部署问题。

但记得,再多个概念和工具,都是为了弥平资讯流上的误差,以及强化跨部门工作上的整合性,光只有导入机制还不够,还必须透过定期的review和改进,才有办法完成适合每一个组织或团队自己的机制,这也才是符合敏捷式开发最重要的精神。

只有「快」还不够,而是要让整个生产机制的效率提高,才是提升团队生产效率的不二法门。

好雨云xDevOps

好雨云提供面向业务的DevOps工作流最佳实践,遵循以应用为中心的设计理念,利用容器技术、微服务架构和软件定义系列技术解耦服务器和应用,清晰界定开发与运维之间职责,企业IT将可以零负担落地DevOps工作流,通过好雨云独有的“应用级”生产面板和“业务级”运维面板,专注于业务并以以自动或自助方式完成计算资源运维工作,达到降本提效的目的。

进一步了解好雨云DevOps:https://www.goodrain.com/scene/devops

0 个评论

要回复文章请先登录注册