一、我们要解决什么问题

伟大领袖毛主席教导我们：“没有调查就没有发言权。”其实做 DevOps 也是一样，如果不了解具体企业、具体团队、具体项目的 DevOps 情况，就开始指指点点搞规划，那是没有什么好效果的，因为没有抓住它的痛点。

不论你是工具团队负责人，还是过程改进团队负责人，或者是 DevOps 教练，不论你想从工具角度做改进，或者从流程角度做改进，当你帮助一个团队做改进时，你总得先摸清楚当前 DevOps 的落地情况是怎样的。

所以我们就来看一下摸底工作到底怎么做？这个摸底的方法也是我们这些咨询师，这几年在为几十个项目做DevOps咨询的时候逐步探索出来的。

在开始之前，我们还是先说明一下我们这里说的 DevOps 是指啥。近几年 DevOps 是一个很火的词汇，搞得好像什么都是 DevOps 了，而今天重点讨论的是 Dev 之后，Ops 之前的部分，就是从你写完一行代码到把它发布上线这期间要考虑的部分。

那这部分里面发生了什么事情呢？

第一，生成转换。我们会看到程序的形态从源代码形态通过构建生成了安装包形态，再进一步被部署到线上运行起来，变成运行中的程序。程序的形态发生转换，从源代码最终生成转换为运行中的程序。

第二，配套支持。程序要想运行起来，需要相应的运行环境（测试环境、生产环境）支持，数据库表结构变更需要管理，不同环境有不同的配置，所有这些都是需要提供支持的。因为要想程序运行起来，需要一系列配套的东西在一起。

第三，累积汇聚。发布上线的时候，其实并不是只上线一行源代码改动，而是上线了一系列改动，这些改动是在软件交付过程中不断汇聚、累积起来的。如果你一个人写源代码就是不断累积，但一次发布的东西可能不止是一个人的改动，不同人写不同的用户故事，这实际是大家工作汇聚的过程。

第四，质量提升。最重要的是，这个过程当中会不断提升软件质量，直到达到可以发布的程度。这包括了静态测试和动态测试。

从这个过程来看，DevOps 包括了这四类活动，来实现从改动一行源代码到最后发布上线的事情。我们今天说的DevOps，就是这期间发生的事情。我们也可以把这个过程称作软件交付过程。

下面我们看一下我们这里讲的 DevOps 或者说软件交付，在软件开发全过程中的位置。

软件开发包括了哪些内容？总体上，大致划分为定义侧、实现侧，一起构成了软件开发。定义侧就是关于确定该研发什么，该把这个产品做成什么样子，产品的定义和业务定义是什么样的。产品经理，CEO 等都在这一侧，他们要定义产品是什么东西。

而咱们在座所有人都是在实现侧，把定义的东西实现出来。实现侧大体上包括了设计编码、交付、运维三个部分。设计编码是 Dev、运维是 Ops，这两者中间是交付过程，也就是我们这里说的 DevOps，某种意义上，它可以说是既属于 Dev，又属于 Ops，是两者的交集。

好，我们搞清楚了概念，下面就开始介绍如何做调研。

二、了解项目和团队总体情况

做调研，总得先了解一下总体情况吧。先看一下业务和系统的主要特征。

