专栏名称: 运维帮
互联网技术分享平台,分享的力量。帮主一直坚信技术可以改变世界,从毕业到现在干了15年运维,有许多话要和你说。
目录
相关文章推荐
运维  ·  再见,CDN 巨头:Akamai 宣布 ... ·  3 天前  
51好读  ›  专栏  ›  运维帮

跳出运维看运维:持续性交付,就是提升整个研发体系效率的关键

运维帮  · 公众号  · 运维  · 2018-05-23 09:38

正文

作者介绍:赵成, 美丽联合集团技术服务经理, 《进化:运维技术变革与实践探索》作者,《赵成的运维体系管理课》专栏出品人,公众 号“Forrest随想录”作者,多届ArchSummit运维专题明星讲师和优秀出品人,TGO会员,目前专注于云计算和人工智能时代的运维转型和提升。


为什么需要持续交付?


持续交付覆盖了应用的整个生命周期,涉及产品、开发、测试、运维以及项目管理等相关方面。从生命周期出发,自然就会牵出整个自动化的全貌,就会有从全局着眼的规划设计,这时无论是在开发还是运维过程中存在的问题,都会完完整整地暴露出来。


那么,应该以什么样的主线开展?各方应该如何配合?应该以怎样的优先级明确任务?这些问题就都清楚了。同时,也避免了各个环节只把注意力放在各自职责范围内的事情上,而忽略了整体的配合。所以,做好持续交付,对于整个研发体系意义重大。


持续交付代表着从业务需求开始到交付上线之后的端到端的过程。同时,还要有一些非常关键的准备工作,主要包括: 配置管理、需求拆解、提交管理、构建打包、自动化测试以及部署发布。


 

配置管理


配置管理是持续交付的第一关键点。 讲持续交付,一上来就先讲配置管理,主要还是想强调: 配置管理是基础,是关键 。我们后面将要讲的每一个持续交付环节,都对配置管理有很强的依赖。这个基础工作做不好,也就谈不上的持续交付的成功。


按照持续交付的理念,这里所说的配置管理范围会更广,主要有以下几个部分。


1.版本控制


版本控制的主要作用是保证团队在交付软件的过程中能够高效协作,版本控制提供了一种保障机制。


2.依赖配置


这里以Java为例,我们使用Java进行开发,必然会依赖各种第三方的开源软件包。同时,内部还会有不同组件的二方包。这些三方包和二方包就是一个应用编译和运行时所依赖的部分。


对于Java来说,我们熟知的依赖管理工具有Ant、Maven和Gradle。


3.软件配置


这里我把软件配置细化为两类: 一类是代码配置,一类是应用配置


代码配置是跟代码运行时的业务逻辑相关的 。比如应用的服务接口、并发线程数、超时时间等这些运行时参数;还有类似于业务或技术上的开关,比如商品评论是否开放、优惠时间段设置等等。


应用配置就是 应用这个对象的属性和关系信息


从区别上讲,我们可以认为代码配置是跟业务或代码逻辑相关的,动一下就会改变系统执行状态,是运行时的配置,但不依赖周边环境。而应用配置,是跟业务和代码逻辑无关的,不管你怎么动,业务逻辑是不会改变的,但是它跟环境相关。


4.环境配置


环境配置管理,就是不同环境中的应用配置管理。环境配置是我们在持续交付过程中要关注的重中之重,也是最为复杂的一部分。


 

多环境配置管理


环境配置管理主要是针对应用对基础设施和基础服务依赖关系的配置管理。


我们通过一个简化了的场景来做示例,讨论环境配置管理的解决方案。


假设现在有三个环境:

  • 开发环境

  • 预发环境

  • 线上环境

继续假设某应用有配置文件:config.properties,里面存储了跟环境相关的配置,简化配置如下:

  • 缓存地址:cache.app.url

  • 消息地址:message.app.url

  • 数据库地址:db.app.url

  • 支付调用地址:pay.url

  • 支付调用Token:pay.app.token

这里,我提供三 个解决思路。


  • 方案一,多个配置文件,构建时替换。

  • 方案二,占位符(PlaceHolder)模板模式。

  • 方案三,AutoConfig方案。

 


线下多环境建设


线下环境最初建设的时候,主要是提供给测试使用,帮助其建立一个模拟环境,在软件发布上线前进行需求功能验证,保障业务流程顺畅,以确保应用在上线前达到最低质量要求。


一般来说,我们在线下环境区域内,建设三套环境。


1.集成测试环境


主要供测试使用,这个环境会最大程度与线上版本保持同步。作为对应用的功能、需求、业务流程等在正式发布上线进行验证的主要环境,集成测试环境的稳定性和可测试需要加强保障,进行全套建设。同时,作为整个线下环境的中心节点,也要为开发测试环境和项目环境提供部分依赖服务。


2.开发测试环境


主要供开发人员使用,针对偏日常的需求开发、联调和功能验证,以最小化原则进行建设,但是一般情况下不对资源进行回收。


3.项目环境


供开发和测试共同使用,针对多团队多人员协作的项目型场景,可以同时存在多个项目环境,在这个环境中针对项目需求进行独立开发、联调和验证。测试也需要提前介入这个环境进行基本功能的验收,并遵循最小化的建设原则,但是要有生命周期,即项目启动时分配资源,项目结束回收资源,不能无限期占用。


 


线上环境建设


线上环境建设主要包括 生产环境 Beta环境 预发环境 办公网生产环境 这四种。我们简单构建一张模型图来对线上环境作个展示:


 

 


持续交付中的流水线模式


从一个应用的代码提交开始,到发布线上的主要环节,整个流程串起来就是一个简化的流水线模式。如下图所示:


 


1.项目需求分解


比较通用的做法,就是要求业务架构师在做需求分析和功能设计时,要针对一个需求进行拆分,最终拆分成一个个的功能点,这些功能点最终落实到一个个对应的应用中,对应的逻辑体现就是应用代码的一个分支。


2.开发模式选择原则


一看这几种模式的适用场景;

二看我们实际的使用场景是怎么样的。


 


持续交付流水线软件构建


我们以Java为例,来介绍构建环节。


构建过程中我们要用到以下4种工具:

  • Gitlab,代码管理工具,也是版本管理工具;

  • Maven,依赖管理和自动化构建工具,业界同类型的工具还有Gradle等;

  • Docker,用来提供一个干净独立的编译环境;

  • 自动化脚本和平台,自动化构建的任务我们使用Python脚本来实现代码获取、编译执行、软件包生成等。

具体整个构建过程图示如下:


 









请到「今天看啥」查看全文