CI/CD

DevOps构建流程

2020-08-07  本文已影响0人  狗狗胖妞

以下内容为我们当前环境主要的构建发布方式，当然根据不同的环境也会有自己独特的构建发布方式。

1. 源码分支管理规范

请使用一个常驻分支作为构建分支，并且不要在这个常驻分支上私自随意提交

请查看源图地址: https://processon.com/view/5bf25121e4b0e9468c29614c?fromnew=1



下图是针对我们小微项目代码分支管理的建议流程：

如上，我们一般大多数的项目都是单分支流水线，在jenkins中我们只会选择其中一条常驻分支(一般叫Dev分支)进行构建。所以，当我们需要开发新的功能时，请从master或者dev上checkout新的功能开发分支进行开发，当我们本地开发完成后将其合并到dev分支触发DevOps(使用--no-ff, 不要快速合并)

一般规范的开发流程都应该如此或者比这更加完善，为什么要在这继续说呢？原因是我们很多小型项目的开发方式并不规范，都在一个分支上甚至master分支上疯狂commit并提交，这在DevOps上是不合理并不推荐的，因为你的这次提交的代码很可能并不完整，直接运行会报错，这样我们构建，测试，产生的镜像就没有任何意义。我们应该在自己的分支上将功能做好之后，再合并上去进行自动化的构建(合并分支最好交给专门的代码审核人员去管理)

2. 开发环境的构建

当我们按照上面的开发流程将功能分支合并到dev分支后，自动触发或者由开发人员主动去构建部署(当前我们是手动触发)


开发人员的构建流程如上图所示，登陆jenkins项目开发者用户并针对各个源码分支进行构建： 拉取代码 > 编译代码 > 构建镜像 > 推送镜像到harbor仓库 > 开发环境部署 ， 如下为一条在Blue Ocean构建的流水线:

3. 非开发环境的构建

非开发环境是指uat, 预发布，生产等环境，它们不是从源码仓库直接拉取代码、编译、测试、部署的。开发人员开发,修改源码并不断触发构建，当这个功能最终比较完善已经达到发布到uat、生产的级别时，由开发人员将应用和对应的版本告知运维人员，再由运维人员登陆非开发者用户进行uat、sit、生产等上线构建。这就是一次构建多次部署。

补充：从这可以看出，我们应该不要将配置硬编码，这样才能真正的满足一次构建多次部署，如果我们将配置存放到源码中，我们就不得不在开发环境、uat环境、预发布环境、生产环境等都进行编译，构建镜像并推送这样一个完整的过程，而且会影响到方方面面。关于配置硬编码的问题，请看我上一篇文档。

如下为非开发环境构建的入口：

参数化构建

由运维人员输入开发人员经过构建测试的镜像版本号进行上线，这个流水线支持该项目的多个环境多个应用的上线



上线逻辑图:

deploy3.jpg

如下为Blue Ocean的视图:

blueocean

如上，实际流水线其实还多了一步"judgeEnv"来判断环境在kubernetes集群下的命名空间，但其实这一步在这条流水线下是多余的，因为我将不同环境下k8s的清单文件放在不同的目录下面了，具体可以往下看“流水线源码管理”这一节。

4. 回滚

与非开发环境一样，回滚也是都能放在一条流水线下进行的。但因为安全的原因，这边还是分为了两条流水线，一条给开发人员作为开发环境的回滚，一条给运维人员做非开发环境的回滚。

  1. 选择准备回滚的应用；
  1. 选择准备回滚的方式(直接回滚到上一个版本还是指定的版本);
  1. 如果选择0就直接回退到上个版本，如果选择1则选择指定的版本回退。

如下为非开发环境的BlueOcean:

blueocean

5. 权限管理

针对项目我主要划分了两组权限：

项目开发者流水线界面：

各个应用构建发布的流水线和开发环境回滚的流水线



运维人员非开发环境流水线界面:

如上图，各个项目的uat、生产等环境的发布流水线目录

6. 流水线源码管理

目录结构

Uat和Pro分别放的uat和生产环境的kubernetes资源清单

在上面的第三节中说过“根据选择的环境检出指定源码下的目录文件”，当我们选择Uat环境时，流水线只检出上面Uat目录下的资源清单，当选择生产环境时，流水线只检出Pro目录下的权限，等等如果有其他环境，我们可以继续添加。

当然，开发环境的流水线也可以像这样集中的管理起来，但是没有必要，因为其和源码密切相关分开反而不合适。

jenkins共享库主要的作用就是将pipeline的具体实现封装成方法，可以方便不同的Jenkinsfile调用，一次封装，到处使用。(此处不做详细介绍)

上一篇下一篇

猜你喜欢

热点阅读