软件工程诞生以来所历经的三个重要发展阶段
瀑布式开发模式
缺陷：需要在一开始就确定软件开发的目的，但往往因为需求变更，导致项目延期交付。
敏捷式开发模式
将大目标不断拆解，小步快跑进行迭代
Devops模式
devops是为了打破开发和运维之间的隔阂
传统模式，度量开发团队效率途径是看开发完成了多少需求，可以新功能却可能只是在堆砌，没有可测试，可运维性。
对于运维团队，考核指标确实系统的安全性，可用性，稳定性。
作者给出的定义：
DevOps 是通过平台（Platform）、流程（Process）和人（People）的有机整合，以 C（协作）A（自动化）L（精益）M（度量）S（共享）文化为指引，旨在建立一种可以快速交付价值并且具有持续改进能力的现代化 IT 组织。
Devops的价值？
高效率和高质量。
软件交付的效率和质量成了当今企业的核心价值和核心竞争力，
DevOps 的 4 个结果指标。
部署频率：指应用和服务向生产环境部署代码的频率。
变更前置时间：指代码从提交到成功运行在生产环境的时长。
服务恢复时间：指线上应用和服务出现故障到恢复运行的时长。
变更失败率：指应用和服务在生产环境部署失败或者部署后导致服务降级的比例。
这四个指标，能衡量高效能团队和低效能团队的差距，
四项结果指标，分别代表了软件交付的两个最重要的方面，也就是交付效率和交付质量
DevOps 本身也包含了改善软件从业人员的生存状态，提升他们的幸福水平的理念。
实施 DevOps，一方面可以通过种种流程优化和自动化能力，改善软件开发团队的工作节奏，另一方面，也可以让大家关注同一个目标，彼此信任，高效协作，调动员工的积极性和创新能力，从而让整个团队进入一种积极创造价值的状态，而这所带来的影响远非建设一两个工具平台可比拟的。
devops落地很难。
高效率和高质量是 DevOps 的核心价值，而工具和自动化就是提升效率最直接的手段，让一切都自动化可以说是 DevOps 的行为准则。
改变行为最关键的，就是要建立一种有效的机制 。机制就是人们愿意做，而且做了有好处的事情。
DevOps 的 3 个支柱
人（People）、流程（Process）和平台（Platform）
只有通过人、流程和平台的有机结合，在文化、工具和人员培训赋能领域共同推进，才能实现 DevOps 的真正落地实施。
《跨越鸿沟》，这本书中提出了一个“技术采纳生命周期定律”
这 5 个阶段分别对应一类特殊人群，即创新者、早期使用者、早期大众、晚期大众和落后者。
DevOps 能力成熟度模型
部署引力图
企业应用 DevOps 能力模型和框架的步骤和原则。
1)识别差距 对比能力成熟度模型和框架，识别出企业的不足。找到问题点。
2）锚定目标 找出影响当前交付效率的最大瓶颈，痛点。
3）关注能力 导入与能力想匹配的实践
4）持续改进
“DevOps 三步工作法”
第一步：流动。通过工作可视化，限制在制品数量，并注入一系列的工程实践，从而加速从开发到运营的流动过程，实现低风险的发布。
第二步：反馈。通过注入流动各个过程的反馈能力，使缺陷在第一时间被发现，用户和运营数据第一时间展示，从而提升组织的响应能力。
第三步：持续学习和试验。没有任何文化和流程是天生完美的，通过团队激励学习分享，将持续改进注入日常工作，使组织不断进步。
VSM是什么？
VSM 是 Value Stream Mapping 的缩写，也就是我们常说的价值流图
在需求提出后，怎么一步步地加工原材料，进行层层的质量检查，最终将产品交付给用户的过程。通过观察完整流程中各个环节的流动效率和交付质量，识别不合理的、低效率的环节，进行优化，从而实现整体效率的提升。
VSM的关键要素
前置时间（Lead Time，简称 LT）。前置时间在 DevOps 中是一项非常重要的指标。具体来说，它是指一个需求从提出（典型的就是创建一个需求任务）的时间点开始，一直到最终上线交付给用户为止的时间周期。这部分时间直接体现了软件开发团队的交付速率，并且可以用来计算交付吞吐量。DevOps 的核心使命之一就是优化这段时长。
增值活动时间和不增值活动时间（Value Added Time/Non-Value Added Time，简称 VAT/NVAT）。在精益思想中，最重要的就是消除浪费，也就是说最大化流程中那些增值活动的时长，降低不增值活动的时长。在软件开发行业中，典型的不增值活动有很多，比如无意义的会议、需求的反复变更、开发的缺陷流向下游带来的返工等。
完成度和准确度（% Complete/Accurate，简称 %C/A）。这个指标用来表明工作的质量，也就是有多少工作因为质量不符合要求而被下游打回。这里面蕴含了大量的沟通和返工成本，从精益的视角来看，也是一种浪费。
devops实行的两种轨迹
一种是自底向上，一种是自顶向下。
无论企业的 DevOps 转型采用哪条轨迹，寻求管理层的认可和支持都是一个必选项。如果没有管理层的支持，DevOps 转型之路将困难重重
devops转型通用路径
第 1 步：寻找合适的试点项目
第 2 步：寻找团队痛点
所谓痛点，就是当前最影响团队效率的事情，同时也是改进之后可以产生最大效益的事情。
第 3 步：快速建立初期成 最关键的就是识别一个改进点，定义一个目标
第 4 步：快速展示和持续改进 取得阶段性的成果之后，要及时向管理层汇报，并且在团队内部进行总结
在转型初期，建立一个专职的转型工作小组还是很有必要的.
转型小组团队成员示意图
向上沟通真是很重要的能力，上级是我们能利用到的最好的资源
作者回复: 没错，但是很多人都不会利用这个资源，我想这跟组织的文化关系很大，我在最早上班的时候是一家日企，第一天就给我们培训的菠菜文化，也就是报告，联络和相谈这三个词的缩写，有进展及时报告，有问题风险及时联络，有创意和想法及时相谈，这三点对我受益匪浅，推荐给你。
精益看板
把精益看板的实践方法分为了五个步骤。第一步：可视化流程；第二步：定义清晰的规则；第三步：限制在制品数量；第四步：管理工作流程；第五步：建立反馈和持续改进。
可视化流程：通过价值流分析将团队的交付路径可视化，建立起看板的主要结构，
看板的竖向队列，是按照价值流转的各个主要阶段进行划分的，比如常见的需求、开发、测试、发布等。对识别出来的每一列进一步可以划分成“进行中”和“已完成”两种状态
横向泳道，可以按照不同维度划分，如这里的常规任务和紧急任务。
（看板就属于devops实践啊）
DevOps 包含了大量的工程实践，很多我们都耳熟能详，比如持续集成、自动化测试、自动化部署等等，这些基本上是实践 DevOps 的必选项。
配置管理
四个核心理念：版本变更标准化，将一切纳入版本控制，全流程可追溯和单一可信数据源。
一套标准化的规则和行为习惯，可以降低协作过程中的沟通成本，一次性把事情做对，这也是标准和规范的重要意义。
连提交注释都要规定。
软件源代码、配置文件、测试编译脚本、流水线配置、环境配置、数据库变更等等，你能想到的一切，皆有版本，皆要被纳入管控。在你的公司里面，针对任意一个需求，你们是否能够快速识别出它所关联的代码、版本、测试案例、上线记录、缺陷信息、用户反馈信息和上线监控数据呢？对于任意一个应用，是否可以识别出它所依赖的环境，中间件，上下游存在调用关系的系统、服务和数据呢？
全流程可追溯：
变更的管控都是非常严谨的，一旦出现问题，就要追溯当时的全部数据，像软件源代码、测试报告、运行环境等等。
在你的公司里面，针对任意一个需求，你们是否能够快速识别出它所关联的代码、版本、测试案例、上线记录、缺陷信息、用户反馈信息和上线监控数据呢？对于任意一个应用，是否可以识别出它所依赖的环境，中间件，上下游存在调用关系的系统、服务和数据呢？
建议从需求入手。
单一可信数据源--必须要有统一的管控，这是一个理念，如对于代码来说，要有统一的版本控制系统，不能代码满天飞；
分支策略
不同的分支策略
（我们现在，主干开发，主干发布）
1、主干开发，分支发布
所有代码提交至主干分支，发布之前，基于主干拉出一条以发布为目的的短分支
分支存在时间不会太长，主要是bugfix（需要同步至主干），不包括新功能。
优点：发布分支以版本号命名，如果线上哪个版本有问题，就在哪个分支上修复。
缺陷：对主干质量要求高，团队协作节奏要求高，会导致两个分支提交不同步。
2、分支开发，主干发布。
分支一般是某个特性开发分支。
3、主干开发，主干发布
对每一次提交代码质量要求高，可以加自动化验收手段，代码评审等。
fackbook最新分支策略：
为了保证主干分支的质量，自动化验收手段是必不可少的，因此，每一次代码提交都会触发完整的编译构建、单元测试、代码扫描、自动化测试等过程。在代码合入主干后，会进行按需发布，先是发布到内部环境，也就是只有 Facebook 的员工才能看到这个版本，如果发现问题就立刻修复，如果没有问题，再进一步开放发布给 2% 的线上生产用户，同时自动化检测线上的反馈数据。直到确认一切正常，才会对所有用户开放。最后，通过分支策略和发布策略的整合，注入自动化质量验收和线上数据反馈能力，最终将发布频率从固定的每天 2 次，提升到每天多次，甚至实现了按需发布的模式
不同类型、规模、行业的软件项目采用的分支策略不同。
作者建议的是主干开发+特性分支的模式。
建议遵循原则：团队共享一条主干分支；特性分支的存活周期要尽量短，最好不要超过 3 天；每天向主干合并一次代码，如果特性分支存在超过 1 天，那么每天都要同步主干代码；谨慎使用功能开关等技术手段，保持代码干净和历史清晰；并行分支越少越好，如果可能的话，尽量采用主干发布。
是否需要发布分支，需要却取决于项目的发布模式666。
持续集成
CI 本身源于肯特·贝克（Kent Beck）在 1996 年提出的极限编程方法（ExtremeProgramming，简称 XP）。顾名思义，极限编程是一种软件开发方法，作为敏捷开发的方法之一，目的在于通过缩短开发周期，提高发布频率来提升软件质量，改善用户需求响应速度。
CI 是一种软件开发实践，团队成员频繁地将他们的 工作成果集成到一起（通常每人每天至少提交一次，这样每天就会有多次集成），并且在每次提交后，自动触发运行一次包含自动化验证集的构建任务，以便尽早地发现集成问题。
（像我们这种不用编译的，提交就是集成了）
CI的三个阶段
1）每次提交触发完整流水线---快速集成
每次变更都触发CI，这个变更，包括配置，环境，数据。
对于不同分支策略，采用不同的集成规则。
CI要有足够快的反馈周期，不要超过10分钟还没有反馈结果。
2）每次流水线触发自动化测试。---质量内建
不同层级的CI匹配不同的测试活动
（CI还有分层级的，提交集CI不适合运行过于复杂的测试活动，快速的代码检查和冒烟测试即可。
系统层的集成来说，可以加入接口和UI测试）
3）出了问题可以快速修复--文化建立
要有规则机制，如果出现问题，采取什么措施。
