文章由什么是DevOps？总结而成。
传统开发和运维合作的困境
对于运维部门来说，不懂开发逻辑，而且团队内部的侧重不同，有些负责数据库脚本执行，有些负责Web服务器，如果每次上线前都需要把所有的人来过来开会，熟悉操作步骤。
当然最根本的原因在于软件本身太复杂了，开发复杂，部署也复杂。现在的系统，需要面对海量用户的报并发访问，还需要24*7的方式运行，如果只靠开发或者测试部门的人员进行兼职来维护几乎不可能。所以设立了运维部门(Operations)。
所以运维和研发的重要性已经差不多了。
又来个敏捷开发
传统的软件开发模式是瀑布式的，也就是说需要严格遵循预先计划的需求分析、编码、测试的步骤顺序进行。将软件开发分为不同的阶段，有点在于更便于协作，但是每个阶段极少有反馈。
所以经常会出现在项目快到了尾声的时候，才发现客户原来还需要其他功能，比如这个界面多一个选项 ，为领导留一个后门等等。
根本原因在于，从客户那里得到的需求描述和需求文档，其实离客户真正想要的还差很远。如果到了测试阶段才发现问题，想要改正的代价是非常高昂的。
那么能不能让客户经常做验收测试呢？这样有了反馈，可以迅速的修改。想想还是很美的，但是还是有很多的问题
- 抛弃了冗长的需求文档，但是还是得描述需求啊？
那么我们需要一种更高效的描述方法，叫用户故事，比如
用户故事主要彰显的是：谁做了什么事，带来什么价值。
- 如何决定每个小开发周期需要开发什么东西？
用户故事有大有小，大的需要拆分，
而且还需要对需求的优先级进行排序 - 架构设计怎么办？
架构工作肯定还是要的，但是更需要的是演进式的架构，随着迭代而推进。 - 详细设计怎么办？
每个迭代开始的时候，把用户故事拆分成小的任务，这个过程就相当于详细设计了。 - 由于是迭代开发，下一个周期怎么不破坏上一个周期的代码，测试怎么办？
答案就是自动循环回归测试，包括单元测试和功能测试
开发人员在写代码的同时，也要写下自动化单元测试，而测试人员需要开发自动化功能测试，一但有修改，就可以运行他们，检查是否有破坏功能。 - 这么短的时间，如何进行测试
开发和测试同时进行
这就是敏捷软件开发
但是虽然可以频繁交付，但是不能频繁上线，因为运维希望的是稳定，不希望给自己找麻烦，但是敏捷开发的思想是拥抱变化啊。
DevOps
所谓DevOps就是把敏捷开发部门和运维部门之间的围墙打通，形成闭环。
也就是要让系统不但稳定，还需要支持业务快速演化。
我们知道频繁部署和稳定是矛盾的，所以引入了微服务，部署不再以巨无霸的应用为单位了，而是以一个一个微服务为单位，简单很多。
为了方便部署，需要把部署的工作完全自动化，保证脚本在所有的环境能都可用。
