我们离DevOps有多远--持续集成思想的延伸

  1. 云栖社区>
  2. 博客>
  3. 正文

我们离DevOps有多远--持续集成思想的延伸

技术小美 2017-11-14 16:48:00 浏览1240
展开阅读全文

Wikipedia对DevOps的定义是:

  DevOps是软件开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程、方法和体系的一个集合。 它是人们为了及时生产软件产品或服务,以满足某个业务目标,对开发与运维之间相互依存关系的一种新的理解。 ...... DevOps并不仅仅关注软件部署,它是部门间沟通协作的一组流程和方法。

 

持续集成思想

  怎样才能达到这样一种状态呢,我们先放一下,看看持续集成(Continuous Integration)体现出来的一些思想。

纵览全局(打破职责界限)

  rd,qa,op,如果仅仅按照这样的角色标签去处理事情,那就和圣经里的巴别塔一样,大家不说同一种语言怎么能劲往一处使呢。

  我们把目标放得更远一些,不再为了赶代码而将质量保障交给qa和op,不是为了增加测出bug的数量而和rd争论,不是为了减少变更而是积极的适应变更,我们共同的目标是实现商业目的,确保软件质量(也包括变更质量和运行质量)也是其中的一部分。频繁的变更不是质量的杀手,而应该在软件开发整个流程多个环节进行质量的保障,并频繁的运行这些保障。

  这种方法就打破了目前的rd->qa->op流水线的流程,而是将三者紧密的结合在一起。从实践的结果来看,rd每次提交代码都会触发一系列的自动化步骤,包括编译,单元测试,代码覆盖率,功能测试,部署测试,性能/容量测试(注:后两者受限与时间要求,实际实施不会每次提交代码都触发)。Rd,qa,op都在过程中做质量保障。

   是努力减少变化还是在变化发生时做好准备。一定是后者,因为当一件事情频繁发生时,问题才会大量的暴露。解决暴露出来的问题才能促进业务更好的发展,也是对团队能力的提升。

  拿一个的实际例子,部署测试(Deploy check)和性能/容量测试(capacity test),我们比QA有更多的资源和条件,那么我们就应该主动承担起这份工作,然后将其加入到整条质量保障线的必要环节上。

 

 

浑然一体(而非七零八落)

  代码树被管理起来——主干开发

  主干开发的好处是每个rd都知晓整体的变更,所有的feature作为一个整体发布,对OP的现实意义就是上线变得更有规律,非计划的、临时的上线最后消失。

  代码和周边(配置,数据,构建脚本,单元测试,测试用例)统一作为产品被管理起来——一键式产构建,测试,部署,完成产品的最终发布。

SVN结构样例

module

|--product

|----code

|----bin

|----scm_product.conf(描述程序地址)

|----module_control

|----conf

|----data

|----data_description(描述数据存放地址)

|----ci-script

|----test_case

|----build_script

|----test_script

|----deploy_script

|--development

|--test

  好处易见,生成一个完整的产品的所有原料都被管理起来,上线仅需要一个版本号,不会出现上线时冗长的步骤,做版本diff,部署环境diff,测试case diff都非常简单。而且,环境的备份也变得简单和纯粹了。

  研发(开发,测试,发布,部署)全过程被管理起来。所有角色在一个界面下工作,使用共同的平台,统一的源码管理,共享。

  大家都在一个平台上工作,所有的任务都在这个平台下,各角色间对互相的工作有更深入的了解,并且,工作状态也可以共享。

 

 

少就是多,简洁就是美(用简单的方法解决问题)
持续集成的解决方案是简洁的。产品由SVN去管理,构建过程由CI server负责,而构建过程包含了编译,测试,发布,部署过程

 

  没有封闭的系统,没有蹩脚的流程,配合开放的系统(Code Review/wiki)所有的信息被自然的整合在一起。而一切都是以提高变更速度,提高产品质量为目标。

  当解决方案让你觉得不自然(或有很多内容无法囊括,或需要人为干预)的时候,那这个方案就不是一个完美的方案,必定在某一些方面受到了限制,这些限制有可能是历史造成的。要勇于质疑,扩展角度,提升高度。去掉角色的限制,站在产品的角度去思考,对于整体的优化的解决方案就产生了。

 

 

 