• 业务：这里说的业务是指，产品是做什么的。进而要了解产品是企业内部用户使用，还是企业外部用户使用，等等。
• 形态：这里指软件的形态。比如淘宝，它首先有服务端，成千上万台服务器。然后是客户端，手机淘宝。你要仔细分析服务端和客户端长什么样子。服务端可能全球只部署一套，所有人都访问这里。也有可能服务端是部署在各个企业内部，即私有云。服务端的不一样的情况会影响到 DevOps 的流程，如企业内部部署需要同时维护提供给不同企业的多个版本。客户端指的是用浏览器访问还是通过移动端 App 访问，还可能是嵌入式设备。只有分别考察客户端和服务端，才知道这个软件是什么形态，这个形态会决定后面调研什么。比如说客户端是浏览器，那考察的时候既要看服务端的后端模块也要看前端模块。而如果服务端是一个后端系统，供别的系统通过 API 和它打交道，这时候再看整个 DevOps 方案的时候就不关心前端的事情了，也不关心自动化UI测试，只需要关注自动化接口测试。
• 规模：规模决定了软件开发的难度，也会影响到软件的交付过程。
  
  • 软件规模是指有多少行源代码。研发团队规模是指由多少人在上面工作。因为人越多，协作越困难，需要分更多层级，越需要流程。
  • 还要看用户规模、部署规模。访问量大了，负载就高了，就需要部署更多的机器和节点。访问量大了，对质量的要求也有所提高。
  • 耦合性。耦合性是指如果系统是由一个个松散的单元组成，比如微服务，当你说规模的时候，基本上只需要关注一个微服务的规模就可以了，因为是相对独立的。而如果是一个强耦合的大系统，比如比较古老的一个大型单体应用，这时候不能只看某一个模块的规模了，在看规模的时候就得看系统整体的规模。
    
• 质量：一方面是质量要求高不高，另一方面看质量是不是好实现，如果算法特别复杂，逻辑特别复杂，可能就不好实现，如果只是一个简单的转接，就比较容易实现高质量。
  

然后我们要大致了解一下管理实践。

首先一个问题是，这个产品管需求条目叫什么？就叫需求，还是用户故事，还是特性，甚至可能是项目。我们要用跟用户一样的语言，所以先要了解用户怎么说。另外需求是分层级的，我们关键是要抓住哪个层级呢？抓住可以独立测试、独立发布的需求，这个层级。因为将来它很可能会映射成一条 Feature 分支。将来统计测试的内容、发布的内容的时候，也说的是有哪些这样的条目。

接下来是关于开发的组织方式。典型的，Scrum 这样的迭代方式，或者精益看板墙来管理的精益方式。后者比前者要更好些。

最后落实到要看当前的发布频率。比如可能是每个迭代末发布。当然也有多个迭代才发布一次或者一个迭代发布多次的情况。

接下来我们顺着生成转换过程了解下，从源代码，然后构建，再到部署运行起来。这些事情一方面是了解情况，比如用没用容器啊，用没用容器编排啊。另一方面和项目团队建立一些共同语言，将来沟通的时候，你说的别人听得懂。

为什么你说的别人听得懂？因为你是用别人的语言来说。比如说，开发环境，在不同的团队里，它的含义就不一样。有时候指的是个人开发环境，还有的时候指的是开发人员共用的一个服务器端的测试联调环境。

最后看一下分支策略。如果想了解流程，那么先看分支策略，因为分支策略是承载了它的流程的。你能看到代码在哪儿 Checkout，在哪儿提交的，在这条分支上怎么被管理的，流程再往下走，提交到新的分支又怎么去管理，你顺着分支就捋下来了，就是一个完整的 DevOps 过程。

1000个项目有1000种分支策略。那你怎么去着手了解呢？有一个小的窍门，就是从这四个角度去了解：

• 总的分支模式：是基于 GitFlow 模式，还是基于 AoneFlow 模式？跟这样的典型分支模式的差别在哪儿？如果这个事情一上来就弄清楚了，那可就省事儿了。
• 代表线上最新版本分支：现在常用 master 分支来做这件事，它上面的版本代表了当前最新发布到生产环境的版本。
• 集成/发布分支：典型的，GitFlow 里的 develop 分支。而 AoneFlow 里就没有一条长期存在的 develop 分支，而是一条一条的 release 分支。过去常提的主线开发模式，主线指的就是集成/发布分支。还有 Hotfix 用的分支，它的本质也是一条发布分支。
• 特性分支：特性分支不一定需要。如果有的话，就看它叫什么名字，从哪里拉出来的，合并到哪里，合并之前要满足哪些质量上的要求等等。
  
  

三、沿价值流进行梳理


了解完总体情况，下面我们来梳理价值流。这是精益里面的一个方法，沿着软件交付的流程进行梳理，从写下一行代码开始，是怎么一步一步最后发布上线的。通过梳理找到要改进的地方。

既然是沿价值流进行梳理，那我们就解释一下软件交付过程的6个阶段。

• 代码改动累积。代码改动累积就是在本地开发环境里没有做 git push 之前的事，随着不断地开发、不断地写代码，你要不断进行测试。这包括了静态代码扫描，也包括了本地的人工自测试、单元测试等等。关于自测试，还要详细考察，它是端到端的，还是只测一个微服务，其他都 mock 了。后者其实还是挺不够的，因为还有很多问题没有测到。理想情况下，尽管微服务是在个人开发环境里跑起来的，但是可以连通到整体测试环境和整体系统，于是可以做端到端的测试，这时候会发现更多的问题，将来遗漏给测试人员让他遇到的麻烦更少。代码改动累积阶段应该被重视。
• 代码改动提交。看看在 Push 之前有没有进一步的质量确认步骤。另外还要考察，多久提交一次。以前常说每天都提交，这可不是说，每天下班前必须要提交一次，是大概频率就好。
• 特性改动累积。如果你使用了特性分支，那就有这个阶段。为每一个用户故事、每一个需求拉出特性分支，在这个分支上面，为这个特性不断开发和 git push。在特性分支上，改动不断累积。并且可能每次 Push 都触发了流水线，做构建、单元测试、代码扫描。
• 特性改动提交。特性改动完成了，把特性分支合并到集成分支。这经常是一个 Merge Request 或者 Pull Request。
• 集成。它是指在集成分支上，不断收到新的特性或者新的代码改动，不断累积，在累积过程当中不断给你质量上的反馈，比如说提交触发流水线。进而做持续测试，不要等着所有功能开发后再测试，即使人工测试也不要这么等。每当有一两个 Feature 做完了，合并到集成分支上了，测试人员又有空闲，那就去做测试。
• 发布。这个阶段指什么呢？是指当所有的打算发布的功能都做完了，都提交到集成分支了，于是开始这个阶段。这个时候进行进一步的测试，如果测试特别顺利，全都通过了，那我就发布了。不像集成的时候，即便测试通过了也不会发布，因为还没攒够一拨呢。所以发布阶段就是最后一哆嗦。这里最重要的策略就是把发布阶段里干的事情尽量往前挪，挪到集成阶段，甚至再往前挪。我们要尽量避免在发布阶段做很多事情，这样我们才能比较频繁地发布。
  

所以看起来就是，首先是代码改动的不断累积不断测试，然后 piu，提交上去。接下来是特性分支上改动不断累积不断测试，然后 piu，合并到集成分支。最后是集成分支上代码不断累积不断测试，最后 piu，发布出去。你用这个框架去调研项目实际的交付流程，会让你思路特别的清晰。

四、了解各个具体活动

我们沿价值流进行了梳理，了解了在流程上，何时发生了什么，各个具体的活动是在什么时候发生的。但是对具体的活动本身，还需要更深入细致的了解。一个活动一个活动地细致深入地了解。

我们把所有的活动分一下类，然后看一下每个分类里面有哪些活动。

左边是非测试的活动。上面是源代码版本控制、构建、构建环境管理、制品管理等，总之是从源代码到构建，再把构建生成的制品储存起来。

下面是部署运行方面的事情，也就是怎么让制品变成运行中的程序，并为它提供环境上的支持。

右边是测试相关的活动。上面是静态测试，也就是靠分析源代码就进行的测试。包括人工的评审，也包括自动的代码扫描和制品分析。

下面是动态测试，也就是让程序跑起来进行的测试。从最简单的单元测试开始，一直到在生产环境下做的测试，比如全链路压测什么的。（转自董越）

