为团队构建DevOps体系

栏目: 编程工具 · 发布时间: 6年前

内容简介:在开发过程中,如果团队没有基本的DevOps体系来保证应用的稳定,便捷的自动部署,规范的部署流程,优良的开发环境,那么除了开发效率很可能是极为底下之外,团队成员也怕是会怨声载道,更别提应用的健壮性了。DevOps的定义众说纷纭,个人的理解是:

在开发过程中,如果团队没有基本的DevOps体系来保证应用的稳定,便捷的自动部署,规范的部署流程,优良的开发环境,那么除了开发效率很可能是极为底下之外,团队成员也怕是会怨声载道,更别提应用的健壮性了。

DevOps是什么

DevOps的定义众说纷纭,个人的理解是:

  • 从狭义上来说是一套实践、方法、工具,是提高交付应用程序和服务能力的一组最佳实践,为了在保证高质量的前提下缩短系统变更从提交到部署至生产环境的时间。
  • 从广义上来说是一个运动,一种文化,强调团队紧密合作,打破角色之间的隔阂从而达到提高最终交付价值。

为什么要构建DevOps体系

为团队构建DevOps体系

所以,我们需要:

  • 将应用部署的流程自动化起来,只需要按一个按钮就能完成在任意环境上的部署
  • 将开发、测试、部署环境统一起来并管理起来
  • 缩短从代码提交到部署到生产环境之间的时间
  • 将所有过程可视化起来,让所有人知道当前的进展
  • 将异常及时反馈给负责人并有回滚方式

DevOps体系的思路与实践

思路:以提升开发部署效率这个结果为导向,以标准化、自动化、可视化为思想,以持续集成、持续交付、敏捷为核心来构建一套DevOps体系。

自动化流水线

优先级:高

通过使用自动化流水线构建 工具 将代码的构建、测试、部署的流程规范起来,将执行的操作固定下来,去除人为因素干扰构建流程,从代码的提交到部署形成一条生产线。

前置条件:

  • 分支策略。流水线的构建方式是通过分支策略来定的,如果有master、dev、release分支,则可能需要构建出三套流水线来分别管理这三个分支
  • 提交策略。不论是否使用持续集成的方式提交,提交的信息必须统一,提交者的姓名、提交所属的功能、提交的内容这三块内容必须要有
  • 部署步骤。确定需要部署到哪些环境中,有几个构建的步骤,如test、build、deployDev、deployTest、deployProd
  • 多项目的结构。一个项目需要是一个能让git单独追踪的项目,才能避免在自动化中影响其他项目的构建

准备好前置条件之后就可以开始构建第一条流水线了,具体的构建工具与构建步骤因团队而异,具体构建的过程就是将所有当前的部署流程整理进构建流水线中,并使用类似Jenkinsfile这样的Pipieline as code的形式将流水线当做整个项目的一部分管理起来,因此这是工作量最大的部分。构建完成后还需要完成流水线可视化,在团队工作区域的显眼位置放置一台显示器,将当前所有流水线的工作状态显示在上面。

各种环境的管理

优先级:高

  • 统一开发、测试、部署的环境。生产环境是什么样子,测试环境与开发环境就尽量保持一致。应用的架构方式、应用运行所在的系统版本、应用运行所在的机器配置都应当保持一致,使用 Docker 可以保证后两者没有问题,但架构方式在开发环境难以做到,优先级其实不高,可以暂时放下。
  • 使用到的虚拟机需要使用Ansible将构建虚拟机上各种工具、环境的过程代码化,也为日后再多个虚拟机上批量执行命令提供方便。
  • 依赖包的管理。Java非常方便,可以自己部署一个配置管理源,所有包都从这个源里下载,但 Go 不太方便,可以使用vender将项目依赖的特定版本的代码管理起来,但是会碰到被墙导致无法下载的问题,目前的方式是将项目的依赖提取到一个公共代码库中,然后将公共代码库放到GOPATH中,如果有一些依赖不适合放入公共代码库,则提交到项目根目录下的vendor中。

团队协作的纪律

优先级:中

  • 提交规范。根据分支策略拟定提交规范,主要是小步多次提交、提交信息要全面。
  • 快速反馈。在任何工作的过程中,如果觉得哪里不太高效或者有问题,需要及时提出反馈共同优化现状,被动收集反馈。
  • 长期反馈。定期召集团队成员举办retro,主动收集改进意见。
  • 高优先级修复问题。一旦流水线或监控或日志有异常,需要及时通知相关人员修复。

监控日志规范化

优先级:中

监控:对于应用、数据库、虚拟机都应当有一套监控方式,一旦某个运行节点出现异常则需要通过一些方式通知相关人员

日志:将所有应用的日志在容器内是收集,并上传到一个日志中心,并提供方便的查询工具便于全部人员查询

构建过程文档化

优先级:中(长期、穿插)

前置条件:

  • 建立文档中心。TAPD、Gitbook。

在构建DevOps体系的过程中,将构建的过程文档化,将已有的开发、部署步骤、系统架构文档化也是必不可少的一环,让日后其他同事能够接收DevOps体系和已有的系统架构。

所以在构建DevOps体系的过程中,文档化是穿插在各个地方的,每当完成一个任务就需要抽点时间补充一下文档。

部署结果可视化

优先级:低

  • 流水线可视化。流水线构建完成后,将所有流水线的状态用可视化工具与机器在团队内部展现出来。
  • 运维面板可视化。在测试、生产环境部署完成且监控系统到位之后,将运维面板通过可视化工具展现出来,可以实时观察当前系统运行状态。
  • DevOps构建过程可视化。使用看板的方式将DevOps体系构建过程管理起来,先维护好TAPD电子看板,需要的话再加上物理看板。看板的资料可以查看这里

落地计划

以上的实践可以说是需要落地的具体事情,把这些事情落地成功也需要一些方法。

遵循渐进式的实施顺序:

  1. 以任意一个项目为例,将整个DevOps体系实践根据优先级落实其中,当做一个示例规范化整个体系
  2. 将已有的混乱开发部署方式以第一个项目为例逐步迁移到我们搭建的架构中来
  3. 基本完成之后回过头来重新审视一遍已有的体系,继续改进

在实施的过程中的建议:

  1. 使用看板与迭代开发的方式将我们的实施任务分配清楚,计划制定成熟
  2. 在过程中将DevOps体系当前构建进展同步给所有人,将所有人的意识规范起来
  3. 让你的老大与团队其他成员意识到构建DevOps体系的必要性,为长期发展做好铺垫
  4. 整个过程中最大的难点可能是已有的体系也比较庞大与混乱导致迁移难度大从而需要大量时间,所以必要的时候向你的老大申请更多时间与人员来

以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

松本行弘的程式世界

松本行弘的程式世界

松本行弘 / 鄧瑋敦 / 博碩 / 2010年07月27日

讓Ruby之父教您大師級的程式思考術! 本書以松本行弘先生對程式本質的深層認知、各種技術之優缺點的掌握,闡述Ruby這套程式語言的設計理念,並由此延伸讓您一窺程式設計的奧妙之處。本書內含許多以Ruby、Lisp、Smalltalk、Erlang、JavaScript等動態語言所寫成的範例,從動態語言、函數式程式設計等領域開展您的學習視野。 本書精華: ‧物件導向與抽象化 ‧......一起来看看 《松本行弘的程式世界》 这本书的介绍吧!

JS 压缩/解压工具
JS 压缩/解压工具

在线压缩/解压 JS 代码

RGB转16进制工具
RGB转16进制工具

RGB HEX 互转工具

UNIX 时间戳转换
UNIX 时间戳转换

UNIX 时间戳转换