精选 | DevOps 三十六计之精益敏捷与持续交付

前言:

一册在手,DevOps我有”,这就是传说中的《DevOps 三十六计》,相信您读完也意犹未尽,小编就来和您说道说道我注解的《DevOps 三十六计》,今天先跟大家聊聊精益敏捷和持续交付,从中摘取何勉、杨晓俊、张乐三位老师的计策,跟聊聊您!

精益敏捷篇

精益产品开发(何勉)

  1. 寻求在问题域将需求拆分成可流动和交付的子需求,避免过早在实现域拆分任务 我们做产品研发时,最容易犯的错误就是需求还没有理解透彻就开始思考实现,具体怎么在问题域将需求拆分,需要你系统的阅读何老师的新书《精益产品开发 原则、方法与实施》。
  2. 系统组织拆分后的需求。用户故事地图是组织和规划需求的好工具 用户故事以用户的角度描述需求,替代原来的功能性描述,增加团队对用户、对价值的关注和理解。但是用户故事对于优先级、故事场景(线索)的体现并不好,所以发展出用户故事地图这样的实践与工具,帮助我们梳理将用户故事变成一本精彩的“小说”!
  1. 可视化价值流动而非任务,以促进团队协作,并系统改进价值交付过程 何老师将精益看板划分为三个层次:任务状态看板、价值流动看板、持续改进看板。看板最基础的价值就是满足我们可视化工作流的需求,然后看板要能帮助团队明确流程规则和限制在制品数量,这样的看板才算是真正的看板。 在何老师的实践中,看板还需要追求更高级的目标:管理价值流动和帮助持续改进。
  1. 控制在制品,减少同一时刻并行需求的数量,以加速价值交付,并暴露瓶颈和问题 控制在制品,这是大多数实践看板的团队所面临的最大难关。既要转变工作不饱和的恐慌思维,又要切实控制住WIP。

PS,何老师出新书了,《精益产品开发 原则、方法与实施》不只有36条计策,更多精彩尽在其中

敏捷项目管理(杨晓俊)

  1. 没有照本宣科的敏捷,只有最适合团队的实践 敏捷的本质就是在实践中探寻更好的软件开发方法,所以实践敏捷需要我们去找到最适合自己的实践和方法。
  1. 好的架构是演化出来的,而不是一开始就设计出来的 这个在传统瀑布模式下最常见,总是花好几周的时间设计架构,考虑各自高可用、安全等场景,可惜往往很多项目都没有熬到上线就胎死腹中。架构师演化出来的,这是敏捷研发中的铁律。
  2. 需求卡(Story Card)最好能够写明目标用户、用户的场景以及用户的目的或需求本质 需求卡片,以用户故事的表达方式,清晰的告诉所有人团队成员(产品、开发、测试,甚至业务运维)需求的内容是什么。同时在需求卡片上写清楚验收条件也是非常好的实践。

持续交付篇

持续集成(张乐)

  1. 开发人员每天至少向版本库提交一次代码 在Martin Fowler的持续集成测试中,第一条就是“开发人员每天至少向版本库提交一次代码”。

只有开发人员每天至少向版本库(主干)提交一次,才能避免出现复杂的合并与集成,主干的质量才能持续得到保障

  1. 每次变更都执行构建,以便尽早发现缺陷 持续集成解释就是持续地集成(构建),何为持续?原来我们都是DailyBuild,每天做一次。现在随着技术的发展,架构的解耦。每一次提交(变更)都能进行构建,这样才能保证代码始终处在可构建的状态。 这里的构建至少包含了编译、单元测试。
  2. 将DDL和DML脚本提交到版本库,以便使用脚本重建数据库和测试数据 数据库的持续集成一直都是难题,使用版本控制系统管理DDL和DML是第一步,这样才能建立起应用和数据的版本关系,可以自动完成数据库重建和测试数据的生成。 尤其是在搭建测试环境中,数据库搭建和数据导入往往需要花费测试工程师很多时间,自动化该过程并纳入到持续集成(持续交付)流程中,是非常好的实践

