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