原创

基于DevOps平台构建自己博客:5-Coding平台提供的能力介绍

温馨提示:
本文最后更新于 2022年08月01日,已超过 6 天没有更新。若文章内的图片失效(无法正常加载),请留言反馈或直接联系我
首先,先声明一下,本文章内容不涉及任何有偿的产品推广促销等商业行为,只为单纯的技术方案分享使用,不存在以此谋利的行为。

一、Coding平台简介

地址:https://coding.net/

这就是coding平台的官方首页,访问后我们可以很清楚的看到该平台所提供的核心能力,正如描述的一样:提供一站式开发协作工具,帮助研发团队快速落地敏捷开发与DevOps开发方式,实现研发效能升级。

但是,这里Simon要提醒一下大家,目前这个平台还不是一个完整的DevOps平台。不过,可能平台后续会增加该部分能力,但截止当前文章编写,并没有看到目前有这个迹象。具体DevOps的相关知识,可以参考一下我们上一章讲的内容:基于DevOps平台构建自己博客:4-DevOps入门介绍

二、Coding平台能力介绍

下面我们看下这个平台具体的能力:

通过二级菜单,我们可以看到该平台提供了代码托管、持续集成、制品库、持续部署、项目协同、测试管理、API文档管理。我们现在详细说下这几部分的功能分别对应DevOps的哪些环节。

代码托管

在DevOps中,我们的代码是需要存储在代码库中的,设计人员或开发人员在代码库初始化项目工程后,需要将代码仓库的代码拉取到本地进行开发,并在开发结束后提交到代码仓库。而代码仓库需要提供如版本控制、提交管理、分支管理、Tag管理、合并管理、冲突解决、分支保护等等一系列的功能。常用代码仓库有subversion、git及mercurial等,具体可以参考Wiki:Codebase

在国内常用的解决方案中,我们会选用Gitlab,Github或者Gitee。当然,某些大厂也会有自己的仓库系统,如阿里的云效,腾讯的Coding。虽然,他们来着不同的公司,但是提供的能力几乎都是一样的。那么,代码托管具体有什么作用和意义呢?

对于多人协同开发而言,一个系统会有多人甚至多个团队共同完成,在开发过程中涉及到大量代码同步合并的工作,如果仅仅靠开发人员之间手动同步本地代码根本无法完成,而且极易出现人为的代码丢失、覆盖等问题。代码仓库在最早的多人协同开发中就体现出其重要的价值与地位。随着软件系统的不段更新,团队人员的更迭,代码仓库中的代码也成为了软件公司最重要、最直接的资产。与此同时,软件的升级所依赖的最终要的概念——版本,也就孕育而生。版本体现在交付的软件的标签,也同样需要体现在代码管理之中,所以,代码仓库的版本管理功能也便是最基本的能力。代码仓库支持版本管理之后,我们的软件开发组织变可以继续裂变成多个,针对不同的版本做开发、问题修复。在敏捷开发中,我们会发现敏捷团队会以故事为单位进行任务分配,这个时候,每个开发人员会有多个故事,但是,仅仅依靠版本的功能根本无法区分和管理到每个任务,这时,我们需要引入一个新的概念,那就是——分支(branch)。分支很好的解决了开发过程中,细粒度的代码管理问题。基于分支管理,在配合我们的研发流程中代码管理规范,一套完整且好用的解决方案就孕育而生了。而这套方案可以更好的支撑敏捷团队、支撑微服务、支撑DevOps。如下是我在管理团队时使用的代码分支管理流程:

这里就不再过多的说明代码管理的内容,有兴趣的可以留言,后续我会准备专题来讲解该部分内容。

说了这么多,代码托管在DevOps中具体有什么用呢?总结一下有以下几点:

  1. 存储并集合了所有开发人员可被编译部署的代码。
  2. 存储所有提交代码的分支、标签及提交记录等信息。
  3. 提供了代码分支管理及分支保护的功能,防止代码被非正常覆盖。
  4. 提供其他组件的安全拉取代码的源文件,可作为后续持续编译、持续部署的基础。
  5. 作为DevOps中,产出交付物的唯一源使用。

 

持续集成

英语:Continuous integration,缩写为CI,持续集成的能力在当前的软件开发过程中愈发重要。在早期的软件开发过程当中,很多公司有独立的团队来做这部分工作,主要内容就是合并开发提交到某个分支的代码,一个团队一个分支,团队内所有开发人员共用这个分支。多个开发团队的分支代码统一由这个组来合并到产品的主干分支上,解决冲突,然后手动编译、打包、部署到测试环境、执行各种测试、生成版本的升级包。最后发给用户或者一线运维人员。如果在测试过程中,出现了问题,则需重复合并代码到部署的动作,如果涉及到多个环境,工作量又增加。而持续集成解决了前半部分的工作:

  1. 手动的编译动作由系统自动触发。
  2. 打包的动作由系统自动触发。
  3. 在部署前的静态代码检查可由系统自动触发。
  4. 在部署前的单元测试可由系统自动触发。
  5. 在部署后的自动化测试可由系统自动触发。

而上面所说的系统就是我们DevOps中的持续集成的部分。在目前的行业内,通用的解决方案大多采用Jenkins作为整个DevOps流水线的核心来使用。下图是一张Jenkins的工作界面:

