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

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

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

 

 

 

 

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

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

 

 

 

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

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

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

 

 

 

 

编码是个分水岭

l  编码前——创造性过程

n  所有的需求都是假设

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

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

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

l  编码后——重复性过程

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

n  Everything as code才是解决思路

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

u  Pipeline as Code

u  Configuration as Code

u  Infrastructure as Code

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

 

 

 

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

 

 

 

 

 

 

 

 

*好处：

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

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

*挑战：

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

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

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

 

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

l  小到不能再小

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

 

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

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

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

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

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

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

l  拉去请求：

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

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

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

 

 

 

 

02.大量采用自动化测试

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

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

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

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

 

 

 

 

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

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

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

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

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

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

 

 

 

 

04.解耦部署和上线

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

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

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

 

 

  　　

 

05.基础设施即代码

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

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

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

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

 

 

 

 

 

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

研发效能提升的核心秘籍

 

 

 

 

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

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

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