失败罪魁祸首在DevOps?

标签: | 发表时间:2020-07-26 21:01 | 作者:
出处:https://mp.weixin.qq.com


概论




这样的浪费有很多原因,但不乏是由于传统行业对于软件开发、部署、发布、迭代以及运维的了解有限,因而本文面向传统企业转型中的困难和疑问,通过推进组织的DevOps转型作为抓手来尝试提供一份数字化转型指南,以资参考。


1、数字化转型


数字化转型是使用云计算、大数据,以及其他信息技术对企业的运营、组织架构和商业模式进行改造的过程,以提高企业相应客户需求的速度,增强企业与客户的联系。数字化转型不仅仅是技术转型,更需要从商业战略、组织架构、文化、客户关系等多维角度来确定企业的转型策略和目标。


这些维度和开发运营一体化(DevOps)变革和敏捷运动有众多重叠的领域。因而,我们可以使用DevOps作为抓手,在确定商业目标的同时,减少数字化转型中的成本,通过DevOps的成熟度指标,来关联和量化数字化转型的成果。 缺乏量化性的指标,就无法管理数字化转型的过程,也是造成大量投资浪费的原因之一。


2、开发运营一体化


开发运营一体化(DevOps)是对于企业内部开发和运营的整合的方法论、工具和指标。 衡量一个组织的DevOps成熟度,需要从技术、流程、度量和文化四个维度来进行评价。根据当前主流业界的标准,DORA(DevOps Research and Assessment) DevOps成熟度模型、软件交付表现SDP(Software Delivery Performance)包含了下面这些指标,包括前置时间(Lead Time)、变更失败(Change Fail)、可靠性(Availability),以及部署频率(Deployment Frequency)和恢复时间(Time to Restore)。



3、开发运营一体化和数字化转型的实例


微软公司,作为操作系统和办公软件的业界翘楚,也同样面临着数字化转型的压力。但是不同于其他企业,微软有深厚的工程师文化,强大的IT技术储备。他们面临的问题是如何将基于授权(license)的商业模式转型为以订阅(subscribe)为基础的订阅服务上。例如传统的单机密钥授权转换为云化的office 365订阅服务。


在这期间,微软着重推行了敏捷开发模式并且是office业务上云,同时将其传统的基于私有数据中心的Team Foundation Server改造成为基于微软云业务的Microsoft Azure DevOps。这成为了微软内部的运营开发一体化的转型抓手和重要推动引擎。


开发运营一体化能力建设


依据DORA(DevOps Research and Accessment)超过六年对业界技术能力(Technical)、流程(Process)、度量(Measurement)和文化(Cultrue)四个维度的连续研究和评估,我们同样可以从这四方面进行建设。


1、技术能力


版本控制跟自动化紧密相关。事实上,建设持续集成和持续交付能力的建立在成熟的版本控制流程和工具的基础之上。很多企业在建立版本控制的时候,更多关注的是代码,而忽略了代码之外的配套流程和制品,例如测试用例、自动化测试脚本、测试数据、基础设施和数据库。我们在建立版本控制的时候,需要实现 基础设施即代码、配置即代码、数据即代码,以及测试即代码。版本控制可以帮助企业满足以下两个最关键的需求,即:


1)可复制性(Reproducibility)


可复制性是保障我们的开发、测试,以及生产环境的可复制性。能够快速通过自动化的手段实现环境的复制和重建,进而保证环境的一致性。


2)可追踪性(Traceability)


可追踪性的目的是为了保证团队可以在任何时间都可以利用版本重建环境,并且可以比较两套环境的区别。


2、主干开发模式


业界有两种常见的软件开发模式,即功能分支模式(Feature Branch Based Development)和主干开发模式(Trunk-based Developoment)。


1)功能分支模式



功能分支模式是指开发人员从主干分支(Master分支)拉取代码来开始开发,直到开发人员认为代码开发结束,即从不可部署阶段到可部署阶段。如上图所示,即从浅灰色变为深灰色,才将代码重新合并到主分支。


这种模式有两个主要问题。第一,每一次发布都伴随着大量的代码合并,并且会引起代码冲突。原因是每次分支合并的代码量过大;第二,需要手工维护代码的合并,因为代码不仅仅是合并到主干,还需要人工判断是否需要合并到其他功能分支上。一般的逻辑是如果另一个功能分支的发布时间晚于当前要合并的分支,并且后面的发布需要当前分支的功能或问题修复,即需要合并,即所谓的向后合并。向后合并可以采用自动化合并的模式来实现,例如可以依赖于Jenkins来实现自动向后合并。由于每次合并代码都需要完整的测试,所以需要代码锁定(Code Freeze),以确保代码的稳定性。


2)主干开发模式


不同于功能分支模式,主干开发模式是实现持续集成的必要条件。开发人员只有在代码准备发布的时候,才会拉出发布分支, 所以发布分支一直是可部署的状态。而在功能分支模式下,功能分支不一定是可部署状态。开发人员每天都会把当下代码签入主干,但是要求开发人员如果自己签入的新代码引起了任何问题,必须立即修复,否则会阻塞其他开发人员签入代码。因为每次签入的代码量比较少,所以出现代码冲突的可能性就会大幅度降低。同时,主干代码因为继承了回归测试的自动化,任何破坏回归功能的代码都会被立刻修复,也维护了代码质量。主干开发模式不需要锁定代码或者其他手段来保证代码稳定性。


实现主干开发模式的要点:


  • 分支数目控制在3个或以下;

  • 至少每天一次代码合并;

  • 不要采用代码锁定(Code Freeze)和集成阶段;

  • 确保在代码合并之前进行代码复查(Code Review)和代码扫描(Code Scanning), 推荐使用PR(Pull Request)代码扫描。


3、测试驱动开发


开发人员经常误认为开发运营一体化(DevOps)就是讨论开发和运维,即Development和Operation,其实这是一个望文生义的一种误解。在推进DevOps转型中,很多企业和团队经常忽略了自动化测试这一个关键的因素。没有完善的测试驱动开发流程, 没有完善的回归测试自动化,持续集成就是空谈。



上图是测试驱动开发TDD的流程示意。新的功能在拿到需求之后,测试人员和开发人员都需要被通知。所有的开发都是基于对测试用例的实现。首先增加新的测试用例,并且运行自动化测试。此时,由于代码还没有开发,测试一定会失败。这么做的原因是让开发和测试人员明确在代码开发之前新增加的测试用例是失败的,从而避免测试用例的错误而造成测试用例错误通过的问题。开发人员根据测试来进行功能开发,直到所有测试用例通过。当测试用例通过之后,开发人员进行代码的重构来进行代码优化,以实现安全性和性能的要求。在签入代码到主干的时候,如果发现自动化回归测试失败,测试人员需要更新自动化回归测试确保回归测试是最新状态。


实现TDD的要点:


  • 代码签入都会触发自动化构建;

  • 代码签入会触发一系列自动化测试;

  • 确保每天的构建和自动化测试必须是成功状态;

  • 如果出现构建和测试失败,开发人员必须立即修复。


4、自动化测试


自动化测试给开发人员提供了一种快速反馈的机制。自动化测试是保证持续集成的基础条件。自动化测试包括下面两种测试种类:


1)单元测试(Unit Test)


单元测试是TDD流程中经常使用的针对单个函数、类或者方法,来保证开发人员的代码按照预期的测试方法。单元测试的开发早于业务代码,流程在上一节介绍TDD的内容中已经提及。 


2)验收测试(Acceptance Tests)


验收测试是针对程序或这API进行功能上的测试,本身也是开发工作的一部分。开发人员在没有通过验收测试之前是不能够认为开发工作已经完成。



上图从四个角度分析了自动化测试的使用。


从业务角度来看,验收测试和手工探索性测试都是针对业务功能进行的,来保证业务流的顺利进行。一般手工测试在代码上生产环境之前进行,有些团队称之为PVT(Product Validation Testing),即产品验证测试,对应的测试人员一般都是业务专家。


从开发支持的角度来看,单元测试和自动化验收测试是实现CICD和TDD的关键。



以上为一个完整的CICD从开发到发布的流程。在commit stage中,经常会进行代码扫描和单元测试。如果单元测试或者代码扫描未通过,开发人员可以获得快速反馈,并根据需要重新修改代码。 这个地方可以实现问题的左移, 即代码风格问题左移和安全性左移。


在自动化验收测试时,如果测试未通过,有两种可能性。第一是业务代码有问题,第二为验收测试代码需要调整。这个反馈应该发送给对应的测试团队和开发团队。


3)自动化测试金字塔(Automation Testing Pyramid)



根据自动化测试金字塔模型,尽可能多的问题应该被自动化单元测试发现,这样可以降低测试成本,开发人员可以尽早获得反馈以修改代码。验收测试的作者和维护者,应该尽可能是开发人员,这一点经常被很多企业和团队所忽略。


5、测试数据管理自动化


测试数据管理是很多团队和企业在做DevOps转型中容易忽略的领域。测试数据是保证测试能够正常进行的基础。没有良好的测试数据管理,会提告测试缺陷的误报率,降低团队的信息,忽略真正的严重产品缺陷。


测试数据管理必须要保证自动化测试能够顺利进行。针对不同的环境,例如测试环境、预生产环境、测试数据必须能够区别管理,因为不同环境的测试数据有可能会有不同。


测试数据管理应该能够自动的在环境设置完成之后,配置测试环境,以便开展自动化测试。在测试完成之后,能够自动清理数据,并且恢复环境至测试开始之前。


测试数据管理必须要能够根据代码开发更新,确保数据的实时性。


