简介

在敏捷已经被大多数人接受的当下，DevOps成为了下一个软件工程领域最具热度的话题。这里我们就是要讨论一下，应该以何种方式才能更好推广DevOps。

作者：薄涛

LEANSOFT咨询服务总监，认证 Scrum Master，曾为多个行业的100多家客户实施过微软Team Foundation Server，包括：中国农业银行，兴业银行，中关村银行，华为，上海通用，上海汇众，百威英博，斯伦贝谢，世纪互联，金士顿(台湾)等。

随着国内软件开发敏捷化的推进，DevOps已经被越来越多的企业所关注，但是随着对DevOps的了解的逐渐加深，很多企业都在思考：要不要开始DevOps，面对企业现状应该怎么做？我要投入多少？

其实目前我国很多企业都是在进行初期的敏捷探索，完全谈不上企业级敏捷管理，但是又由于市场与业务所带来的压力让他们都向开始进行DevOps转型，这时DevOps的推进就使很多企业感觉无从下手，今天我们就讨论一下，如何才能在最小的风险下，投入最少的成本做到一个较高程度的DevOps。

这里我们先分析一下DevOps是什么。大部分人对DevOps的解释都是从这个单词直译过来的就是开发运维一体化，其实这样理解很片面。其实我们不难从Patrick提出DevOps的过程得出结论，DevOps的精准解释应该是通过敏捷的软件开发与敏捷的运维管理相结合达到业务的快速、灵活响应，也就是DevOps = Dev Agile + Ops Agile。那么我们在重新组合整理下，DevOps就是敏捷管理与软件的持续交付。

敏捷管理这里就不过多阐述了，我们主要说一下持续交付。下面我们看一下持续交付改进框架100-to-100。

这个框架说明了我们需要在持续交付上进行哪些改进，才能做到从100天发布1次（瀑布式开发）转变成1天发布100次（DevOps）。

首先我们为我们的后续话题引入一个定理：康威定理。

康威定理中一条与软件行业息息相关的定律，我们可以这样解读：企业内组织架构会直接映射到你的软件产品上。也就是说你的组织架构决定了你的沟通方式，同时都会直接体现在你的软件产品上。

从100-to-100框架上我们不难看出，框架中的多个模型都与了=康威定理中组织架构与系统架构有关系：组织架构即团队模型，组织之间的沟通方式决定了分支模型，技术架构即系统架构，系统架构也影响着你的基础设施以及你的部署模型。这里我发现，当我们对康威定理中关联紧密的模型进行改进的时候，企业面临的改动与风险要远远高于关联不紧密的模型。比如对测试模型的改进对企业的影响远远小于对团队模型的改进。因此我们这里引入康威定理，帮助我们分析DevOps实施的最佳方式。

DevOps的推进无外乎激进型与循序渐进型，激进型就是全面实现DevOps转型，从敏捷管理到持续交付框架改进同时进行，这种方式需要有雄厚的资金实力，较强的市场掌控力以及超强的技术实力，而且即便具备了这些要素这个过程也是困难重重，所以这种方式的特点是：风险大，转型周期相对较短。

循序渐进也就意味着要从对企业影响最小的方面入手，逐渐构建企业DevOps体系。这种方式的特点是：风险小，转型周期较长。

首先我们应该从构建自己的两个核心DevOps能力开始：自动化与脚本化：

• 自动化：指的是依托于工具帮助企业减少软件研发过程中的手工干预，在版本管理，测试，部署，发布等等环节实现自动化。
• 脚本化：让你的测试脚本化，让你的数据库管理脚本化，还有就是DevOps的核心能力基础架构即代码（Infrastructure as Code）， 即环境脚本化。
  
  

在企业不具备这两种核心能力时，不管是敏捷的推广还是DevOps的实践，收益都会减少很多，因此企业需要在一开始就持续构建这两个能力，以便为企业的DevOps转型铺平道路。同时这两个能力的建设对企业来说影响最小，也是最容易推行的。

