DevOps 究竟是什么

敏捷方法论在数年前被奉为金科玉律，以至于出现了敏捷教练这个角色，使命是帮助企业改善产品研发流程，提升效率和质量。互联网的快速发展，各类产品迭代速度惊人，使得企业意识到必须有一套新的方法论、流程和工具来提升企业竞争力。竞争力的差距不再是活的好不好的问题，而是能不能活下去的问题。生死存亡之际，于是纷纷希望通过DevOps这一个全新的理念实现快速迭代，更快地实现管理者的意图，毕竟效率决定生死。

所以，DevOps是一种改善产品生产流程，提升竞争力的手段。本质上来说，软件研发也是生产活动，只是有一些特殊而已。DevOps能做的是将各自擅长的领域划分开，设计、开发、测试、运维关注在自己的核心领域，本质上与微服务架构的核心思想一致，都是分而治之，实现精细化操作与管理。责任明确、守土有责，那么人就成为了关键因素，人的积极性调动了，很多事情就很好解决了。

DevOps 如何实施

企业内部的研发流程往往存在很久，从内部开始是最好的做法，从内部突破、发掘痛点才能真正实现产品的“归零”。这里有两个误区要避免：

• 按照既有的内部流程和工具设计一套DevOps系统；
• 希望打造一个大而全的东西覆盖所有需求。
  
  

从内部需求出发没有问题，关键是需要甄别哪些是合理的，哪些是需要改造甚至重新来做的。怎样的流程才合理，哪些工具才合适当然跟设计人员的视野有关，但参考业内一些比较好的案例，基本上也能找到较好的解决方案。

DevOps系统也必须遵循在核心需求的基础上迭代的原则，往往搜集DevOps需求的时候，从BA到设计、开发、测试、运维到项目管理者各种需求层出不穷，他们都希望DevOps能帮助他们解决目前遇到的痛点或者不爽点，但是往往让DevOps设计人员难以抓住核心需求。

记得在一个大中型公司的DevOps启动会上，负责人面对着众多相关人员的眼睛，在台上说的第一句话是DevOps项目80%都失败了。他说出这句话的时候，其实已经说明这不是一个容易的事情。对既定流程的更改、对现用工具的更新换代都会给各个相关岗位的人员带来一定的工作量。

那么DevOps如何实施呢？

• 工具链
• 管理平台
• KPI
• Pipeline
  
  

DevOps相关的工具非常多，全部都可以采用开源工具，比如GitLab + Jenkins + Sonar + Robot + Kubenetes等等，当然最新开源的Spinnaker对于多云环境的部署有着非常好的支持，这方面也非常值得引入。对于传统项目中，通常会使用Jenkins配合诸多插件实现一键打包和部署。

对于管理平台而言，就需要一个统一的门户来管理各个工具。与各个工具的交互均以API形式进行，用户也不必管理在各个工具里面的用户和权限信息。最关键的是，通过一个统一的管理平台，可以很方便地将这些信息与项目管理信息对接起来，从项目维度看整个DevOps流程。

能够从相关管理角度看DevOps，那么很自然就可以想到使用KPI Dashboard的形式提供一个项目监控功能，方便查看整个的进程。比如，项目进行到哪个Sprint，每个微服务的开发进度，构建情况、部署情况，运维相关情况等等。

Pipeline是规范化的操作流程，结合可视化的设计，方便设计人员对流程进行管理，固化某些最佳实践实现复用。将Pipeline与产品的版本及项目关联能够很方便地追踪产品的整个生命周期情况，方便进行评估。
痛点在何处

既有项目的复杂依赖

通常一个项目的开发是基于一些已有的基础性内容，经年累月就会出现一个项目的依赖来自于另外两三个项目的Nexus仓库。只有具体负责项目的人才了解这些依赖，甚至经过项目人员流转，项目组成员也很难说清楚具体的依赖关系。

在做微服务改造的时候，很大部分时间就是在梳理这些依赖关系，然后一点点剥离，最终才能实现独立分发部署。然而整个过程中需要大量的项目相关人员的配合与参与，具体推进速度如何就取决于项目人员的配合程度了。

