【DevOps】DevOps如何落地实施（一）

参考资料一、落实敏捷流程

1、找到合适的试点项目2、应对多变的业务3、真正意义上的“干掉变化” 二、使用精益看板三、做好配置管理

1、版本变更标准化2、将一切纳入版本控制3、全流程可追溯4、单一可信数据源 四、分支管理策略五、持续集成
《DevOps如何落地实施》一共两篇笔记：

【DevOps】DevOps如何落地实施（一）
【DevOps】DevOps如何落地实施（二）

《DevOps实战笔记》 极客时间，石雪峰

贴近核心业务倾向敏捷业务改进意愿优先 2、应对多变的业务

开发更少的功能，聚焦用户价值，持续快速验证。

不是使用了一些敏捷工具，团队就成了敏捷开发模式

双周迭代。每日站会。站会意义是做到风险点上报和预测，商量具体的对策。不是“工作汇报”需求拆分。 二、使用精益看板

很多人使用Jira看板，原因就是可以更加直观的观测到每一个需求的当前进度。这就是一个典型的可视化板。

看板系统不是可视化系统，看板系统应满足

第一步：可视化流程。泳道可以极大提高效率。
第二步：定义清晰的规则

卡片的颜色表示什么状态？卡片内容需要哪些关键信息？
谁来负责整理和移动卡片？
什么时间点进行卡片操作？
卡片的操作步骤是怎样的？（比如，卡片每停留一天需要做一次标记。）
什么时候需要线下沟通？（比如缺陷和阻塞）
哪些标识代表当前最高优先级的任务？
看板卡片的填充规则是怎样的？
谁来保障线下和线上看板的状态一致性？

第三步：限制在制品（需求）数量。

也就是每一个泳道中的卡片数量需要有一定的把控和维持

第四步：管理工作流程

每日站会：待交付的任务。紧急、阻塞&长期没有移动的任务问题排查队列填充会议：目标有两点，一个是对任务的优先级进行排序，一个是展示需求开发的状态。

第五步：建立反馈和持续改进

没有天然完美的解决方案，只有持续优化的解决方案。

【引用】一个完整的提交记录应该至少包括以下几个方面的内容：

提交概要信息：简明扼要地用一句话说明这个改动实现了哪些功能，修复了哪些问题；提交详细信息：详细说明改动的细节和改动方式，是否有潜在的风险和遗留问题等；提交关联需求：是哪次变更导致的这次提交修改，还需要添加上游系统编号以关联提交和原始变更。

可以说，标准化是自动化的前提，自动化又是 DevOps 最核心的实践。

“一切都需要！”比如软件源代码、配置文件、测试编译脚本、流水线配置、环境配置、数据库变更等等，你能想到的一切，皆有版本，皆要被纳入管控。

【引用】对传统行业来说，全流程可追溯的能力从来不是可选项，而是必选项。像航空航天、企业制造、金融行业等，对变更的管控都是非常严谨的，一旦出现问题，就要追溯当时的全部数据，像软件源代码、测试报告、运行环境等等。如果由于缺乏管理，难以提供证据证明基于当时的客观情况已经做了充分的验证，就会面临巨额的罚款和赔偿，这可不是闹着玩的事情。像最近流行的区块链技术，除了发币以外，最典型的场景也是全流程可追溯。所以说，技术可以日新月异，但很多理念都是长久不变的。

针对任意一个需求，你们是否能够快速识别出它所关联的代码、版本、测试案例、上线记录、缺陷信息、用户反馈信息和上线监控数据呢？

对于任意一个应用，是否可以识别出它所依赖的环境，中间件，上下游存在调用关系的系统、服务和数据呢？

【引用】有一个网络热词叫作“官宣”，也就是官方宣布的意思。一般情况下，官宣的信息都是板上钉钉的，可信度非常高。可问题是，如果有多个官宣的渠道，信息还都不一样，你怎么知道要相信哪一个呢？这就是单一可信数据源的意义。

对于代码来说，要有统一的版本控制系统，不能代码满天飞；对于版本来说，要有统一的渠道，不能让人随便本地打个包就传到线上去了；对于开发依赖的组件来说，要有统一的源头，不能让来路不明的组件直接集成到系统中。

这不仅对于安全管控来说至关重要，对于企业内部的信息一致性也是不可或缺的。

没什么可说的，尽可能单独模块分支单独管理。
主线分支由专人管理。

传送门：【DevOps】Jenkins+Git+Gitlab+Sonar+Nexus实现持续集成
成功的 持续集成 应解决下述的三个问题：

每一次代码提交，是否都会触发一次完整的流水线？每次流水线是否会触发自动化的测试环节？如果流水线出现了问题，是否能够在 10 分钟之内修复？

持续集成并非单独包括将分支的代码拉取，打包进行部署，也需要同时触发一系列自动化的测试工程的执行。

执行的结果第一时间里也需要进行反馈和维护。