其实这里对于这两种能力的建设我们可以借助一个非常好的工具：Docker。Docker能极大的简化我们的持续交付模型改进过程。下面这张图展示的就是Docker能在100-to-100框架中可以帮到企业的改进点：

因此如果你想更快更好的实现DevOps，容器化绝对是你的首选。关于Docker的更多介绍您可以扫描文章下方的二维码关注我们的公众号。

此时也可以在源代码的分支管理模型中进行改进，我们应该抛弃传统的集中式源代码管理方式，尝试使用Git作为新的源代码管理方式，因为这样可以帮助我们的团队构建面向用户故事的交付体系。下面这张图即使了我们应该怎样改进我们的分支模型，以及能达到的效果：

当然对于没有实现100-to-100的框架时，我们可以将分支管理模型中的分支粒度加大，变成 软件版本+PR+质量门禁的方式。这样一来分支即版本，对分支的质量使用自动化及脚本化进行内建，最终达到软件版本的统一自动化管理。

当我们实现了自动化建设，并且脚本化能力初具规模时我们就需要对康威定理中紧密关联的模型进行改进了，也就是团队模型，技术架构以及部署模型。

对于这些模型我们就需要从粒度与解耦两个维度进行持续改进。

粒度是由用户的业务灵活响应程度来决定的，你的业务对灵活响应的速度要求越快，那么你的组织架构与系统架构的粒度就应该越小，同时当你的粒度降低的时，你的过程管理也会变得更加简单。当你要适应业务灵活响应的需要时会发现，组织架构及系统架构的内在耦合性阻止了粒度的降低，因此你就需要解耦。在DevOps实践过程中对于业务的响应速度直接依赖于系统结构，系统结构粒度越小，耦合性越低，响应速度才能越快。同时根据康威定理，系统结构的粒度的降低，也让我们对组织结构的调整越顺利。

所以对于国内的大多数企业来说，首先实现自动化与脚本化是实现DevOps的基础，在此之上根据市场及业务的实际需要规划我们的技术架构，由此调整我们的团队模型，同时借助容器帮助团队快速实现转型，是一种最好的DevOps实践方式。

原创： 薄涛

简介

在敏捷已经被大多数人接受的当下，DevOps成为了下一个软件工程领域最具热度的话题。这里我们就是要讨论一下，应该以何种方式才能更好推广DevOps。

作者：薄涛

LEANSOFT咨询服务总监，认证 Scrum Master，曾为多个行业的100多家客户实施过微软Team Foundation Server，包括：中国农业银行，兴业银行，中关村银行，华为，上海通用，上海汇众，百威英博，斯伦贝谢，世纪互联，金士顿(台湾)等。

随着国内软件开发敏捷化的推进，DevOps已经被越来越多的企业所关注，但是随着对DevOps的了解的逐渐加深，很多企业都在思考：要不要开始DevOps，面对企业现状应该怎么做？我要投入多少？

其实目前我国很多企业都是在进行初期的敏捷探索，完全谈不上企业级敏捷管理，但是又由于市场与业务所带来的压力让他们都向开始进行DevOps转型，这时DevOps的推进就使很多企业感觉无从下手，今天我们就讨论一下，如何才能在最小的风险下，投入最少的成本做到一个较高程度的DevOps。

这里我们先分析一下DevOps是什么。大部分人对DevOps的解释都是从这个单词直译过来的就是开发运维一体化，其实这样理解很片面。其实我们不难从Patrick提出DevOps的过程得出结论，DevOps的精准解释应该是通过敏捷的软件开发与敏捷的运维管理相结合达到业务的快速、灵活响应，也就是DevOps = Dev Agile + Ops Agile。那么我们在重新组合整理下，DevOps就是敏捷管理与软件的持续交付。

敏捷管理这里就不过多阐述了，我们主要说一下持续交付。下面我们看一下持续交付改进框架100-to-100。

这个框架说明了我们需要在持续交付上进行哪些改进，才能做到从100天发布1次（瀑布式开发）转变成1天发布100次（DevOps）。

首先我们为我们的后续话题引入一个定理：康威定理。

