天马行空DevOps-Dev平台建设概述

概述

DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

本篇主要概述的是Dev环节的支撑平台。如何一套Dev平台来同时支持传统企业交付模式以及互联网业务交付模式。关于支撑Ops阶段的平台涉及内容庞大复杂，后续从数据中心Ops的角度展开论述。

关于本人对Dev与Ops环节的支撑平台的划分，大致为如下：

场景分析

互联网业务的特点是自开发，自运维，标准的devops模式，从研发活动来看，涉及五个阶段，code，build，test，deploy，monitor。每个阶段的职责不同。

传统IT业务的特点是研发团队负责开发交付，IT技术支持团队负责实施（部署，升级），客户负责运维。且传统IT企业交付的往往是一整套完整的解决方案。

相比较互联网业务模式，研发活动流程变为了如下，增加了assemble(装配过程)。

也就是如何将开发团队的输出装配为面向客户交付的解决方案包。

两种场景下的共同诉求都是devops理念中构建，测试，发布更加快捷，频繁，可靠。

Code阶段

核心目标是如何快速，低门槛的开发，同时对于QA来说，如何可进行统计度量（代码量，产出率等）。而快速，低门槛则尽可能让开发只聚焦与核心业务逻辑的实现，更多的工程相关的属性依托于可视化，自动化的构筑生成。因此需要契约化的工程结构，以支撑后续的运行维护管理。微服务架构模式下，微服务是最小的工程单元，因此也即是定义一种符合微服务的契约化的工程属性。微服务的特征要求具备独立可编译部署变更，对外需要清晰的API等。

因此可以定义譬如下面的开发工程的目录结构

一般一个微服务的开发顺序可参照如下：

一般在设计阶段就需要输出API定义，传统的往往是word或者excel等定义，用于评审，然后开发阶段需要编写代码去定义，此部分则可以完全简化，基于YAML/JSON定义API文件，并基于Swagger直接可视化展示API用于评审，开发阶段同样基于此文件直接生成API代码和到业务逻辑的调用。最终开发者直接编写API的实现单元即可。

依托于契约化松耦合的目录结构，需要devops平台具备如下的能力：

1：微服务的初始化管理服务。微服务自身就是个后续需要被维护管理的对象，故而需要一个微服务管理的能力。包含：微服务定义，开发工程生成，以及关键指标的搜集（代码量，开发语言，责任人，提交次数等）

2：基于主流开发工具（Eclipse，IDEA）可一键式生成API代码。

微服务初始化管理服务（后续简称codeinit）结构可大致表述为如下

至此基于微服务管理服务的code过程变为：

Build阶段

核心目标是检查原始代码的质量并编译生成可执行的包。

• 下载代码：是指从代码仓库下载到编译服务器
• 门禁检查：包含契约化目录规范的检查，圈复杂度检查，findbugs检查，代码样式检查等。
• 编译：则是将原始代码生成二进制，使用语言自身的编译器完成，打包则是生成预期的最终可部署的包，其包含编译产生的二进制文件以及程序的配置文件等。
• 推送：是指生成的包推送到包仓库(FTP服务器，镜像库等)。
• 统计：贯穿在整个Build阶段，是指Build阶段的各种度量指标，譬如编译次数，编译成功率等。

，

Assemble阶段

Assemble核心目标是微服务包到服务包，服务包到解决方案大包，或者微服务包到解决方案大包的自动化装配过程。

需要一种契约化的包的装配规则的定义，包含目标包类型（解决方案，服务），包含的服务或者微服务。最终客户拿到的是一个基于部署系统可部署的完整的大包，不用自己手动下载组装配套的多个包。

最终效果：研发团队视角提供微服务，形成一种原子能力的微服务池子，不同解决方案定义不同的微服务打包策略，基于devops平台自动装配不同的解决方案包。

Deploy阶段

Deploy阶段隶属于Ops范围，涉及上下文很多，后续详细展开论述，此部分只做概要介绍。

部署系统的核心目标是可视化/自动化的将解决方案包/服务包/微服务包部署到不同的环境的节点上。这里面涉及几个名词：包，部署动作，环境，节点，需要展开论述。

包指的是开发活动交付的软件的载体。可以是zip/镜像等。

环境：指的是部署活动中涉及的Alpha（服务内自验证环境），Beta(服务间联调环境)，Gamma(类生产环境)，Gamma(生产环境)。

节点：这里面定义的是在可直接部署包的介质，需要强调的是可直接部署性。一般性硬件和软件是分离的两拨人，一个数据中心内允许两次驻场，以此是设备采购到位后，硬件调测人员进驻进行硬件安装配置，其次是软件调测人员驻场，进行操作系统安装及其之后的过程，而对于部署系统来说，此处部署的是软件包，并不包括OS安装配置，故而也就引出了另一个系统：独立的装机服务，此即为部署系统的其中一个上下文，但并非属于部署系统。但是实际往往也可能没有独立的装机服务，譬如节点如果全是虚拟机，而一般企业往往虚拟机的生命周期管理存在与独立的云管理平台中（物理机的初始化，OS安装，虚拟机发放）。此时云管理平台即可承载此处所需的装机能力。

Monitor阶段

DevOps模式下的Monitor隶属于Ops范围，涉及内容和上下文很多，其内容包含监控（硬件，OS，业务的性能，调用链，拨测），告警，故障诊断等，上下文涉及变更，事件，报表，通道等后续详细展开论述。

此处需要附加说明的是即使从Dev阶段也是需要Monitor能力的，也就是监控统计Code，Build，Assemble阶段的各个指标

Dev平台技术调研分析

Docker

分析目标：基于上述Dev平台建设思路，Docker的目标在此处位于Build或Assemble阶段场景之一，也就是流水线环节中构建包（镜像），所以重点分析的是Docker镜像库，以及构建镜像的环节。但是不仅限于Docker，需要扩展分析支持带状态应用的下的容器技术（类似虚拟机形态的面向资源的容器的镜像模型和构建）。

Kubernates

分析目标：基于上述Dev(Ops)平台建设思路，Kubernates的目标在于Deploy阶段使用场景之一，也就是流水线环节中部署系统，重点分析基于Kubernates部署应用的流程，以及运行机制，部署架构。

Jekins

分析目标：基于上述Dev平台建设思路，Jekins的目标是自动化Code到Build或者Assemble阶段，重点分析其使用流程，Jekins的扩展性（譬如插件生态，二次开发能力等），用于决策整个Code->Assemble阶段是自研借鉴或者还是基于其二次开发。

Gerrit

分析目标：基于上述Dev平台建设思路，Gerrit的目标是Code阶段的代码Review，重点分析其使用方式（操作和角色权限控制），环境部署，用于集成到整个Dev流水线之中

Github

分析目标：基于上述Dev平台建设思路，此处主要是提供代码仓库，需要重点分析其使用方式，API（或lib库）等，用于，同时横向需要比较分析Gitlab，已决定采取何种构建代码仓库。