我们通常将持续集成简称为CI。而持续集成工具为我们提供了可定制化的操作能力,以Jenkins为例:

  1. 可以在这个平台配置对应的代码仓库,作为待编译代码的源
  2. 可以预设设定系统参数和变量。
  3. 可以在流水线中定义需要执行的各个阶段
  4. 可以在流水线中每个阶段书写我们需要执行的脚本
  5. 可以手动触发每个流水线的执行
  6. 可以查看执行过程中的日志
  7. 如果脚本中涉及拉取代码,可以将拉取的代码在本地的沙箱中编译
  8. 可以集成如sonar等工具,执行静态代码检查

类似Jenkins这种工具,为我们在持续集成中提供了几乎无限的可能。因为他是可扩展,他的核心能力取决于我们的流水线编排及具体脚本的书写。而当前的Coding平台的持续集成能力,为我们提供了更为简单易用且兼容Jenkinsfile语法的功能。当然,就目前了解到各大厂的解决方案中,基本持续基础的能来只是在Jenkins上封装了一层,增加了图形界面及配置的易用性,底层使用的仍然是Jenkins。具体可以参考官方的产品说明:https://coding.net/products/ci

Coding可视化的服务编排界面

 

制品库

制品是持续集成(CI)的产物,而制品库就是存放这些产物的仓库。那为什么要有制品库呢?持续集成后,直接将生成的制品部署到环境上不就可以了嘛,有必要单独存放到仓库吗?其实制品库的存在,有其重要的意义:

1. 制品库为持续集成产物提供了公共的存放位置,将持续集成和持续部署的流程解耦,使持续部署不再强依赖于持续集成,转而是依赖制品库中的制品。这样就为一次编译,任意部署提供了前提。

2. 制品库也有版本管理,每次持续集成生成的制品都可以作为版本存储在仓库中,至于每个版本如何使用,则由管理人员自己决定。当然,如果需要检查制品是否有问题,也可以从仓库下载制品分析,为问题定位分析提供了一种途径。

3. 制品仓库的出现将原来以流程为交付标准的情况,转变为以制品作为交付标准。进而保证了研发流程中,对交付物(制品)的全流程质量保证和质检目标的全程一致性。

 

持续部署

英语:Continuous deployment,缩写为CD,意指在软件开发流程中,以自动化方式,频繁而且持续性的,将软件部署到生产环境(production environment)中,使软件产品能够快速的发展。在概念中我们提到以自动化方式、频繁和持续性这些,那这些词在具体的DevOps中是如何体现的呢?通常情况,持续部署与持续集成结合,其他的工具或方式,使得持续部署可以自动触发,而触发后,部署物则是由持续集成构建出来的制品,而该制品在本构建之后便存放于制品库,持续部署则根据不同的场景,不同的环境,通过主动获取或发送指令到目标环境的方式,使得制品被部署到指定环境。而触发这一些列的动作,上面说到工具或方法,不同的解决方案有不同的方式。但是,自动化触发场景下,大多基于研发人员提交commit来处理,也就是代码仓库提供的钩子或者是用一些工具,如argocd。具体这里不做其他的延伸,有兴趣的小伙伴可以自行研究或留言讨论。

 

三、DevOps中的Ops

至此,我们已经介绍了一大半的DevOps的能力,但是,这部分主要集中在研发的阶段及一部分的Ops,所以说,Coding平台提供的DevOps的解决方案,目前还只是关注到研发及部署这一块,即DevOps的Dev这部分,而Ops就仅仅涉及到一部分,那么在DevOps中,Ops具体包含哪些内容呢?

DevOps是Development和Operations的组合词,所以,Ops自然就是Operations,即运维。不知道大家是否还记得上一讲:4-DevOps入门介绍中有这么一张图:

这里面与Ops相关的部分可以看做从Release就开始了,然后就是configure, Monitor以及Plan并进入下次Development循环。在Operations的循环中,Release的便是我们上面提到的制品,而configure的就是针对不同的环境,拥有不同的配置。在上面的持续部署中,我们并没有提到。但是,在生产实践当中,不同环境不同配置是持续部署阶段的重要部分。因为配置可以针对环境区分,也使得不同环境的差异性得以体现。而这种不同配置,通常我们的处理方式就是使用一个配置仓库,每个环境在配置仓库对应了一个标签,如PROD, UAT, SIT, DEV等等,而每个标签对应了一组配置文件集合。这样就可以针对不同环境使用不同的配置,不同的配置引用不同的中间件等资源。

除了上面说到的Configure,目前Coding平台以及其他市面上类似的解决方案缺失的主要是Monitor这部分。Monitor的价值在运维阶段至关重要,而在大量使用微服务及容器化方案的当下,传统的Monitor方式则变的愈发的困难。加上DevOps的特性,旧的制品是可能随时被替换的,相应的本地日志(包括应用日志、资源信息、容器信息等等)也会随着容器的销毁和重建而消失。同时,在微服务场景下,大量的微服务如果采用传统的监控方式,也会有大量的工作量。

目前业界常用的解决方案如ELK + Prometheus + Grafanar,这一套的好处就是好用且免费。借用一张filebeats的图片:

上图描述了日志收集及检索的部分,而Prometheus主要是收集资源信息,Grafana是展示平台。关于Monitor部分,不是本系列的重点,这里只是略微的提一下,有兴趣的朋友可以自己学习一下,或者留言交流。

 

至此,Coding平台的能力也基本介绍的差不多了,我们也提供了一些行业内的实现作为参考,如果有什么问题欢迎留言,谢谢!

正文到此结束
本文目录