DevOps
什么是持续集成
持续集成 CI Continuous Integration
- 这里的集成主要指的是代码的集成，开发任务完成后，一次性提交自己本地代码到代码管理工具的主干代码上。这个过程就叫集成，也就是代码集成。缺点：集成过程中可能会产生冲突，代码量可能比较大，会花费非常多的时间、精力和成本，并且提高了发布风险。
- 持续集成。强调的是不再一次性把代码集成到主干，而是高频率的持续集成。一天集成1次，甚至多次。同时在集成过程中，进行自动化测试，保证主干代码一直可用。
主流的持续集成工具
- Jenkins
根据规则轮询代码管理工具，获取最新代码（也可以手动或设置其他规则）
基于不同的语言进行构建（需要自行配置）
通过 FTP 把构建后的内容自动上传到对应的服务器
使用插件或者脚本，将发布包内容更新到各个环境
通过命令行调用自动化测试脚本，搭配代码覆盖率工具执行自动化测试
展示自动化测试报告，并邮件通知构建情况
持续交付
持续集成包含了构建与自动化测试的阶段，而持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的“类生产环境”之中
可以看到，与 持续集成 相比较，持续交付 添加了 Test -> Staging -> Production 的流程，也就是为新增的代码添加了一个保证： 确保新增的代码在生产环境中是可用的 。
在这一增加的流程中，Test 环节不仅仅包含基本的单元测试，还需要延伸到更为复杂的功能测试以及集成测试等。在这里，Staging 指的是 类生产环境 ，其尽可能的对真实的网络拓扑、数据库数据以及硬件设备等资源进行模拟，从而为测试人员反馈代码在生成环境中的可能表现。流程中每一个环节的执行结果都会对开发人员进行反馈，每一个出现的错误都会导致版本的回滚。当测试完毕确认无误之后，将由相关人员对其进行 手动部署到生产环境。
持续部署
意味着：通过自动化部署的手段将软件功能频繁的进行交付。
与持续交付以及持续集成相比，持续部署强调了通过 automated deployment 的手段，对新的软件功能进行集成。
可以看到，同 持续交付 相比 持续集成 的区别体现在对 Production 的自动化。从开发人员提交代码到编译、测试、部署的全流程不需要人工的干预，完全通过自动化的方式执行。这一策略加快了代码提交到功能上线的速度，保证新的功能能够第一时间部署到生产环境并被使用。
DevOps
是一组完整的实践，可以自动化软件开发和 IT 团队之间的流程，以便他们可以更快、更可靠地构建、测试和发布软件。
Kubernetes 构建完整的 DevOps 流水线
敏捷开发
敏捷开发的核心是 迭代 开发。迭***将一个大任务，分解成多次连续的开发，本质就是逐步改进。所谓"增量开发"，指的是软件的每个版本，都会新增一个用户可以感知的完整功能。也就是说，按照新增功能来划分迭代。增量开发加上迭***，才算真正的敏捷开发。
迭***一般会有以下步骤：
1.需求分析（requirements analysis）
2.设计（design）
3.编码（coding）
4.测试（testing）
5.部署和评估（deployment / evaluation）