持续部署(张乐)

  1. 避免手工部署软件
  2. 避免手工对生产环境进行配置 手工部署软件和手工配置生产环境是持续交付的典型反模式。这里可以尝试使用两个实践:基础设施即代码和不可变基础设施。 基础设施即代码,在大家使用类似Ansible等自动化配置(部署)工具时将环境的配置(状态)都采用代码(比如YAML)的方式进行定义,由于自动化配置工具幂等性的特点,可以保障环境的状态和我们定义的状态保持一致。 不可变基础设施,主要是在使用Docker时,不允许修改容器配置,每次部署都是重新启一个新容器。环境只可以被替换,不可以被修改,这和虚拟机的使用有很大的不同。
  3. 避免开发完成之后才向类生产环境部署 相信你已经听过或者说过:“在我机器上没问题啊,是你环境的问题吧!”,将DTAP环境(开发、测试、预发布、生产环境)都纳入到持续交付流程,才能保证代码能尽快在类生产环境中进行部署和验证,软件要运行,需要应用、应用配置、数据、环境及配置等都正确,尽快在类生产环境进行验证可以有效避免环境差异的问题。
  4. 交付过程是每个程序员的责任 DevOps非常强调文化和协作,在DevOps的文化模型中,责任共担是核心文化,交付过程是每个开发工程师、测试工程师、运维工程师的共同责任。

DevOps 三十六计除了精益敏捷和持续交付,还有安全篇、性能调优篇、开发架构篇、测试技术篇、技术运营篇,每一篇又分多个计策! 欲知详情,且听下回分解!

END

原文发布于微信公众号 - DevOps时代(DevOpsTimes)

原文发表时间:2017-08-16

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏即时通讯技术

新手入门:零基础理解大型分布式架构的演进历史、技术原理、最佳实践

随着社会的发展、互联网技术的进步,以前的大型机服务端架构很显然由于高成本、难维护等原因渐渐地变得不再那么主流了,替代它的就是当下最火的互联网分布式架构。

1224
来自专栏织云平台团队的专栏

新时代运维监控能力的进化——天网云用户体验监控平台实践

运维团队审视业务质量监控能力时,有九个问题值得思考,九问运维后,我们重新审视传统的运维监控能力是否仍然能够满足业务对质量的要求,结合当下移动互联网与新兴的业务形...

9542
来自专栏灯塔大数据

干货|非常实用的10款网站数据实时分析工具

网络分析工具可以帮助你收集、预估和分析网站的访问记录,对于网站优化、市场研究来说,是个非常实用的工具。每一个网站开发者和所有者,想知道他的网站的完整的状态和访...

3057
来自专栏云计算D1net

云计算是什么?你现在需要知道的一切

公共云使客户无需投资新硬件或软件即可获得新功能。相反,他们向云计算提供商支付订阅费或仅为他们使用的资源付费。只需填写Web表单,用户就可以设置账户,并启动虚拟机...

1903
来自专栏达摩兵的技术空间

项目发布验收不严格带来思考

经常会遇到小公司的很多项目在测试环境针对测试数据库 草率的测试完之后就进行上线,然后生产环境暴露出大量问题,而且每个似乎都很严重需要马上纠正的问题。

1201
来自专栏程序员互动联盟

你是否有过代码写的太烂不敢开源的经历?

作为一个写了十几年代码的老司机,在入行不久会有这种心理,老是觉得自己写的代码见不得人,主要还是基础不牢固写出来的代码属于见光死的程度,从测试人员那边的感觉就能测...

1112
来自专栏云计算D1net

关于无服务器计算,您需要知道的10件事

如果您阅读了2017年有关于IT特别是云计算方面的各种预测,您很有可能碰到“无服务器计算”这一术语。早在2014年亚马逊的网络服务(AWS)已推出了第一大无服务...

3376
来自专栏网络

HTTPS环境DNS优化:美图App请求耗时节约近半案例

移动互联网时代,APP 厂商之间的竞争非常激烈,而良好的用户体验是必须优先考虑的,美图产品以高颜值著称,对产品的用户体验非常重视。从技术的角度来看,客户端的体验...

31210
来自专栏逸鹏说道

解析微服务架构(一):什么是微服务

解析微服务架构系列文章将分几篇描述微服务的定义、特点、应用场景、企业集成架构的演进以及微服务转型思路和技术决策考虑等内容,并以IBM技术为例介绍如何实现微服务架...

3154
来自专栏重庆的技术分享区

成功准备微服务的5个步骤

原文地址:https://medium.com/@kikchee/5-steps-to-successfully-prepare-for-microservic...

1202

扫码关注云+社区