软件概念：与计算机系统操作有关的计算机、可能有的文件、文档及数据
软件开发流程的演变：
传统瀑布模型 需求分析-设计-编码-实现-软件测试-完成-维护
软件开发的各项活动严格按照线性方式进行
当前活动接受上一项活动的工作结果
当前活动的工作结果需要进行验证
优点：开发的各个阶段比较清晰-管理人员好把控
强调早期计划及需求调查-防止需求变更需要不断重新流转
适合需求稳定的产品开发-比较适合需求稳定的产品
缺点：由于开发模型是线性，增加了开发风险-失去了及早修正错误的最佳机会
早期的错误可能要等到开发后期的阶段才能发现-修复只有到了测试阶段才会发现问题，修改的成本就会变高
敏捷开发模型 XP&SCRUM
XP-极限编程
编程方法 简单设计-用简单的办法实现更小需求，后期在不断调整优化
结对编程-一个人考虑代码细节编程，另一个人关注整体节奏不断对代码进行评审
测试驱动开发-先编写测试用例，然后根据用例去编写代码，提高代码质量
重构-减少程序出现重复的部分，增强程序的可复用性
小组实践 代码集体所有-每个人都可以改代码
编码标准-实现上一步的前提之一
稳定高速的步伐-长期稳定的开发
持续集成-持续把大家的代码合并到一起，需要自动化的构建（构建是把代码转换成app的过程）
隐喻-把实际项目比喻成一个形象的例子方便大家理解
支付和管理 小规模发布-1~3周迭代，方便总结
计划游戏-根据小规模发布去计划现在和后期要做的事情
完整的团队-共同去工作
现场客户-主要围绕客户进行工作
SCRUM 产品BACKLOG-管理所有产品需求，按照商业价值对需求进行排序
SPRINT计划会议-从产品BACKLOG挑选下一个周期具体要做哪些需求
SPRINT BACKLOG-SPRINT计划会议的产物 下一个迭代周期要做的产物
SPRINT2-4周-期间举行每日站会检查目标进展，方便调整工作和优化
SPRINT结束后生成一个可交付产品增量
下一个SPRINT计划开始前会开一个SPIRINT维护会议-对整个迭代周期进行一个复盘
每一个SPRINT中都是一个小的瀑布模型，第一个SPRINT模型没结束，可能第二个SPRINT也已经开始，如此循环，直到产品BACKLOG没需求
敏捷模型总结 增量迭代 小步快跑-把所有功能列出来排列优先级，优先开发优先级高的部分，然后不断完善小需求
DevOps 持续开发-开发人员不断开发新功能上传到git仓库中，使用一些工具把代码打包到可执行文件中去
持续测试-结合测试框架使用自动化测试工具持续对开发软件进行测试
持续集成-测试通过后持续将新代码跟现有代码进行合并
持续部署-持续保持测试环境一致；并将测试通过的代码持续部署上线
持续监控-通过线上监控提供软件质量，监管软件性能
DevOps 减少变更范围-每一个迭代周期变更的功能很少，对生产系统产生的影响很少
加强发布协调-通过自动化减少沟通成本
自动化-减少部署出错的情况
- 持续集成（Continuous integration，缩写为CI）是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。
- 持续交付（Continuous delivery，缩写为 CD），是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以发布的状况。它的目标在于让软件的构建、测试与发布变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。
CD与DevOps的关系 - DevOps的范围更广，是软件交付过程所涉及的多个团队之间的合作，并且将软件交付的过程自动化。
- 持续交付是一种自动化交付的手段，关注点在于将不同的过程集中起来，并且更快、更频繁地执行这些过程。
- DevOps可以是持续交付下的一个产物，持续交付的成果直接汇入 DevOps模型。