Jenkins 构建

部署环境相关信息多通过GitLab进行管理，由于Jenkins Job中CI和CD捆绑在一起，直接使用代码中的环境信息进行发布，自然简单快捷。这是基于开发人员对部署环境非常熟悉的情况，但是对于DevOps平台来说，问题就很严重了。往往版本的构建和发布是两个阶段，中间需要审核操作，其次开发和环境信息是隔离的，环境信息必须在部署前通过系统注入进去，而不是在代码中写成HardCode。

Job 改造

另外一个问题是Jenkins Job的定义方式，通常都采用直接定义，而不是采用DSL Pipe的形式进行定义。对于DevOps平台来说，代码构建和部署的Pipeline是跟产品的阶段、版本绑定的。必须可以在一个统一的管理平台上进行定义，DSL这种Pipeline描述语言就是为这种需求而生。设施DevOps意味着这类的Job的定义必须进行改造。

版本控制

实际项目开发过程涉及到项目与构建、部署信息需要打通的问题，即能够方便清晰地看到项目的版本有哪些微服务、每个微服务经历了哪些版本迭代、每个迭代经历了哪些构建等等。需要将原来的线下版本控制流程搬到线上，并且关联到具体的每一个构建和部署。

对代码的要求

很多项目由于非核心部分，在单元测试、代码的规范等要求不太够。当使用SonarQube等代码质量控制工具进行检查后，就会出现代码的测试覆盖率、规范等等影响开发行为的事情，这时候对于代码签入、PR合入的原则都有了新的要求。

总结

每个企业对与DevOps项目都有不同的期许，对于打造DevOps平台的企业来说，也是必须逐个击破痛点。DevOps涉及到的方面多、影响比较大，但不得不否认，其带来的影响力也是巨大的，推进DevOps的过程也是很艰辛的，但总体来说，还是很值得各个类型的企业在这个上面进行一番探索的。

原创：付辉

DevOps 究竟是什么

敏捷方法论在数年前被奉为金科玉律，以至于出现了敏捷教练这个角色，使命是帮助企业改善产品研发流程，提升效率和质量。互联网的快速发展，各类产品迭代速度惊人，使得企业意识到必须有一套新的方法论、流程和工具来提升企业竞争力。竞争力的差距不再是活的好不好的问题，而是能不能活下去的问题。生死存亡之际，于是纷纷希望通过DevOps这一个全新的理念实现快速迭代，更快地实现管理者的意图，毕竟效率决定生死。

所以，DevOps是一种改善产品生产流程，提升竞争力的手段。本质上来说，软件研发也是生产活动，只是有一些特殊而已。DevOps能做的是将各自擅长的领域划分开，设计、开发、测试、运维关注在自己的核心领域，本质上与微服务架构的核心思想一致，都是分而治之，实现精细化操作与管理。责任明确、守土有责，那么人就成为了关键因素，人的积极性调动了，很多事情就很好解决了。

DevOps 如何实施

企业内部的研发流程往往存在很久，从内部开始是最好的做法，从内部突破、发掘痛点才能真正实现产品的“归零”。这里有两个误区要避免：

• 按照既有的内部流程和工具设计一套DevOps系统；
• 希望打造一个大而全的东西覆盖所有需求。
  
  

从内部需求出发没有问题，关键是需要甄别哪些是合理的，哪些是需要改造甚至重新来做的。怎样的流程才合理，哪些工具才合适当然跟设计人员的视野有关，但参考业内一些比较好的案例，基本上也能找到较好的解决方案。

DevOps系统也必须遵循在核心需求的基础上迭代的原则，往往搜集DevOps需求的时候，从BA到设计、开发、测试、运维到项目管理者各种需求层出不穷，他们都希望DevOps能帮助他们解决目前遇到的痛点或者不爽点，但是往往让DevOps设计人员难以抓住核心需求。

