[转载]持续交付和DevOps的前世今生

作者/分享人:乔梁,20年IT老兵,腾讯公司高级管理顾问,敏捷和精益开发专家,持续交付领域先行者。曾就职于百度,国内多个知名互联网公司的企业教练。 历年QCon技术大会的讲师和专题出品人。

这是一个新概念风起云勇的时代。 就让我们从云端抓它几个名词下来,一起玩耍吧!!! “敏捷软件开发”,“增长黑客”,“持续集成”,“DevOps”,“精益创业”,“持续交付”,“大数据”... ...

OK,就这四个啦:

“敏捷软件开发”,“持续集成”,“DevOps”,“持续交付”。

先让我们在Wikipedia上验明正身。

在Wikipedia上的定义

敏捷软件开发

Agile software development describes a set of principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams.

持续集成

Continuous Integration (CI) is the practice of merging all developer working copies to a shared mainline several times a day.

持续交付

Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time.

DevOps

DevOps is a term used to refer to a set of practices that emphasize the collaboration and communication of both software developers and information technology (IT) professionals while automating the process of software delivery and infrastructure changes.

我的解读

1. 敏捷软件开发方法

从来就没有一种方法,叫做“敏捷软件开发方法”。因为,IT行业中的“敏捷(Agile)”一词,从2001年它的诞生之日起,就是个软件开发方法集合,当时这个集合中的方法,都遵从敏捷宣言和相同的工作原则(十二原则),它的缔造者是十七位软件工程师(请查敏捷,雪鸟会议)。目前,在这面大旗下,又增加了很多种方法,当然也有很多方法走出了人们的视线。

在国内比较活跃的几种方法:极限编程XP(2009年以前),Scrum及其进化品(2006年至今),精益软件开发方法(2009年至今),看板方法(2012年至今)。当然,现在好象也不再特意强调“敏捷宣言”和“十二原则”了,只在培训课堂上还能听到。

2. 持续集成

早在1999年KentBack的《解析极限编程》一书中,对“持续集成”这一概念就有提及,它是极限编程XP方法中的十二最佳实践之一。在2004年,Martin Fowler发表的一篇博文上,给“持续集成”下了一个定义,并一直沿用至今。即:“持续集成是一个软件开发实践, 是指团队成员频繁地集成他们的工作成果,通常每天每个人至少集成一次, 这样在团队内每天都会有多次代码集成,每次集成都有通过自动化的构建(包括测试)尽可能快地发现集成问题。” 这个概念已被软件研发团队广泛接受,但是其中提到做法,并未能全部落实,太困难了。 这是正常的,来自极限编程方法的实践,都是有挑战的,否则就不叫“极限”二字了。

3. DevOps

在2008年的一次敏捷大会上,运维相关人员就“敏捷基础设施(Agile Infrastructure)”展开讨论,并在2009年以后逐步发展成为一场大规模“运动”,它是期望改变开发团队和运维团队之间协作关系的一场运动。强调开发团队与运维团队的沟通与协作,同时将软件的交付与基础设施变更过程都能够自动化。近年基础设施及工具链的发展,也让DevOps多了一些发力点。

4. 持续交付

Jez Humble和David Farley在2010年《持续交付》一书中正式提出这个概念,它在书中被定义为:一系列的原则与实践的集合;通过这个集合,团队能够在低成本、短时间及低风险的状态下以增量方式将软件变更交到用户手上。Jez认为,持续交付有三个支柱,它们分别是持续集成、自动化测试和部署流水线(Deployment Pipeline)。

它们的关系

1. 空间与时间维度

根据以上的信息,我认为它们在空间和时间维度的关系是这样的:

上面这个图是从实践或环境的角度来看它们之间的关系。那么,如果我们换一个角度呢?

2. 人或组织维度

我的微信签名是“别提概念,只解决问题!”。所以我更愿意从解决问题的角度看这些概念。一谈到问题,就有一个经典的话浮现在我脑海里:“所有的问题,都是人的问题”。所以,这个角度看到的才是本质。那么,它们的关系是什么呢?

持续集成,有助于打破开发人员和测试人员之间的“墙”。

敏捷开发,有助于打破研发团队(开发+测试)与业务(产品)人员之间的“墙”。

DevOps,有助于打破开发团队与运维团队之间的“墙”。

持续交付,则是希望从端到端的角度,考虑如何解决问题。

为什么从“人”开始

