07.持续交付流水线与敏捷开发笔记

-------------------------------------------------------------------------------------

什么是软件的生产制造过程:

 07.持续交付流水线与敏捷开发笔记_第1张图片

 

 

 

管理属性过程:建立“规划版本”的管理能力,完整跟踪做什么,怎么做,进展如何

工程属性过程:建立“交付版本”的管理能力,完整跟中谁在做,如何实现,在哪里,质量怎样。

 07.持续交付流水线与敏捷开发笔记_第2张图片

 

 

创造性过程:想法逐渐明确,知道开发人员开始编写代码,所有的需求都是假设。编码之前的过程都是不可重复的探索过程。

重复性过程:将已经实现的代码推送到用户面前,一旦代码编写完毕,后续的过程都是可重复的。

编写代码:把想法变成实际可以运行的软件功能。

 07.持续交付流水线与敏捷开发笔记_第3张图片

 

 

 

编码是个分水岭

编码前——创造性过程

所有的需求都是假设

采用不确定性思维知道的协作工作模式:影响地图,故事地图,Scrum和看板等

编码——将创意转换成代码

创意被固化——但仅仅在非常短的实践内

编码后——重复性过程

标准化不是解决方案:任何一行代码的改动都会造成固化CI/CD流水线的崩溃

Everything as code才是解决思路

CI/CD流水线上的所有配置,编排,逻辑均通过代码库进行控制

Pipeline as Code

Configuration as Code

Infrastructure as Code

------------------------------------------------------------------------

 07.持续交付流水线与敏捷开发笔记_第4张图片

 

 

迭代单元的大小决定了整体效率

 07.持续交付流水线与敏捷开发笔记_第5张图片

 

 07.持续交付流水线与敏捷开发笔记_第6张图片

 

 

 

 

 

*好处:

更小的迭代单元意味着更少的代码量,更少的缺陷,更快的构建和更简单的部署

如果做错了,你也将付出更少的机会成本

*挑战:

更小的迭代单元意味着更加频繁的CI/CD触发,更加频繁的部署动作

对环境获取能力的要求也随之提高

任何手工的配置向管理都将变成恶梦

 

什么才是最小的迭代单元?*怎样完成需求拆分?*多大的粒度才是适合我的团队的?

小到不能再小

怎样的粒度才能再少,用户无法体验到所交付的价值,任务切换开始成为团队哦工作的障碍或者瓶颈

 

-----------------------------------------------------------------------------

流水线对关键敏捷实践的支撑

01.特性分支,主干发布模式

l  分支上工作的团队规模不能超过20人,符合Scrum中对于团队大小的定义

l  特性分支上完成完整的开发、测试、验证过程,符合跨职能团队的工作模式

l  按照用户故事微粒度拉去特性分支,符合敏捷中按故事进行交付,按故事微粒度拉去特性分支,符合敏捷中按故事进行交付,按故事组织开发,测试、验证过程的方式。

l  拉去请求:

n  协作式的代码评审机制帮助团队建立对代码的所有权共享

n  解决了按特性拉去分支后需要给每个分支创建CI/CD

n  解决了大量分支情况下容易产生冲突的问题

 07.持续交付流水线与敏捷开发笔记_第7张图片

 

 

 

02.大量采用自动化测试

l  从敏捷的角度来看,流水线的主要作用式给团队提供即使的反馈,在流水线中添加测试就是为了从不同的层面提供全面的质量反馈

l  当测试用例被大量自动化以后,开发和测试人员的技能将大量重合,驱动团队成为混合型团队类型

l  当团队开始逐步从UI测试,向API测试和单元测试倾斜中心的时候,开发和测试必须能够共享代码所有权。

l  最终的结果是“测试”变成开发人员的一项职责,而不再是一个职能。

 07.持续交付流水线与敏捷开发笔记_第8张图片

 

 

 

03.服务独立性和接口外露

为了能够支持按故事迭代和更快的反馈速度,产品脚骨开始从大而全向小而精的方向转变。这样可以允许更加独立的完成从设计,开发,测试,打包到上线的全过程。

为了支撑更加小而精的架构,每个服务的结构方式将百年等更加外露和明确,原先只是不同模块建的进程内调用,开始变成不同服务间的跨网络调用

推动每个服务提供更加规范的产品级接口,而不在是开发人员自行随意决定的内部接口,而不再是开发人员自行随意决定的内部接口

这种外露和明确的接口也将进一步盖上服务的可测性,推动自动化测试的推广

服务数量的增加造成了高度异构化的运维环境,急需引入容器花技术解决

 07.持续交付流水线与敏捷开发笔记_第9张图片

 

 

 

04.解耦部署和上线

l  改变只有从新部署才能上线新功能的限制,通过功能开关将代码通过流水线部署,然后通过关键控制功能的上线

l  通过灰度发布,AB测试解决“一切需求都是假设”的问题,通过真实用户的反馈来刷选出真正的需求,让奥基社变成现实。

l  不是和上线一旦解耦,开发人员将具备直接在生产环境运行测试的能力。

 07.持续交付流水线与敏捷开发笔记_第10张图片

 

    

 

05.基础设施即代码

l  随着迭代单元粒度的缩小和服务数量的增加,使用传统的“养宠物”方式来管理基础设施已经变得不可能,“养牛”的方式成为云时代的唯一路径。

l  跨职能的混合团队的边界从开发/测试延展至运维/运营,形成以产品/服务微服务模式的团队架构

l  进一步推动流水线本身的服务化,开始大量用Pipeline as Code的模式来管理流水线

l  DevOps工程师的职能也开始合并进入混合团队

 07.持续交付流水线与敏捷开发笔记_第11张图片

07.持续交付流水线与敏捷开发笔记_第12张图片

 

 07.持续交付流水线与敏捷开发笔记_第13张图片

 

 

--------------------------------------------------------------------------------------

研发效能提升的核心秘籍

 07.持续交付流水线与敏捷开发笔记_第14张图片

 

 

 

管理粒度:DevOps从管理角度的优化永远是在通过控制"管理单元"的粒度来完成的。所谓的"管理单元"可能是团队、需求,任务,测试,交付物等任何研发中的被管理对象。

研发效能提升:曲轮是敏捷,精益或持续交付,其最终目的都是为了提升效能。所谓“效能”,就是单位投入的产出量(效率)和组织实现目标的能力。

工程解耦:DevOps从技术角度的优化永远是在通过解除“工程对象”之间的耦合实现的。所谓“工程对象”坑你是系统,工具、代码、模块、服务、平台,云或者任何研发过程中存在或者交付的“技术对象”

 

你可能感兴趣的:(07.持续交付流水线与敏捷开发笔记)