BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

DevOps,不是一个传说!

| 作者 乔梁 关注 7 他的粉丝 发布于 2011年4月20日. 估计阅读时间: 12 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

DevOps最近成了热词,望文生义,你也能猜个八九不离十,它就是在说"研发团队"与"运维团队"之间的那点事儿。那么,到底什么是"DevOps"呢?

WikiPedia上说:"DevOps是软件开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程、方法和体系的一个集合。它是人们为了及时生产软件产品或服务,以满足某个业务目标,对开发与运维之间相互依存关系的一种新的理解。"这恰好体现了精益管理中的客户价值原则,即:以客户的观点来确定企业从设计到生产交付的全部过程,实现客户需求的最大满足。我们也可以把DevOps看作是一种能力,在缺乏这种能力的组织中,开发与运维之间存在着信息"鸿沟"。

如何获得这种能力呢?关键有两点:一是全局观:要从软件交付的全局出发,加强各角色之前的合作;二是自动化:人机交互就意味着手工操作,应选择那些支持脚本化、无需人机交互界面的强大管理工具,比如各种受版本控制的script,以及类似于Nagios这样的基础设施监控工具,类似于Puppet、Chef这样的基础设施配置管理工具。

有人评论说:"针对目前国内情况,DevOps还是很遥远。也许只有行业顶尖的公司,或者新成立的公司会有这样的尝试。大多数的企业还未开始进行敏捷的推进,传统的重重阻碍会使敏捷的推进进程遥遥无期。" DevOps真的离我们有那么远吗?DevOps应该从哪里开始呢?

一、让数据说话

让我们看一看百度某产品线在半年内的变化吧。首先要说明两个百度术语。"提测"是指某个项目开发完成后,在正式上线前,将其提交给测试组进行测试的活动。对于客户来说,"提测"这个动作本身并不增加什么价值,但也需要花费一定的时间。"上线"是指某个项目验证合格后,将其部署到服务器的过程,其中包括"上线申请"和"实际部署"两个活动。也许在各公司中对这两个活动叫法不同,但在软件生命周期中,"提测"、"上线"这两件事无论花长时间,大家可能都不会感到奇怪。下面两张图是该产品线进行改进之后的对比数据。

从图中不难看出,提测和上线部署的效率已大大提高。象百度这样的互联网企业,产品线多得数不清,几乎每个产品线每周都有新功能部署。仅从这两个数据来看,其收益可想而知。那么,半年前的状况是什么样的呢?

二、流程建模

既然DevOps关注于价值交付的全过程,那就让我们看看该产品线常见的交付过程吧。

对于单个项目来说,它大体上是一个典型的瀑布开发过程。首先是需求收集与整理,撰写MRD(Marketing Requirement Document)或总体设计后,进行评审。如果涉及到多模块,每个模块的开发人员会对各自负责的模块进行详细设计,给出大致的开发计划,并商定联调时间点。之后,开发人员会从主干上拉出项目分支,并在该分支上进行开发。当到最后联调点时,几个开发人员才会在将代码合在一起,进行联调。当调通之后,开发人员再申请提测。测试人员接到提测申请单后,进行测试,记录Bug,通知开发人员修复,直致质量达到标准。之后,开发人员会填写上线申请单,经运维人员确认后,运维人员操作进行上线部署工作。如图所示。

开发的复杂性还在于:该产品线有很多并行项目,为了避免互相干扰可能带来的冲突,每个项目启动后都会重新在主干上拉出分支,在上线前才进行合并。如下图所示。

另外,并行项目太多,导致每个开发人员会同时参与多个处于不同阶段的项目。那些周期较长的项目虽然会被分解成多个迭代,但每个迭代内都是同样的开发流程,只是最后仅有一次上线而已。

总而言之,突出的问题表现在:

  1. 同一角色多个人员的合作开发;
  2. 各角色部门之间的协作以各自的产品物为目标,如MRD、产品代码、测试用例、上线操作单;
  3. 基于人机交互方式的内部流程管理平台。

三、发现浪费

从精益思想出发,为了尽早交付价值,必须首先找出整个流程中的浪费,并将其消除,从而提高流程效率,让"一个想法从提出到实现"可在最短时间里完成。那么,浪费到底表现在哪里呢?

  • 一些不必要的多分支开发,合并后发生问题的风险高。多个项目中可能都要修改同一个模块的代码,每次在最后合并代码时都会出现一些问题,非常痛苦,尤其是修改比较大的时候,合并及修复时间较长。
  • 推迟问题被发现的时间。每个开发人员会将需求分解成多个技术任务后开发。所以,所有任务完成之前,应用程序一直处于不可用状态。当最后在一起联调时,常常会发现一些意想不到的问题。
  • 基于流程平台的沟通。在提测环节中,沟通完全基于内部项目管理平台和即时消息工具或Email。比如开发人员在提测前,需要在项目管理平台上申请该项目的4位版本。拿到4位版本后,才能提交平台统一编译。如果编译失败,那么问题解决后还要再次申请4维版本。如果成功,则在项目管理平台上填写表单,回答一系列的问题(比如,是否做过单测?测了哪些功能点?部署步骤是什么?),发起提测工作流,管理平台会自动发送电子邮件给相关测试人员,通知他们进行测试。测试人员收到该提测工作流后,必须在平台上进行相关确认操作,通知开发人员已收到该版本。如果测试人员对部署和测试内容有疑问的话,还会通过即时通讯工具或邮件与开发人员进行确认。
  • 常规的例行工作很难自动化。上线部署也需要通过内部平台来完成。开发人员拿到已测试通过的4位版本后,先要登录到内部平台,再提交上线申请单,填写上线步骤。当运维人员收到上线步骤后,再将其"翻译"成平台可以识别的"半自动上线步骤",再让平台来执行。如果运维人员不理解上线步骤,就要和开发人员通过电子邮件或即时通讯工作等进行反复确认。部署配置信息分散在各处。如下图所示:

另外,该产品的一个重要特征是需要不断地尝试调整程序算法策略,以得到最佳的流量效果,而这种调整的频率较高(至少每周一次)。当需要调整策略时,开发人员修改代码后重新进行编译打包,由于产品代码发生变化,所以测试人员仍需要进行大量的回归测试,而运维人员在部署时也需要将对二进制文件包进行整体部署,整个周期比较长。

从上面这些内容中,我们不难发现,流程中更倾向于将问题推迟到后面解决(比如最后集成联调),将工具(平台、邮件、即时通讯)作为协作的基础,而角色间的沟通几乎完全依赖于前一个环节的产物(比如MRD、产品代码、上线步骤)。那么我们使用哪些对策进行优化,达到消除浪费的目的呢?

四、应对措施

1. 无人工干预方式的脚本自动化

  • 自动化提测——由于已做到了每日集成,所以每天都有可测试的版本,开发人员不再需要为提测进行专门的准备工作,只要从成功构建的列表中选择一个给测试人员就可以了。使用Hudson平台后,通过插件即可调用自动化脚本,完成提测版本的标识。
  • 统一配置信息源——将所有的配置项全部放在Subversion库中进行版本控制;并根据应用环境的不同,分别保存在Dev,Test和Online三个目录中。

  • 常规流程脚本化——经过各角色的共同讨论和可行性分析,最后配置上线部署的实施方案是:由开发人员将产品二进制包与配置项进行剥离,这样仅做策略调整时,测试人员只要对已修改的配置项进行相关测试即可。运维人员用一系列的脚本代替了内部运维平台的手工上线操作,再通过Hudson平台的插件,以 "Click Button"的方式达到了一键式部署。

2. 尽早发现问题,解决问题

  • "需求细分,及时开发,及时验证"——将需求拆分成端到端可测试的需求(即"用户故事"),这些需求一般可在3天内完成。在实现每个需求之前,开发人员与测试人员进行充分沟通,对需求与验收条件达成共识。每开发完成一个用户故事,就进行测试,并用自动化测试进行覆盖。
  • "主干开发,分支提测"——将原来的多个分支进行合并,统一在主干上开发,每周结束时拉出一个分支,进行提测,一旦发现问题,就在主干上修复。
  • "持续集成"——为了确保每次提交质量,对主干开发建立持续集成环境,开发人员和自动化测试人员都严格遵守持续集成纪律"Check-in Dance"。

新的开发流程如下图所示。

分支开发策略变更为Single Branch模式。

五、小结

通过以上改进措施,让团队的合作方式发生了重大变化,从"碉堡防御"走向了"战线统一"。

原来,各角色仅关注于自己本身的工作,虽然大家都同处于一个项目中,但各自划分了"领地",产品经理就应该将MRD写得清清楚楚,如果开发人员认为不清楚,那就回去再改。开发人员只管按照MRD上的内容进行开发,很少考虑可测性和易测性问题。测试人员只管按照MRD中内容来测试,有问题通过内部工作流平台提交问题单。运维人员只管根据开发人员提交的上线操作单进行操作。似乎各角色之间的沟通介质只有各自的"交付物"。

现在,各角色都能够共同合作,以项目的最终交付为目标,积极讨论需求,优化实现。因为角色之间的这种紧密合作让所有人对不同角色都有了深入的了解。开发人员耐心为产品经理解释技术实现,说明计划安排,测试人员与开发人员共同讨论验收条件,避免遗漏需求。开发人员让运维人员了解架构设计, 细心听取运维人员的建议,进行技术改造,使部署工作更快捷有效。

通过这些活动,大家都认识到原有内部管理平台仅是个公文流转的支撑平台,要想提高工作效率,就要将这种"办公自动化工具"进一步提升为"全面自动化工具",使所有人更关注于端到端的价值,而非各角色之间的分界点。

六、结束语

百度刚刚开始敏捷之旅,还没人谈及"DevOps"运动,虽然还没有什么强大的工具支撑,但基于"提高效率"的朴素思想进行的过程改进也带来了"DevOps"效果。可见,DevOps听上去很神秘,但其实并不难。只要本着精益思想,聚焦于快速交付价值,不断发现并消除浪费,你也一定会有很大收获。