一、我们要解决什么问题

伟大领袖毛主席教导我们：“没有调查就没有发言权。”其实做 DevOps 也是一样，如果不了解具体企业、具体团队、具体项目的 DevOps 情况，就开始指指点点搞规划，那是没有什么好效果的，因为没有抓住它的痛点。

不论你是工具团队负责人，还是过程改进团队负责人，或者是 DevOps 教练，不论你想从工具角度做改进，或者从流程角度做改进，当你帮助一个团队做改进时，你总得先摸清楚当前 DevOps 的落地情况是怎样的。

所以我们就来看一下摸底工作到底怎么做？这个摸底的方法也是我们这些咨询师，这几年在为几十个项目做DevOps咨询的时候逐步探索出来的。

在开始之前，我们还是先说明一下我们这里说的 DevOps 是指啥。近几年 DevOps 是一个很火的词汇，搞得好像什么都是 DevOps 了，而今天重点讨论的是 Dev 之后，Ops 之前的部分，就是从你写完一行代码到把它发布上线这期间要考虑的部分。

那这部分里面发生了什么事情呢？

第一，生成转换。我们会看到程序的形态从源代码形态通过构建生成了安装包形态，再进一步被部署到线上运行起来，变成运行中的程序。程序的形态发生转换，从源代码最终生成转换为运行中的程序。

第二，配套支持。程序要想运行起来，需要相应的运行环境（测试环境、生产环境）支持，数据库表结构变更需要管理，不同环境有不同的配置，所有这些都是需要提供支持的。因为要想程序运行起来，需要一系列配套的东西在一起。

第三，累积汇聚。发布上线的时候，其实并不是只上线一行源代码改动，而是上线了一系列改动，这些改动是在软件交付过程中不断汇聚、累积起来的。如果你一个人写源代码就是不断累积，但一次发布的东西可能不止是一个人的改动，不同人写不同的用户故事，这实际是大家工作汇聚的过程。

第四，质量提升。最重要的是，这个过程当中会不断提升软件质量，直到达到可以发布的程度。这包括了静态测试和动态测试。

从这个过程来看，DevOps 包括了这四类活动，来实现从改动一行源代码到最后发布上线的事情。我们今天说的DevOps，就是这期间发生的事情。我们也可以把这个过程称作软件交付过程。

下面我们看一下我们这里讲的 DevOps 或者说软件交付，在软件开发全过程中的位置。

软件开发包括了哪些内容？总体上，大致划分为定义侧、实现侧，一起构成了软件开发。定义侧就是关于确定该研发什么，该把这个产品做成什么样子，产品的定义和业务定义是什么样的。产品经理，CEO 等都在这一侧，他们要定义产品是什么东西。

而咱们在座所有人都是在实现侧，把定义的东西实现出来。实现侧大体上包括了设计编码、交付、运维三个部分。设计编码是 Dev、运维是 Ops，这两者中间是交付过程，也就是我们这里说的 DevOps，某种意义上，它可以说是既属于 Dev，又属于 Ops，是两者的交集。

好，我们搞清楚了概念，下面就开始介绍如何做调研。

二、了解项目和团队总体情况

做调研，总得先了解一下总体情况吧。先看一下业务和系统的主要特征。