在我多年的持续交付践行及咨询工作中,总结的经验是:如果希望在最短的时间和成本内,取得最大的收获,那么在一开始,与“人”相比,技术实践并不需要太在意,即:最好还是先从“人”的角度看问题。真正去解决问题时,上面说的种种概念并不是那么重要。它们都是你用来解决问题的工具,而且其中的每一个工具(概念)都包含了很多个小工具(原则和实践)。而且,在解决问题时,你也不必整套选择这些工具。

从哪里找问题

从参与者的问题陈述中找问题。比如:

老板:

  • “项目经常延期” “做东西太慢”

产品:

  • “老板的想法总变”
  • “事情太多,忙成狗”
  • “开发说这个实现不了”

开发:

  • “需求总变”
  • “UI方案给的太晚”
  • “活儿太多”

测试:

  • “需求变了没提前通知”
  • “测试时间总被压缩,还要背锅”
  • “重复测试太多遍”

运维:

  • “每天这么多版本上线,活干不完,出事儿第一个背锅。”

每句话的背后都有很多含义。开挖吧~~

提问题的人是问题的创造者,也是接盘侠~

从哪里找解决方案

在《持续交付》一书的第十五章,提到一个“持续交付成熟度评估模型”。在这个模型中,包含如下六个维度:

  • 构建管理和持续集成
  • 环境与部署
  • 发布管理和和符合性
  • 测试
  • 数据管理
  • 配置管理

通过实际工作的验证,我发现,这里面缺失了一些东西。所以,增加了一些维度,并重组了一下,如下图所示:

我也没有称其为成熟度模型,而是“持续交付七巧板”。

是的,中国的传统玩具“七巧板”,这个儿时的玩具可以拼出各种各样的图形。也就是说,每个团队、企业都有不同的环境上下文(人也是环境的一部分),解决方案也不必一样,关键是你想解决什么(想拼成什么图形)。

找正确的问题去解决

上面的诸多概念并不是你的问题或目标,而只是你的工具(手段)。千万不要把手段当成你的目标来实现。很多人问:

  • 怎么做持续交付?
  • 怎么做持续集成?
  • 怎么做敏捷?
  • 怎么做DevOps?

我猜测你是想问:是否有捷径做XXX。当然有,多种途径里,一定有相对来说的捷径,但不一定是你期望的那种“捷径”。

  • 我们做的是敏捷吗?
  • 我们这么做持续交付,对吗?

我猜测你是想问:(某个人或部门)这么搞,是不是靠谱啊?

  • 你这不是敏捷?
  • 你这不是DevOps?
  • 你这不是持续交付?
  • 你这不是持续集成?

我想说:无所谓,因为我的在微信上的签名是:别提概念,只解决问题。我们还是先讨论清楚问题吧~

再炒一炒冷饭

2011年,我在InfoQ上发表了一篇案例文章《DevOps,不是一个传说!》,其中有两个评论比较有意思:

1. 怎么感觉就是一个从瀑布模型到Scrum/CI的变化?
正如我们上面第二张图所示,这个项目的前期工作,的确主要是在敏捷开发的范畴,但文中还是提到一小部分Ops方面的东西,可能评论者没有注意到吧。或者没有看到他想找的内容。

2. 标题党啊
好吧,我承认在那个很少有人提及“DevOps”的年代,我就做标题党吧。

这个案例就混合了上面所有的概念,但在项目里,谁还在意概念呢,达成结果最重要。

一、了解环境背景

当任何人想要对组织进行改变时(无论改变的大小,你叫它改进、转型或者变革都可以),一定先要了解组织的历史,感受组织的文化,因为组织的历史决定了问题的来源,定义了问题的范围。

几年前的百度,工程管理相对固化,敏捷还在“小步快跑,越变越美”的倡导期(从瀑布到迭代,强调项目管理中的迭代概念)。一个从Google跳槽加盟百度的技术经理在自己的部门里倡导“主干开发(Single Branch mode)”,但由于原有的基因特别强大,进展艰难。 而这个项目是在最有百度特质的大搜索团队,试验田是一个10人左右的工程架构团队。

团队间接管理者

  • 项目交付不太可控:
    • 我们一直在做计划,但计划性非常差。
    • 经常有各种各样的情况发生,总会让项目改期。

团队直接管理者

  • 我非常希望能够快速交付,但我们对这类架构变动类的项目不知道怎么能做到。
  • 这个项目中,有一部份需求必须在XXX时间点完成。

团队Lead

  • 估算不准确、临时插入事情多、项目计划很难做(这里省略一千字)。
  • 我不知道怎么改进,因为我周围的团队也是这样,而且一直这样工作。

开发人员

  • 领导说试一下,就试一下吧。