感谢熊节对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家加入到InfoQ中文站用户讨论组中与我们的编辑和其他读者朋友交流。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

最后一个图是rework里面的。 by fan tom

最后一个图是rework里面的。

会遇到的困难 by cao qinmiao

这是一种很好的工作融合的方式,在创业初期基本就是这种境况.
个人感觉会遇到的困难:
1.权力之争,将三个部门合并,那剩余的领导者去哪?
2.团队的考核,怎么样会是公平的?
3.当出现故障的时候,谁会是背责任的人?

Re: 最后一个图是rework里面的。 by 高 德翔

好眼力啊!

主干开发,分支提测 by li qingfeng

如果多个项目再进行,主干开发,分支提测。如何上线呢,
主干上线,无法保证主干的代码是测试过的,因为多个项目在修改。一个项目测试过了,但是其他项目没有测试完成。
分支上线,其实问题也是一样的,因为从主干拉出的分支,你无法保证主干的其他项目是稳定版本,所以这也是有风险的。

从你的图可以看出,没有考虑并行开发

有点baidu内部培训的味道 by Top Gun

要想确保“在实现每个需求之前,开发人员与测试人员进行充分沟通,对需求与验收条件达成共识。每开发完成一个用户故事,就进行测试,并用自动化测试进行覆盖。”--这需要耗费多少时间来统一认识呢?只要制定正确的版本控制流程,自动化提测不会比人工方式快多少,还不一定能处理所有情景。
感觉更重要的是提前制定各模块之间的接口,以及围绕这些接口进行的开发,这样将有效避免集成测试中的问题,这些问题也是后期发现最难处理的问题。

怎么感觉就是一个从瀑布模型到Scrum/CI的变化? by F Mic

怎么感觉就是一个从瀑布模型到Scrum/CI的变化?

Re: 有点baidu内部培训的味道 by 乔 梁

这需要耗费多少时间来统一认识呢?

没有共识,如何协作呢

Re: 怎么感觉就是一个从瀑布模型到Scrum/CI的变化? by 乔 梁

从瀑布模型到Scrum/CI的变化

的确做了这事.
另外,还做了开发团队与运维团队统一信息源.版本控制.

真正的产品化团队,不过感觉太理想化了 by chen chris

真正的产品化团队,不过感觉太理想化了,真正到执行层面会遇到很多阻力和压力,况且产品,开发,测试和运维的资源配比情况也很难满足这样的要求,大家可以YY一下。

Re: 真正的产品化团队,不过感觉太理想化了 by 段 永明

使用Hudson全部自动化,在Java这样的平台相对比较简单。在C C++这些需要配置不同编译环境的项目来说,难以很好的应付。

Re: 真正的产品化团队,不过感觉太理想化了 by 乔 梁

这个产品线就是c/c++。

另外,还有很多工具可以解决环境配置问题,如puppet/chef等等。

Re: 主干开发,分支提测 by lu lin

同问这个问题,如何解决的?

Re: 主干开发,分支提测 by zhu ao

他这个主干开发应该是只是做主干的简单维护工作。
并行项目是在分支上开发,然后周期性将主版本合并至分支中,最后由分支版本提交上线。

Re: 主干开发,分支提测 by 乔 梁

这个系统的所有开发都在主干上完成。在这种改进之前,原来用分支并行开发方式,每三个月才能上线一次,有一个分支甚至根本无法上线,最后不得不放弃。而这种改进之后,每两周上线一次。

标题党啊 by wu denzel

通篇讲的都是敏捷,持续集成。devops也就最后提到那么一点,也没说出个大概。

从架构看DevOps by soft wmz

要做到DevOps,其实采用微服务架构相当不错,在微服务架构中做得比较好的开源项目有JXADF,
详细访问:osgi.help

Re: 主干开发,分支提测 by 谷 锎

我认为@li qingfeng的问题不是你们取得的成果,而是这个通用技术套用到更常见的开发场景时遇到的问题。
1. 如果并行A/B的两个项目开发都在主分支上同时进行,那么是否会造成A的缺陷影响B当前的联调。换句话说B项目的联调必须祈祷A项目恰好达到一个可用的时间点上。

微服务确实更适用这种场景,那么但是再微服务也会有不同需求项目在一个服务中的场景。我能否这样理解这张图。

1. 每个小阶段拉分支进行提交(分支为小特性级别而非项目级别),提交的代码应当是可执行,不影响主体代码的。
2. 每次提交打一个tag,触发自动测试和自动部署。

Re: 主干开发,分支提测 by 乔 梁

正解~持续交付要求每次提交,如果没有完成,也不会影响线上版本。
困难是有的,但不是每个团队都不能实现,也不是每个团队都能实现。
一切由人和所在的场景决定。

Re: 主干开发,分支提测 by 乔 梁

提交的代码就是要达到生产环境的质量(虽然整体功能没有完成,但不影响用户体验)

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

19 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT