文章目录
《DevOps如何落地实施》一共两篇笔记：
【DevOps】DevOps如何落地实施（一）
【DevOps】DevOps如何落地实施（二）
参考资料
一、落实敏捷流程
1、找到合适的试点项目
- 贴近核心业务
- 倾向敏捷业务
- 改进意愿优先
2、应对多变的业务
开发更少的功能，聚焦用户价值，持续快速验证。
3、真正意义上的“干掉变化”
不是使用了一些敏捷工具，团队就成了敏捷开发模式
- 双周迭代。
- 每日站会。站会意义是做到风险点上报和预测，商量具体的对策。不是“工作汇报”
- 需求拆分。
二、使用精益看板
很多人使用Jira看板，原因就是可以更加直观的观测到每一个需求的当前进度。这就是一个典型的可视化板。
看板系统不是可视化系统，看板系统应满足
- 第一步：可视化流程。泳道可以极大提高效率。
- 第二步：定义清晰的规则
卡片的颜色表示什么状态？卡片内容需要哪些关键信息？
谁来负责整理和移动卡片？
什么时间点进行卡片操作？
卡片的操作步骤是怎样的？（比如，卡片每停留一天需要做一次标记。）
什么时候需要线下沟通？（比如缺陷和阻塞）
哪些标识代表当前最高优先级的任务？
看板卡片的填充规则是怎样的？
谁来保障线下和线上看板的状态一致性？
- 第三步：限制在制品（需求）数量。
也就是每一个泳道中的卡片数量需要有一定的把控和维持
- 第四步：管理工作流程
- 每日站会：待交付的任务。紧急、阻塞&长期没有移动的任务问题排查
- 队列填充会议：目标有两点，一个是对任务的优先级进行排序，一个是展示需求开发的状态。
- 第五步：建立反馈和持续改进
没有天然完美的解决方案，只有持续优化的解决方案。
三、做好配置管理
1、版本变更标准化
【引用】一个完整的提交记录应该至少包括以下几个方面的内容：
- 提交概要信息：简明扼要地用一句话说明这个改动实现了哪些功能，修复了哪些问题；
- 提交详细信息：详细说明改动的细节和改动方式，是否有潜在的风险和遗留问题等；
- 提交关联需求：是哪次变更导致的这次提交修改，还需要添加上游系统编号以关联提交和原始变更。
可以说，标准化是自动化的前提，自动化又是 DevOps 最核心的实践。
2、将一切纳入版本控制
“一切都需要！”比如软件源代码、配置文件、测试编译脚本、流水线配置、环境配置、数据库变更等等，你能想到的一切，皆有版本，皆要被纳入管控。
3、全流程可追溯
【引用】对传统行业来说，全流程可追溯的能力从来不是可选项，而是必选项。像航空航天、企业制造、金融行业等，对变更的管控都是非常严谨的，一旦出现问题，就要追溯当时的全部数据，像软件源代码、测试报告、运行环境等等。如果由于缺乏管理，难以提供证据证明基于当时的客观情况已经做了充分的验证，就会面临巨额的罚款和赔偿，这可不是闹着玩的事情。像最近流行的区块链技术，除了发币以外，最典型的场景也是全流程可追溯。所以说，技术可以日新月异，但很多理念都是长久不变的。
针对任意一个需求，你们是否能够快速识别出它所关联的代码、版本、测试案例、上线记录、缺陷信息、用户反馈信息和上线监控数据呢？
对于任意一个应用，是否可以识别出它所依赖的环境，中间件，上下游存在调用关系的系统、服务和数据呢？
4、单一可信数据源
【引用】有一个网络热词叫作“官宣”，也就是官方宣布的意思。一般情况下，官宣的信息都是板上钉钉的，可信度非常高。可问题是，如果有多个官宣的渠道，信息还都不一样，你怎么知道要相信哪一个呢？这就是单一可信数据源的意义。
- 对于代码来说，要有统一的版本控制系统，不能代码满天飞；
- 对于版本来说，要有统一的渠道，不能让人随便本地打个包就传到线上去了；
- 对于开发依赖的组件来说，要有统一的源头，不能让来路不明的组件直接集成到系统中。
这不仅对于安全管控来说至关重要，对于企业内部的信息一致性也是不可或缺的。
四、分支管理策略
没什么可说的，尽可能单独模块分支单独管理。
主线分支由专人管理。
五、持续集成
传送门：【DevOps】Jenkins+Git+Gitlab+Sonar+Nexus实现持续集成
成功的 持续集成 应解决下述的三个问题：
- 每一次代码提交，是否都会触发一次完整的流水线？
- 每次流水线是否会触发自动化的测试环节？
- 如果流水线出现了问题，是否能够在 10 分钟之内修复？
持续集成并非单独包括将分支的代码拉取，打包进行部署，也需要同时触发一系列自动化的测试工程的执行。
执行的结果第一时间里也需要进行反馈和维护。