康威定理中一条与软件行业息息相关的定律，我们可以这样解读：企业内组织架构会直接映射到你的软件产品上。也就是说你的组织架构决定了你的沟通方式，同时都会直接体现在你的软件产品上。

从100-to-100框架上我们不难看出，框架中的多个模型都与了=康威定理中组织架构与系统架构有关系：组织架构即团队模型，组织之间的沟通方式决定了分支模型，技术架构即系统架构，系统架构也影响着你的基础设施以及你的部署模型。这里我发现，当我们对康威定理中关联紧密的模型进行改进的时候，企业面临的改动与风险要远远高于关联不紧密的模型。比如对测试模型的改进对企业的影响远远小于对团队模型的改进。因此我们这里引入康威定理，帮助我们分析DevOps实施的最佳方式。

DevOps的推进无外乎激进型与循序渐进型，激进型就是全面实现DevOps转型，从敏捷管理到持续交付框架改进同时进行，这种方式需要有雄厚的资金实力，较强的市场掌控力以及超强的技术实力，而且即便具备了这些要素这个过程也是困难重重，所以这种方式的特点是：风险大，转型周期相对较短。

循序渐进也就意味着要从对企业影响最小的方面入手，逐渐构建企业DevOps体系。这种方式的特点是：风险小，转型周期较长。

首先我们应该从构建自己的两个核心DevOps能力开始：自动化与脚本化：

• 自动化：指的是依托于工具帮助企业减少软件研发过程中的手工干预，在版本管理，测试，部署，发布等等环节实现自动化。
• 脚本化：让你的测试脚本化，让你的数据库管理脚本化，还有就是DevOps的核心能力基础架构即代码（Infrastructure as Code）， 即环境脚本化。
  
  

在企业不具备这两种核心能力时，不管是敏捷的推广还是DevOps的实践，收益都会减少很多，因此企业需要在一开始就持续构建这两个能力，以便为企业的DevOps转型铺平道路。同时这两个能力的建设对企业来说影响最小，也是最容易推行的。

其实这里对于这两种能力的建设我们可以借助一个非常好的工具：Docker。Docker能极大的简化我们的持续交付模型改进过程。下面这张图展示的就是Docker能在100-to-100框架中可以帮到企业的改进点：

因此如果你想更快更好的实现DevOps，容器化绝对是你的首选。关于Docker的更多介绍您可以扫描文章下方的二维码关注我们的公众号。

此时也可以在源代码的分支管理模型中进行改进，我们应该抛弃传统的集中式源代码管理方式，尝试使用Git作为新的源代码管理方式，因为这样可以帮助我们的团队构建面向用户故事的交付体系。下面这张图即使了我们应该怎样改进我们的分支模型，以及能达到的效果：

当然对于没有实现100-to-100的框架时，我们可以将分支管理模型中的分支粒度加大，变成 软件版本+PR+质量门禁的方式。这样一来分支即版本，对分支的质量使用自动化及脚本化进行内建，最终达到软件版本的统一自动化管理。

当我们实现了自动化建设，并且脚本化能力初具规模时我们就需要对康威定理中紧密关联的模型进行改进了，也就是团队模型，技术架构以及部署模型。

对于这些模型我们就需要从粒度与解耦两个维度进行持续改进。

粒度是由用户的业务灵活响应程度来决定的，你的业务对灵活响应的速度要求越快，那么你的组织架构与系统架构的粒度就应该越小，同时当你的粒度降低的时，你的过程管理也会变得更加简单。当你要适应业务灵活响应的需要时会发现，组织架构及系统架构的内在耦合性阻止了粒度的降低，因此你就需要解耦。在DevOps实践过程中对于业务的响应速度直接依赖于系统结构，系统结构粒度越小，耦合性越低，响应速度才能越快。同时根据康威定理，系统结构的粒度的降低，也让我们对组织结构的调整越顺利。

所以对于国内的大多数企业来说，首先实现自动化与脚本化是实现DevOps的基础，在此之上根据市场及业务的实际需要规划我们的技术架构，由此调整我们的团队模型，同时借助容器帮助团队快速实现转型，是一种最好的DevOps实践方式。

原创： 薄涛