瀑布式开发
一个软件从零开始到最终交付，大致要经历：规划、编码、构建、测试、发布、部署和维护。最初程序简单的时候，程序员一人就能完成所有阶段的工作。而当软件产业不断发展，出现精细化分工，如开发、测试、运维等。于是由原先的程序员一人完成工作，转变成了传统的软件开发流程：
开发花费大量时间编写代码，然后把代码交给QA进行测试，再将最终的发布版本交给运维团队去部署。即开发 =>测试=>部署。这种早期采用的软件交付模型，被称为瀑布模型。简而言之，就是等一个阶段所有工作完成之后才进入下一个阶段，而当用户对系统的需求不断增加，给的时间周期越来越短的时候，瀑布式开发就显得笨重而又迟缓。
敏捷开发
敏捷开发是一种能应对快速变化需求的软件开发能力。简单来说，就是把大项目变成小项目，把大时间点变成小时间点。就像这样：
比较流行的案例是scrum、XP极限编程。在新迭代（一般2-6周）开始前，产品经理将需求拆分成具体的开发任务，研发人员进行任务认领，每日会进行任务的review，直至开发完成，发布新的可用版本。
虽然敏捷开发大幅提高了开发效率和版本更新速度，但是它的效果仅限于开发环节。在运维那边，依旧是铁板一块，成为新的瓶颈。运维的核心诉求就是稳定压倒一切，运维非常排斥改变（因为容易出问题），而敏捷开发就是不断改变的过程，这就造成了两者的矛盾。
DevOps
DevOps集文化理念、实践和工具于一身。可以提高组织交付应用程序和服务的能力。与使用传统软件和基础设施管理流程相比，能够帮助组织更快的发展和改进产品。这种速度使组织更好的服务其客户，并在市场上高效的参与竞争。
DevOps是一组过程、方法与系统的统称，用于促进开发、技术运营和质量保障部门（QA）之间的沟通、协作与整合。
DevOps = development + Operation，它就是让开发人员和运维人员更好的沟通合作，通过自动化流程来使得软件整体过程更加快捷可靠。在devops下，我们需要重新梳理全流程的规范和标准。
在这个流程下，运维人员会在项目开发期间就介入到开发过程中，了解开发人员使用的系统架构和技术路线，从而制定适当的运维方案。而开发人员也会在运维的初期参与到系统的部署中，并提供系统部署的优化建议。DevOps贯穿了软件整个生命周期，而不仅限于开发阶段。
DevOps这样的开发模型，需要持续开发、持续集成（CI）、持续测试、持续部署/交付（CD）、持续监控，每一次代码改动都会触发一次校验，每天每时每刻都可进行新版本的上线。
持续集成（CI）开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。
持续交付（CD）完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境中。
我们认为：为了帮助研发团队在保持质量的前提下提高交付效率的方法和方法论都隶属于DevOps的范畴。
Google提出了5个DevOps原则：
- 精简组织结构
- 愿意承担一部分试错带来的损失；
- 分阶段地一小步一小步地进行转型；
- 最大化地利用工具和自动化流程；
- 对所有的过程和结果进行记录和分析。
DevOps 中的一套成熟的运维系统包括什么？
- 自动化测试
- 批量配置基础组件
- 监控，告警
- 数据可视化
- 协同合作
一套成熟的运维系统，能够将应用、网络、计算、存储、虚拟化等资源的性能以及告警信息进行综合分析，通过简洁易懂的界面，直观呈现业务健康水平。当出现故障时，能够第一时间受到信息，从监控相关信息确定问题位置，缩小故障定位范围，确定问题是在计算、应用还是网络，进而明确问题职责，让相应的开发运维迅速处理问题，没有推脱责任之嫌。