devops与敏捷开发_传统行业学敏捷
当你看敏捷的时候，不经意间出现了DevOps这个词，你还在好奇，这是什么的时候，发现规模化敏捷也出现了，这个时候如果你还发现自己对这个词很陌生，那说明你的知识该补齐了，毕竟他们如果总是频繁出现，说明他们的相关性很高。
咱们以前也分享过一些DevOps的文章，不过很多人对DevOps的基础还不太了解，今天就给大家做一些介绍。
学了敏捷，但你还不知道DevOps，就Out了【管理有度5】
图解DevOps流程体系全景图--构建敏捷+持续交付的体系平台
一文全面精通DevOps
DevOps平台架构图实例（多图）
其实不只是敏捷，在CMMI、ITIL都在提到DevOps，说明我们真的很有必要对它进行一个系统性的了解了。
CMMI中提到关于Devops
1、以价值为导向
2、开放式框架
3、构建项目的敏捷性
4、DevOps
图 CMMI
ITIL中提到关于DevOps
1、以价值为导向
2、Lean精益
3、Agile敏捷
4、DevOps
各类管理体系其实都在走向融合，而且都需要DevOps的支持，所以你还觉得自己不需要认真了解下它么？
如果你想快速的系统性的了解DevOps，可以先阅读以下几本书：
《凤凰项目》
《持续交付》
《独角兽项目》
《凤凰项目 一个IT运维的传奇故事》
《DevOps精要》
如果你报考了DevOps Master认证，那你《EXIN DevOps Master WhitePaper》是必读的。
什么是DevOps
DevOps是对敏捷软件开发与精益生产思想的演进，应用于IT端到端的价值链中，使得业务基于现代信息技术，并通过文化，组织与技术变革来获得更大的成功。
这是《DevOps精要》中关于DevOps定义，定义都有其严谨性，所以往往看完定义让我们摸不着头脑。
DevOps其实是英文单词Development(Dev)和Operations(Ops)的组合，为什么要把这两个词组合到一起，最初创造这个词的人目的就是期望开发和运维能够紧密的合作，随后逐步的被扩展和衍生，下面这个“DevOps能力环”是对这种打破部门墙，进行顺畅交付的一个非常经典的一个表达。
它强调了IT专业人员（研发，运维，测试）在应用和服务生命周期中的协作和沟通；强调整个组织合作以及交付和基础设施变更的自动化，从而实现持续集成、持续部署和持续交付。
DevOps能力环
DevOps的发展历史
我们为什么要了解其历史，如果我们只是想用DevOps的一些工程实践，大可不必，但是如果你的团队还对这个概念很陌生，他们不知道为什么要用DevOps，如果是这样的话，我们还是有必要花几分钟来了解下它。
DevOps起源于敏捷，是在2008年敏捷论坛上被提出的，所以现在很多人会认为DevOps是敏捷的一部分，对于到底是谁属于谁，谁包含谁，这些观念大家不必纠结，各大体系都认为自己包括别人。
敏捷认为它包括DevOps，而DevOps认为自己是它的衍生。
DevOps的概念在2010年的《What is DevOps》这篇文章中得到了较为完整的描述。DevOps在2013年之后被业界快速接受，源于相关技术的同步发展，2013年，dotCloud公司推出Docker项目，同年，Google推出开源项目Kubernetes，提供了以容器为中心的不部署、伸缩和运维平台，2015年云原生的概念也逐步成熟，他们的发展助推了DevOps的快速发展。
大家可能还听说过DevSecOps，Sec是不是安全，你猜的没错，就是安全和合规性，这是在2016年开始逐步推出的一个理念。
关于历史的部分就讲到这里，大家感兴趣的可以再做进一步的了解。了解了概念、历史之后，我们再来看看关于DevOps的整体框架，也就是知识体系部分。
DevOps的知识体系
在来看知识体系前，非常想要先给大家看一张图，DevOps的道法术器，有助于大家更好的理解也应用DevOps。
图1 DevOps的道法术器
“道”就是价值观，DevOps的出现核心是为商业价值服务的，通俗点来讲就是降本增效。
“法”是实现价值观的战略，DevOps这个词的组成的两个部分开发（Dev)和运维（Ops)，还包括测试（QA)的紧密协作就是DevOps的法，也就是拆除部门墙的这一概念。
“术”是战术、技术，系统应用指导原则。
“器”是指具体的工具了，利用工具提升开发、运维、测试的效率和质量，或者从另一个维度来说，运用工具以实现持续构建、持续集成、持续交付。
道、法、术、器自上而下是系统思考的层次，自下而上是解决问题的层次。接下来我们就来看看DevOps的知识体系，下图就是知识体系的三个支柱和一个基础。
图2 DevOps的知识体系
三个支柱分别是指规范敏捷，持续交付，IT服务管理，为什么DevOps是以这三部分作为支柱呢？
1.规范敏捷
为什么是规范敏捷，这一点很好借，首先从他的历史发展来看就是来源于敏捷的，他想要发挥作用是建立在良好的敏捷转型基础之上的，如果一个团队从需求、开发、测试、到最终发布需要至少3个月的时间，这个时候其实还没达到规范敏捷，这个时候想要应用DevOps可以暂且缓一缓，优先要考虑先让团队“敏捷”起来。
规范敏捷包括如下这些特点：
· 速度稳定（Stabilized Velocity）
· 适应变化（Adaptability for change）
· 总是能发布优质的无错误代码（Always release high quality bug free code）
另外，还有一个非常重要的概念，就是DoD（Definition of Done），完成的定义，这一点团队的每个人都必须非常清楚。
2.持续交付
从图2上可以看到，敏捷位于整个需求端到端交付的从计划、需求、设计，到开发的这一部分，而持续交付链接的是开发到部署的这一些列的过程。
那持续交付的定义是什么呢？
持续交付是指实现自动应用程序的构建、部署、测试和发布的流程。自动化是为了能够建立一个可重复、可信赖、和可预测的发布release，将一些重复的，易出错的过程通过自动化的方式沉淀到流程中，以降低可能由于人为导致的错误，同时减少工作量和提升质量。
持续交付里面有一个非重要的概念，部署流管线（Pipline)就是一套将代码从版本控制工具最终交付到用户手中的自动化流程。一般团队中一个产品会有一个部署流水线，不排除实际中一个团队有多个产品，公用一套部署流水线。
3.IT服务管理
软件交付了就代表工作结束了吗？当然不是，发布上线后要有持续的进行运营管理，保证服务的连续性和高可用性。
如果服务无法按照业务的要求保持连续性，或者无法在出现问题的情况下做到及时的恢复，对业务的正常运行会带来问题。
4.以TPS（精益管理）理念为基础
如果要追本溯源，无论是敏捷还是DevOps，最早的理念都是来自于传统制造业的精益生产实践。
《凤凰项目》中神秘的角色带主人公去参观的也是一个制造的流水线。TPS包括JIT（Just In Time)和自动化，想要做到JIT需要建立一个单件流（one-piece flow)，这个单件流需要尽可能的实现自动化，并能够在出现问题时及时停止。
总结
本文从什么是DevOps，DevOps的历史，以及DevOps的知识体系三个方面对DevOps进行了介绍，看完了上面的介绍，不知道大家是不是也对DevOps也有了一定的认识呢，欢迎互相交流。
近期热文：学了敏捷，但你还不知道DevOps，就Out了【管理有度5】
- 一文搞定PMO如何推动流程规范的落地及常见问题如何解决？【管理有度4】
- PMO和项目经理如何建立组织影响力【管理有度3】
- 如何做好项目干系人管理的实战案例分析？【管理有度2】
- 敏捷项目中如何做好进度管理及其步骤方法【管理有度1】
- PMO&项目经理如何高效解决问题看这篇文章就够了
上一篇
已是最后文章
最新文章
更多>