自动上线测试已经不潮了，你有跟上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的方式，来达到提升发布速度及可靠性，而透过度享的回馈机制来改进，当这些观念结合在一块儿以后，才有助于组织能够更有品质及效率的交付产品给客户，而除了武功心法外，在实务概念上还有下列几点：

一、 持续交付及持续整合：

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

二、 服务微型化：

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

三、 基础设施即程式码：

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

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

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

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

好雨云xDevOps

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

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