以终为始(一直以发布级的质量要求产品)

  写代码都是为了要发布的,也就是需要上线使用的,那在开始编码就以产品的质量要求代码,要求check in的代码就是能够完成编译的,具备一定功能并且可以部署的产品。

  将质量内建于产品中。每次代码的提交都会经历单元,功能,部署,性能/容量测试。在上线前我们就能够知道是否能成功部署,线上的服务器是否能撑住。这样的产品在上线时我们就不会有那么大的压力了,OP也不需要担心回滚的风险了,即使回滚,那么回滚也是one step。小菜一碟。

 

 

 

我们与DevOps的距离

  那么我们离DevOps有多远呢。从各个公司放出来的技术资料(flickr最全面),最经典的是flickr的10+ deploys per day,他们的最佳实践有以下几点,而起穿针引线作用的是持续集成(技术上)和思考方式(文化上)。

 

Culture:

1.respect

2.trust

3.healthy attitude about failure

4.avoiding blame

  从文化上,我们需要一种氛围,不仅仅把自己看作rd,qa,op这样的角色,哪里有质量缺口,我们就要把它补起来;哪里有不通畅的地方,我们就要把它疏通。RD了解op的部署方式,能够获取OP提供的监控指标;OP也了解RD的开发方法,开发流程,所面对的问题。放开自己的眼界,从更高的视角看待和解决问题。

 

Tools:

1.Automated infrastructure(自动化,系统之间可集成)

2.shared version control(SVN共享源码)

3.one step build and deploy(持续构建和部署)

4.feature flags(公司内部称为single branch,主干开发)

5.Shared metrics

6.IRC and IM robots(信息整合)

 

  技术上的这些要点被3(持续集成/部署)一线贯穿。

  4点(主干开发)是持续集成的前提

  1点(自动化),2点(代码及周边集中管理)是实施持续集成的必要条件

  5点是1的一部分(图表是由自动化系统产生的)

  可见,技术上的核心是持续集成/部署

  5所提到的有较高的技术要求。要求我们将业务/运维上的指标变得可测量,直至可预测。这里面的两个核心技术内容就是:

  容量测量(Capacity management)

  容量的变化体现在用户行为(流量)系统变更(软件性能)和资源(服务器数量,冗余度计划)等几个因素的变化上,将容量和这些变化挂钩,在每一个因素变化下重新得到系统的容量,从而在变更中控制容量不足造成的风险。有一个要点,我们需要的是系统的容量而不是单个模块的性能。

  质量反馈(Quality feedback)

  变更会导致质量变化,而质量变化体现在各种指标上,而测量这些指标(包括应用指标:平响,处理效率等和系统指标:负载,网络流量),发现指标之间的规律,将指标share给整个团队,从而有效的达成质量的反馈,控制变更(包括内部变更和外部条件的变化)造成的质量下降的风险。本质上说,容量测量也是质量反馈的一部分。

  在实施持续集成的过程中,并行实施的三个项目:

  持续部署/一键式部署(continuous deployment/one step deploy),

  容量测试/管理(Capacity Test/Management)

  质量反馈(Quality feedback)

  分别对应于上面三个要点,共同支撑系统的高速迭代,减少系统频繁变更引发的风险。

  借助于持续集成,我们在实践中向DevOps迈进了一大步,离业界的最佳实践已不远。dev和ops说着同一种语言,共同为业务发展和质量保障做出贡献。

  敏捷/精益开发方法可以提高应变业务变化的能力,并内建质量。DevOps把开发和运维的沟壑抹平。那么我们的development和ITIL就能够结合到一起了。

 

 

  我们曾经愿景将服务器放到机架上,一键就能完成服务上线,我们已经有了一个好的开始,这个目标就会实现。

 

 

 

【本文首发于:百度运维空间http://hi.baidu.com/ops_bd/blog/item/74d7710916d8aafe37d1225a.html
关注百度技术沙龙










本文转自百度技术51CTO博客,原文链接:http://blog.51cto.com/baidutech/748587,如需转载请自行联系原作者

网友评论

登录后评论
0/500
评论
技术小美
+ 关注