测试人员

  • 工作经常被打断。
  • 提测质量不高,经常浪费精力。
  • 出了Bug,影响太大。
  • (这里省略一千字)。

二、找到正确的问题来解决(目标)

三个月内:

(1)该项目交付时间可预期。

(2)建立新的软件开发协作方式。

(3)建立必要的基础设施,以支持后续的持续发布模式。

三个月后:

(1)需求的周期时间缩短,可以短周期上线。

(2)生产环境的质量不降低。

(3)测试人力总投入降低。

在少于30人的团队(61个人也可以~哈哈~那62个人呢~~~)

  1. 通常行为的改变,需要一个半月的时间;
  2. 带来强烈可感知的收益需要三个月的时间。

三、承诺是必须的

上面的问题(目标)找到了,也要一并承诺。

要想让团队和你走,你必须站在前面。

四、培训及过程指导

需要解决团队提出的任何疑问,如果当时不知道如何解决,也要承认。

启蒙培训(1小时)

对于这种能够直接认识团队每个人的小团队,一开始就别花费太长时间讲大道理,以解决具体问题的方式来启蒙。

重新定义工作流程

  • 新的项目工作流程
  • 新的迭代工作流程
  • 新的需求工作流程

  • 新的代码工作流程

解决新流程中的障碍

  • 团队沟通和协作的方式。
  • 编译环境的准备。
  • 编译时间的缩短。
  • 自动化测试策略的制定,比如:我们放弃了原教旨主义的单元测试。

  • 自动化测试运行的环境的准备。
  • 自动化测试编写时机与自动化的利用。
  • 自动化测试用例代码管理。

我和运维人员的对话(真实的场景再现)

我:我们团队想每两周就部署一次服务

运维:不行

我:为啥?

运维:线上需要稳定

我:每两周部署一次,就不稳定了吗?

运维:原来的质量太差,每次上线总是出问题

我:现在质量很好

运维:怎么可能?

我:我们改变了工作方法,质量优先,你可以参加我们的站会。你有什么要求,我们都可以满足

运维:那也不行

我:为啥

运维:我没有那么多时间。一次部署要涉及370多台机器。原来三个月上线一次,每次前前后后要折腾两天。现在每两周上线一次,我还哪里有时间去干其它业务线的活啊?

怎么解决?

改变部署方式,让他的工作生活美好起来吧~~~~~

  • 部署流水线的建立,要求一键部署
    • 运维人员负责编写部署脚本,并做版本管理。
    • 开发人员在开发自测时使用同样的脚本。
    • 测试人员在测试环境上使用同样的脚本。
    • 运维人员在生产环境上也使用同样的脚本。

如果想了解更多,我的“持续交付”微信公众号上对这个案例进行连载分析。感兴趣就来我的Chat交流吧。

善意的提醒

强烈建议大家仔细研读《持续交付》,尽管这是一个大部头著作,而没有代码,少量插图,也没有什么工具使用说明。

我正在写一本关于持续交付案例解读相关的书,希望能帮助大家。书中很多内容是我在实际工作里如何运用书中的理论和原则,做出我认为适当的选择(比如上例中的不做单元测试),帮助团队解决实际问题。


原文地址:《持续交付和DevOps的前世今生

时间: 2024-10-05 21:38:53

[转载]持续交付和DevOps的前世今生的相关文章

基于Jenkins,docker实现自动化部署(持续交付)

前言 随着业务的增长,需求也开始增多,每个需求的大小,开发周期,发布时间都不一致.基于微服务的系统架构,功能的叠加,对应的服务的数量也在增加,大小功能的快速迭代,更加要求部署的快速化,智能化.因此,传统的人工部署已经心有余而力不足.持续集成,持续部署,持续交互对于微服务开发来说,是提高团队整体效率不可或缺的一环.合理的使用CI,CD能够极大的提高了生产效率,也提高了产品的交互质量.本文不对三个概念做过多的介绍,有兴趣可以读读这篇文章:The Product Managers' Guide to

基于Jenkins的持续交付全流程设计与实践