记得在一个大中型公司的DevOps启动会上，负责人面对着众多相关人员的眼睛，在台上说的第一句话是DevOps项目80%都失败了。他说出这句话的时候，其实已经说明这不是一个容易的事情。对既定流程的更改、对现用工具的更新换代都会给各个相关岗位的人员带来一定的工作量。

那么DevOps如何实施呢？

• 工具链
• 管理平台
• KPI
• Pipeline
  
  

DevOps相关的工具非常多，全部都可以采用开源工具，比如GitLab + Jenkins + Sonar + Robot + Kubenetes等等，当然最新开源的Spinnaker对于多云环境的部署有着非常好的支持，这方面也非常值得引入。对于传统项目中，通常会使用Jenkins配合诸多插件实现一键打包和部署。

对于管理平台而言，就需要一个统一的门户来管理各个工具。与各个工具的交互均以API形式进行，用户也不必管理在各个工具里面的用户和权限信息。最关键的是，通过一个统一的管理平台，可以很方便地将这些信息与项目管理信息对接起来，从项目维度看整个DevOps流程。

能够从相关管理角度看DevOps，那么很自然就可以想到使用KPI Dashboard的形式提供一个项目监控功能，方便查看整个的进程。比如，项目进行到哪个Sprint，每个微服务的开发进度，构建情况、部署情况，运维相关情况等等。

Pipeline是规范化的操作流程，结合可视化的设计，方便设计人员对流程进行管理，固化某些最佳实践实现复用。将Pipeline与产品的版本及项目关联能够很方便地追踪产品的整个生命周期情况，方便进行评估。
痛点在何处

既有项目的复杂依赖

通常一个项目的开发是基于一些已有的基础性内容，经年累月就会出现一个项目的依赖来自于另外两三个项目的Nexus仓库。只有具体负责项目的人才了解这些依赖，甚至经过项目人员流转，项目组成员也很难说清楚具体的依赖关系。

在做微服务改造的时候，很大部分时间就是在梳理这些依赖关系，然后一点点剥离，最终才能实现独立分发部署。然而整个过程中需要大量的项目相关人员的配合与参与，具体推进速度如何就取决于项目人员的配合程度了。

Jenkins 构建

部署环境相关信息多通过GitLab进行管理，由于Jenkins Job中CI和CD捆绑在一起，直接使用代码中的环境信息进行发布，自然简单快捷。这是基于开发人员对部署环境非常熟悉的情况，但是对于DevOps平台来说，问题就很严重了。往往版本的构建和发布是两个阶段，中间需要审核操作，其次开发和环境信息是隔离的，环境信息必须在部署前通过系统注入进去，而不是在代码中写成HardCode。

Job 改造

另外一个问题是Jenkins Job的定义方式，通常都采用直接定义，而不是采用DSL Pipe的形式进行定义。对于DevOps平台来说，代码构建和部署的Pipeline是跟产品的阶段、版本绑定的。必须可以在一个统一的管理平台上进行定义，DSL这种Pipeline描述语言就是为这种需求而生。设施DevOps意味着这类的Job的定义必须进行改造。

版本控制

实际项目开发过程涉及到项目与构建、部署信息需要打通的问题，即能够方便清晰地看到项目的版本有哪些微服务、每个微服务经历了哪些版本迭代、每个迭代经历了哪些构建等等。需要将原来的线下版本控制流程搬到线上，并且关联到具体的每一个构建和部署。

对代码的要求

很多项目由于非核心部分，在单元测试、代码的规范等要求不太够。当使用SonarQube等代码质量控制工具进行检查后，就会出现代码的测试覆盖率、规范等等影响开发行为的事情，这时候对于代码签入、PR合入的原则都有了新的要求。

总结

每个企业对与DevOps项目都有不同的期许，对于打造DevOps平台的企业来说，也是必须逐个击破痛点。DevOps涉及到的方面多、影响比较大，但不得不否认，其带来的影响力也是巨大的，推进DevOps的过程也是很艰辛的，但总体来说，还是很值得各个类型的企业在这个上面进行一番探索的。

原创：付辉