本文主要从技术的角度探讨DevOps如何助力企业数字化转型,后续将陆续推出包括DevOps流程、指标、文化和组织角度的解读,敬请持续关注。


相关 [devops] 推荐:

DevOps 实战

- -
DevOps 的 3 个支柱. 第 1 步:寻找合适的试点项目. 第 3 步:快速建立初期成功. 第 4 步:快速展示和持续改进. 第一阶段:每次提交触发完整的流水线. 第二阶段:每次流水线触发自动化测试. 第三阶段:出了问题可以在第一时间修复. 第二步:定义指标并达成一致. 第三步:建立自动化执行和检查能力.

DevOps实践一:DevOps概述 - 知乎

- -
DevOps系列文章包含了本人在工作中的实践和认知理论,现总结并分享出来,希望能够给“迷你型”团队在DevOps上的实践提供一个“反面教材”和可行性建议. 本系列主要包含以下文章(过程中可能也会有所更改):. DevOps实践一:DevOps概述. DevOps实践二:持续集成、持续交付和持续部署.

『DevOps 最佳实践』 — DevOps 实践

- -
Culture – 文化:公司各个角色一起担当业务变化,实现有效协作和沟通;. Automation – 自动化:在价值链中尽量除去手工步骤;. Lean – 精益:运用精益原则更频繁地交付价值;. Metrics – 度量:度量并使用数据来优化交付周期;. Sharing – 分享:分享成功和失败的经验来相互学习.

让DevOps起作用

- - InfoQ cn
根据Neil Garnichaud在Dr. Dobb’s上发表的文章《 究竟什么是DevOps》,想要频繁地发布高质量的软件,首先需要弄清如何使开发人员、QA人员和运营人员在一起协同工作. 在软件公司里,特别是在开发基于云的网络应用, 而又缺少有才华的、合格的员工的公司中,压缩的时间进度和最低限度的QA是压力的根源.

『DevOps 最佳实践』 — DevOps 平台 - Ledge DevOps 知识平台

- -
DevOps 数字化转型框架. 企业为什么需要一站式综合研发平台. 越来越来多的组织开始搞敏捷和 DevOps 转型,打造了很多的 DevOps 基础设施,比如有管理需求的 Jira, 有持续集成的 Jenkins,有容器编排的 K8S 等等. 可是这纷繁复杂的 DevOps 工具链,同时也给企业带来新的困扰.

DevOps,你真的了解吗?

- - IT经理网
与大数据和PRISM(NSA的监控项目之一),DevOps(开发运维)如今是科技人士挂在嘴边的热词,但遗憾的是,类似圣经,每个人都引用DevOps的只言片语,但真正理解并能执行的人极少. 根据CA的一项 调查,45%的受访者并不了解DevOps的含义,其余则有17%认为DevOps只不过是炒作. DevOps如今几乎成了创新的同义词,但其原本的含义却在业界的流传中被人们弃之脑后.

Kubernetes 会不会“杀死” DevOps?

- - InfoQ推荐
DevOps 这个概念最早是在 2007 年提出的,那时云计算基础设施的概念也才刚刚提出没多久,而随着互联网的逐渐普及,应用软件的需求爆发式增长,软件开发的理念也逐渐从瀑布模型(waterfall)转向敏捷开发(agile). 传统的软件交付模式(应用开发人员专注于软件开发、IT 运维人员负责将软件部署到服务器运行),再也无法满足互联网软件快速迭代的需求.

DevOps最佳实践(200711)

- - 人月神话的BLOG
今天准备谈下DevOps过程最佳实践以及DevOps支撑平台建设中的一些思考. 在前面文章里面我就已经谈到了传统企业IT架构转型或企业数字化建设需要解决两个方面问题. 其一:业务层面,重点是中台规划和建设. 其二:技术层面,重点是云原生解决方案,包括了微服务,DevOps和容器云. 当然,如果你是传统的软件开发框架技术,或者传统的基于虚拟机的PaaS平台也可以上DevOps实践,但是我们更加推荐的还是基于微服务和容器云技术来实践DevOps.

DevOps的“定义”:DevOps究竟要解决什么问题?

- - InfoQ - 促进软件开发领域知识与创新的传播
近些年来,DevOps 在我们身边出现的频率越来越高了. 各种大会上经常出现 DevOps 专场,行业内的公司纷纷在都招聘 DevOps 工程师,企业的 DevOps 转型看起来迫在眉睫,公司内部也要设计和开发 DevOps 平台……这么看来,DevOps 似乎无处不在. 可回过头来想想,关于 DevOps,很多问题我们真的想清楚了吗.

你的团队里没有DevOps文化?

- Quantum - LinuxEden开源社区-Linux伊甸园
本文是从 Do you have a DevOps Culture. 全球很多的系统负责人和程序开发者都在 撰写 、 聚会 和 讨论 关于DevOps的事:如何能更加有效的协作、让我们更快的创造商业价值. 阅读全文 | 邮件推荐 | 评论回复.