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

运维 系统运维
DevOps并不仅仅关注软件部署,它是部门间沟通协作的一组流程和方法。怎样才能达到这样一种状态呢?我们离DevOps有多远?看看持续集成(Continuous Integration)体现出来的一些思想。

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结构样例

  1. module 
  2. |--product 
  3. |----code 
  4. |----bin 
  5. |----scm_product.conf(描述程序地址) 
  6. |----module_control 
  7. |----conf 
  8. |----data 
  9. |----data_description(描述数据存放地址) 
  10. |----ci-script  
  11. |----test_case  
  12. |----build_script  
  13. |----test_script  
  14. |----deploy_script  
  15. |--development  
  16. |--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就能够结合到一起了。

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

责任编辑:黄丹 来源: 百度运维空间
相关推荐

2011-12-30 09:22:40

2011-07-21 08:53:42

HTML 5

2015-11-30 11:02:00

5G通信技术

2020-06-23 10:41:08

云计算DevOps持续集成

2015-07-22 17:23:08

融资互联网泡沫大数据

2017-04-18 12:30:16

新能源汽车智能汽车车联网

2017-04-28 08:57:58

持续集成DevOpsC#

2021-10-13 22:41:24

人工智能数据信息技术

2016-08-05 17:19:37

持续集成持续交付系统运维

2017-02-27 18:35:23

集成交付部署

2023-03-02 10:31:01

6G

2023-03-19 11:47:57

Taro小程序持续集

2017-10-19 09:47:55

容器化微服务集成

2011-12-16 16:32:11

百兆宽带

2016-07-01 15:47:02

华为

2021-03-25 20:23:09

人工智能AI肺结核

2020-10-15 08:58:38

人工智能机器学习技术

2018-08-30 10:14:20

代码开发机器

2018-02-24 17:13:51

2021-03-31 09:00:00

管道集成工具
点赞
收藏

51CTO技术栈公众号