• 业务：这里说的业务是指，产品是做什么的。进而要了解产品是企业内部用户使用，还是企业外部用户使用，等等。
• 形态：这里指软件的形态。比如淘宝，它首先有服务端，成千上万台服务器。然后是客户端，手机淘宝。你要仔细分析服务端和客户端长什么样子。服务端可能全球只部署一套，所有人都访问这里。也有可能服务端是部署在各个企业内部，即私有云。服务端的不一样的情况会影响到 DevOps 的流程，如企业内部部署需要同时维护提供给不同企业的多个版本。客户端指的是用浏览器访问还是通过移动端 App 访问，还可能是嵌入式设备。只有分别考察客户端和服务端，才知道这个软件是什么形态，这个形态会决定后面调研什么。比如说客户端是浏览器，那考察的时候既要看服务端的后端模块也要看前端模块。而如果服务端是一个后端系统，供别的系统通过 API 和它打交道，这时候再看整个 DevOps 方案的时候就不关心前端的事情了，也不关心自动化UI测试，只需要关注自动化接口测试。
• 规模：规模决定了软件开发的难度，也会影响到软件的交付过程。
  
  • 软件规模是指有多少行源代码。研发团队规模是指由多少人在上面工作。因为人越多，协作越困难，需要分更多层级，越需要流程。
  • 还要看用户规模、部署规模。访问量大了，负载就高了，就需要部署更多的机器和节点。访问量大了，对质量的要求也有所提高。
  • 耦合性。耦合性是指如果系统是由一个个松散的单元组成，比如微服务，当你说规模的时候，基本上只需要关注一个微服务的规模就可以了，因为是相对独立的。而如果是一个强耦合的大系统，比如比较古老的一个大型单体应用，这时候不能只看某一个模块的规模了，在看规模的时候就得看系统整体的规模。
    
• 质量：一方面是质量要求高不高，另一方面看质量是不是好实现，如果算法特别复杂，逻辑特别复杂，可能就不好实现，如果只是一个简单的转接，就比较容易实现高质量。
  

然后我们要大致了解一下管理实践。

首先一个问题是，这个产品管需求条目叫什么？就叫需求，还是用户故事，还是特性，甚至可能是项目。我们要用跟用户一样的语言，所以先要了解用户怎么说。另外需求是分层级的，我们关键是要抓住哪个层级呢？抓住可以独立测试、独立发布的需求，这个层级。因为将来它很可能会映射成一条 Feature 分支。将来统计测试的内容、发布的内容的时候，也说的是有哪些这样的条目。

接下来是关于开发的组织方式。典型的，Scrum 这样的迭代方式，或者精益看板墙来管理的精益方式。后者比前者要更好些。

最后落实到要看当前的发布频率。比如可能是每个迭代末发布。当然也有多个迭代才发布一次或者一个迭代发布多次的情况。

接下来我们顺着生成转换过程了解下，从源代码，然后构建，再到部署运行起来。这些事情一方面是了解情况，比如用没用容器啊，用没用容器编排啊。另一方面和项目团队建立一些共同语言，将来沟通的时候，你说的别人听得懂。

为什么你说的别人听得懂？因为你是用别人的语言来说。比如说，开发环境，在不同的团队里，它的含义就不一样。有时候指的是个人开发环境，还有的时候指的是开发人员共用的一个服务器端的测试联调环境。

最后看一下分支策略。如果想了解流程，那么先看分支策略，因为分支策略是承载了它的流程的。你能看到代码在哪儿 Checkout，在哪儿提交的，在这条分支上怎么被管理的，流程再往下走，提交到新的分支又怎么去管理，你顺着分支就捋下来了，就是一个完整的 DevOps 过程。

1000个项目有1000种分支策略。那你怎么去着手了解呢？有一个小的窍门，就是从这四个角度去了解：

• 总的分支模式：是基于 GitFlow 模式，还是基于 AoneFlow 模式？跟这样的典型分支模式的差别在哪儿？如果这个事情一上来就弄清楚了，那可就省事儿了。
• 代表线上最新版本分支：现在常用 master 分支来做这件事，它上面的版本代表了当前最新发布到生产环境的版本。
• 集成/发布分支：典型的，GitFlow 里的 develop 分支。而 AoneFlow 里就没有一条长期存在的 develop 分支，而是一条一条的 release 分支。过去常提的主线开发模式，主线指的就是集成/发布分支。还有 Hotfix 用的分支，它的本质也是一条发布分支。
• 特性分支：特性分支不一定需要。如果有的话，就看它叫什么名字，从哪里拉出来的，合并到哪里，合并之前要满足哪些质量上的要求等等。
  
  

