一、软件开发流程的演变
二、传统瀑布模型
1.瀑布模型特点
软件开发的各项活动严格按照线性方式进行
当前活动接受上一项活动的工作结果
当前活动的工作结果需要进行验证
2.瀑布模型优缺点
优点
开发的各个阶段比较清晰
强调早期计划及需求调查
适合需求稳定的产品开发
缺点
由于开发模型是线性的，增加了开发的风险
早期的错误可能要等到开发后期的阶段才能发现
三、敏捷开发模型
（一）XP - 极限编程（开发测试的要求很高，才能实施）
1.编程方法维度：简单设计、结对编程、测试驱动开发、重构
简单设计：只要满足用户当下的需求，不需要太过高深完美的设计，
结对编程：两个人一起编程。同事A关注代码的细节，同事B关注整体的结构，且同事B对同事A进行代码的评审
测试驱动开发：先写好测试用例代码，再编写程序代码，使程序代码在测试代码里测试通过
重构：在“简单设计”上的优化。减少重复部分，增加可服用部分
2.小组实践维度：代码集体所有、编码标准、稳定高速的步伐、隐喻、持续集成
代码集体所有：所有人都可以访问修改代码
持续集成：“集成”的意思是指把多个人的代码合在一起。每次集成都需要进行一个自动化的构建来进行验证，其中包含自动化的测试（构建：把当前阶段的代码变成一个用户可使用的产品，如用户可安装的app文件）
隐喻：以一个比喻的手法形象的描述需求，尽可能让团队的每个人都听懂。
3.交付和管理维度：小规模发布、计划游戏、完整的团队、现场客户
小规模发布：一般1~3周（最常见的是2周）发布一个用户可以使用的版本
计划游戏：计划现在要做哪些工作，之后要做哪些工作
完整的团队、现场客户：开发和客户占据主要地位，测试主要通过自动化来实现
（二）SCRUM
SPRINT：冲刺，一个迭代的周期，一般为2~4周（2周最常见），期间会进行每日站会
产品BACKLOG：以列表的形式展示项目所有需求的概要，并按照优先级排序
SPRINT计划会议：计划实现哪些优先级最高的需求
SPRINT BACKLOG：最后决定的这个迭代里要实现的需求
潜在可交付产品增量：一个迭代完成了，会提交出一个完成了在这个迭代里需要完成的需求的产品，即包含了此次迭代的需求增量
注：
1.在每一次迭代周期结束后，还会有一个SPRINT评审会议，该会议展示此次迭代完成的功能
2.在评审会议之后，在下一个SPRINT计划会议之前，还会再开一个SPRINT的回顾会议，对一整个迭代周期去进行复盘，哪些地方执行的好，哪些地方执行的不好，后面如何改进
3.第1个迭代周期的测试阶段，可能会与第2个迭代周期的需求分析阶段重合
（三）敏捷模型总结
增量迭代
小步快跑（一般2周一个迭代）
四、DevOps开发模型
开发、测试、运维需要紧密的合作，才能真正的做到DevOps
1.DevOps 生命周期
持续开发
持续测试
持续集成
持续部署
持续监控
2.DevOps 对发布的影响
减少变更范围
加强发布协调
自动化
3.CI/CD
持续集成（Continuous integration，缩写为CI）是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。
持续交付（Continuous delivery，缩写为 CD），是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以发布的状况。它的目标在于让软件的构建、测试与发布变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。
4.CD 与 DevOps 的关系
DevOps的范围更广，是软件交付过程所涉及的多个团队之间的合作，并且将软件交付的过程自动化。
持续交付是一种自动化交付的手段，关注点在于将不同的过程集中起来，并且更快、更频繁地执行这些过程。
DevOps可以是持续交付下的一个产物，持续交付的成果直接汇入 DevOps模型。
