对 DevOps 系统开发的见解、经验、心得、体会

本文阐述的是开发 DevOps 系统过程中产生的想法，而不是 DevOps 工具的使用教程。

务虚方面

DevOps 是一种研发团队的风格、理念、文化。

它与微服务、容器化技术相辅相成，并共同组成云原生的重要支架。

不能把 DevOps 仅仅看作使用一些工具。

就算部署了 Jenkins 或其他类似工具并发构建、部署流程搬上去，如果研发流程还是瀑布式或其他传统方式，那也只是给传统方式增加了一些自动化手段（当然这也是好的），算不上 DevOps。

务实方面

与内部系统打通

DevOps 一般作为 PaaS 的一部分，而后者要与内部系统融合。例如，按照中心、部门、工程划分组织层级，并且有相对完整的角色与权限。

考虑制品（artifact）的多样性

有的是可执行程序；有的是 jar，并需要上传到 maven 私服；有的是若干文件，如 foo.js 和 foo.min.js；有的是镜像，并需要上传到镜像仓库私服；有的是一个文档，例如运行一个统计任务，生成一个报告。

打通构建、部署流程各个环节

包括 VCS、镜像仓库、文件服务器、对象存储。

下面是几个典型的流水线：

例 1：从 VCS 拉取代码，运行拉取下来的文件中的 build.sh 构建，基于 Dockerfile 构建镜像，然后推送镜像到内网 Harbor，最后部署到某 Kubernetes 集群并发送一封邮件。

例 2：从 VCS 拉取代码，运行 mvn package，得到一个 jar，推动送到 maven 私服。

例 3：拉取代码仓库 r1，这是个 C++ 项目，make 得到 libfoo.so，将 libfoo.so 和 foo.h 放入内部 S3。

流水线要支持多环境

容器、VM。

VM 的能力范围超过容器。只有容器在某些情况会诸多不便。

主要支持图形化操作，且保留直接编辑流水线的入口

提供易于使用的图形化界面，让使用者直接在界面上编辑流水线。也保留“高级编辑”功能，让使用者在需要极大自由度时可以编辑流水线对象（如 Jenkins 的 jenkinsfile）。

充分利用 Kubernetes 的能力

例如，定义 Pipeline CRD，一个 Pipeline 包含多个 k8s Job。

审慎地选择技术

选择能掌控的，且灵活性、功能性能满足要求的技术。

结束语

以上是本人在某个 PaaS 产品中参与 DevOps 功能设计、开发中的感想。产品销量好，备受赞誉。其大客户（国有银行、行业大厂这种级别算大客户）数过百。