三、沿价值流进行梳理


了解完总体情况，下面我们来梳理价值流。这是精益里面的一个方法，沿着软件交付的流程进行梳理，从写下一行代码开始，是怎么一步一步最后发布上线的。通过梳理找到要改进的地方。

既然是沿价值流进行梳理，那我们就解释一下软件交付过程的6个阶段。

• 代码改动累积。代码改动累积就是在本地开发环境里没有做 git push 之前的事，随着不断地开发、不断地写代码，你要不断进行测试。这包括了静态代码扫描，也包括了本地的人工自测试、单元测试等等。关于自测试，还要详细考察，它是端到端的，还是只测一个微服务，其他都 mock 了。后者其实还是挺不够的，因为还有很多问题没有测到。理想情况下，尽管微服务是在个人开发环境里跑起来的，但是可以连通到整体测试环境和整体系统，于是可以做端到端的测试，这时候会发现更多的问题，将来遗漏给测试人员让他遇到的麻烦更少。代码改动累积阶段应该被重视。
• 代码改动提交。看看在 Push 之前有没有进一步的质量确认步骤。另外还要考察，多久提交一次。以前常说每天都提交，这可不是说，每天下班前必须要提交一次，是大概频率就好。
• 特性改动累积。如果你使用了特性分支，那就有这个阶段。为每一个用户故事、每一个需求拉出特性分支，在这个分支上面，为这个特性不断开发和 git push。在特性分支上，改动不断累积。并且可能每次 Push 都触发了流水线，做构建、单元测试、代码扫描。
• 特性改动提交。特性改动完成了，把特性分支合并到集成分支。这经常是一个 Merge Request 或者 Pull Request。
• 集成。它是指在集成分支上，不断收到新的特性或者新的代码改动，不断累积，在累积过程当中不断给你质量上的反馈，比如说提交触发流水线。进而做持续测试，不要等着所有功能开发后再测试，即使人工测试也不要这么等。每当有一两个 Feature 做完了，合并到集成分支上了，测试人员又有空闲，那就去做测试。
• 发布。这个阶段指什么呢？是指当所有的打算发布的功能都做完了，都提交到集成分支了，于是开始这个阶段。这个时候进行进一步的测试，如果测试特别顺利，全都通过了，那我就发布了。不像集成的时候，即便测试通过了也不会发布，因为还没攒够一拨呢。所以发布阶段就是最后一哆嗦。这里最重要的策略就是把发布阶段里干的事情尽量往前挪，挪到集成阶段，甚至再往前挪。我们要尽量避免在发布阶段做很多事情，这样我们才能比较频繁地发布。
  

所以看起来就是，首先是代码改动的不断累积不断测试，然后 piu，提交上去。接下来是特性分支上改动不断累积不断测试，然后 piu，合并到集成分支。最后是集成分支上代码不断累积不断测试，最后 piu，发布出去。你用这个框架去调研项目实际的交付流程，会让你思路特别的清晰。

四、了解各个具体活动

我们沿价值流进行了梳理，了解了在流程上，何时发生了什么，各个具体的活动是在什么时候发生的。但是对具体的活动本身，还需要更深入细致的了解。一个活动一个活动地细致深入地了解。

我们把所有的活动分一下类，然后看一下每个分类里面有哪些活动。

左边是非测试的活动。上面是源代码版本控制、构建、构建环境管理、制品管理等，总之是从源代码到构建，再把构建生成的制品储存起来。

下面是部署运行方面的事情，也就是怎么让制品变成运行中的程序，并为它提供环境上的支持。

右边是测试相关的活动。上面是静态测试，也就是靠分析源代码就进行的测试。包括人工的评审，也包括自动的代码扫描和制品分析。

下面是动态测试，也就是让程序跑起来进行的测试。从最简单的单元测试开始，一直到在生产环境下做的测试，比如全链路压测什么的。（转自董越）