1 从理论开始 什么是DevOps? 近年来,随着DevOps理念的逐渐深入人心,企业逐渐意识到从看似重复的手工劳动中实现自动化流程处理,对于提高企业劳动生产力已经非常重要,尤其是面向互联网的开发者,往往每次上线时,最大的挑战并非需求的走查或测试和改bug,而是由于发布的流程不够规范,将成果发布到目标环境后可能造成的配置错误或引发其他已知未知问题所造成的额外工作量,使得生产环境的发布流程总会存在不顺利. 而DevOps则致力于统一整合软件开发和软件运维,其特点是强烈倡导对构建软件的所有环节(从集

你的DevOps中有完善的持续交付体系么?

背景: DevOps已经成为软件开发领域一个炙手可热的名词.敏捷开发.持续交付.CI/CD,K8s-这些主流的开发理念.工具无一例外都与DevOps有着很强的联系.这种环境影响下,传统的运维团队均开始向DevOps进行转型.一时之间运维开发.SRE.工程效能工程师需求量大增,无论公司大小,都会开始着手DevOps的从0到1的建设.我们开始搭建工具链.部署流水线.集成自动化测试工具.开发自动化发布系统--一切的一切都是为了完善我们自动化体系,从而提高开发效率,优化产品质量.那么问题来了,你团队所建

基于容器的持续交付管道

基于容器的持续交付管道 在过去的几篇d4d系列中,我给大家介绍了如何使用docker来支持asp.net core的应用开发,打包的场景.Asp.net core的跨平台开发能力为.net开发人员提供了使用容器进行应用开发的能力,今天这篇文章将对如何使用微软的全生命周期管理平台VSTS/TFS来构建基于容器的CI/CD管道来支持团队开发的场景. #1 前世今生 & 世界你好#2 容器化主机#3 在macOS上使用Visual Studio Code和Docker开发asp.net core和my

[持续交付实践] 基于 sonarqube 的代码检查平台实现

前言 公司此前用的一直是的SonarQube5.1(2015年版本,为兼容jdk6和jdk7的项目一直没有升级),最近为了pipeline的集成刚刚升级到了最新的SonarQube6.5版本.网上对SonarQube6的介绍比较少,这里重点先介绍下SonarQube6以后的一些新增特性.1.代码问题重新分级,将问题分为bug.漏洞.坏味道:将代码检查结果从可靠性.安全性.可维护性几个角度进行问题分类和风险分级.2.更丰富的代码检查规则,更友好的问题处理曲线展示,更清晰的质量阈和代码规则定制.3.

运维与持续交付

在互联网的产品开发时代,产品迭代越来越频繁,"从功能开发完成直到成功部署"这一阶段被称为软件开发"最后一公里". 对于持续部署,@湾区日报 这样评论: 一个团队工程技术水平高低,直接反映在部署代码上.我碰到其他公司的人,都喜欢问你们怎么部署代码的,非常大开眼界.你很难相信,很多(有一定规模的)公司仍然是人肉 SSH 到十几.二十台机器上 git pull.手动重启服务器,部署一次代码几个小时 -- 这么原始,活该加班:) 持续部署(continuous deploy

云端基于Docker的微服务与持续交付实践

云端基于Docker的微服务与持续交付实践笔记,是基于易立老师在阿里巴巴首届在线技术峰会上<云端基于Docker的微服务与持续交付实践>总结而出的. 本次主要讲了什么? Docker Swarm Docker Swarm mode 微服务支持(Docker集群架构体系) Docker的发展趋势和前沿成果 在Docker技术方面还是很佩服大牛的,所以赶紧写下笔记,追随大神的脚步. 阿里云资深专家易立,技术就不说了,他比其他直播间硬生生多讲了半个多点,于情于理还是万分感谢本次分享的(可惜devOp

Microsoft将持续交付功能添加到Visual Studio、Azure

Microsoft正在向Visual Studio 2017 IDE中添加持续交付功能. Visual Studio扩展的持续交付工具允许开发人员在Visual Studio团队服务ALM平台上设置自动构建.测试和发布管道.它适用于面向Azure应用服务和Azure容器服务的ASP.Net 4和ASP.Net Core应用程序.开发人员可以通过IDE中的通知来监视管道,提醒他们连续集成运行中发生的生成失败信息. 该功能的目的是使开发人员能够自动保持最新的管道.开发人员可以通过Visual Stu

持续交付的Mesos与Docker导入篇

变革这个词在当今的数字化时代司空见惯,IT技术每过一段时间就会有一起革新,从WEB2.0.虚拟化.云计算.大数据.微架构.DevOps再到今天的容器Docker与Mesos. Docker的出现方便了应用的测试.部署.与升级,其将各种应用程序和它们所依赖的运行环境打包成标准的Container/Image,进而发布到不同的平台上运行.Docker的轻量级.快速部署.迁移方便的特性促进了DevOps的落地,借用容器,开发人员可以很方便的融入到产品的交付流程当中. Mesos是软件定义数据中心的最佳