「Jenkins Pipeline」- 实践经验

  CREATED BY JENKINSBOT

本文将记录与 Jenkine Pipeline 有关的实践经验。

我们的自动化构建流程

开发提交代码到代码服务器(GitHub Gitlab BitBucket)
代码服务器通过 WebHook 触发 CI/CD(Codeship、Shippable、CircleCI、Jenkins)
CI 服务拉去最新的代码,构建 Docker 镜像,进行测试
自动集成测试完成后,将镜像推送到私有的 Registry
运维使用最新的 Docker 镜像进行部署

Shared Libraries VS. Jenkinsfile

为了保证流水线代码的可读性与可维护性,我们遵循以下原则:

	在Shared Libraries中,实现核心的流水线功能。此举是为了实现代码复用以及核心逻辑的统一调整,保证流水线代码的可维护性。
	在Jenkinsfile中,调用在共享库及全局变量中的实现。此举是为了降低Jenkinsfile编写难度,保证Jenkinsfile的可读性。在Jenkinsfile中,看到的是流水线的“框架”(像伪代码),能够直接体现流水线的过程,但是不会看到内部实现。

此原则适用于“多数项目的自动化流程相似”的场景。

共享库的包组织方法

问题描述:共享库及流水线使用Groovy语言,程序文件以包的方式存在,那应该如何组织这些包呢?

解决方法:在包分类方面,我们遵循如下原则:

	**配置分类。**定义在程序中使用的常量、服务器信息、证书ID值等等,将常用且易变常量分离出来。
	**底层实现。**该类型的包进行壹些基础的操作,类似于工具类库。比如使用RSYNC、FTP发布,使用邮件、即时消息通知等等。可以有多个包,比如notify、publisher、util等等。
	**应用逻辑。**该类型的包实现业务功能,更贴近于应用层,使用「底层实现」完成某些功能。允许在Jenkinsfile中调用。

因此,在Jenkinsfile中通常调用「应用逻辑」包中的实现。

是否开发公共类库

问题描述:
因为需要为不同的组织开发共享库,他们之间会涉及很多通用方法(比如消息通知、程序发布等等)。那我们是否应该开发独立的「底层实现」,以类库形式存在,然后在所有组织中引入该共享库呢?

解决方法:
我们还是决定不要这么做,而是:(1)仓库代码分为两部分:公共代码与组织代码。(2)然后将公共代码与组织代码同步到特定仓库中。

如果独立出来,只能达到“美观”目的,并没有减轻太多维护成本,多个仓库的更新及维护反而更加繁琐。另外这种场景并不多见。

关于配置文件

“项目组”配置文件的最小粒度,同项目组的项目应该具有相同的部署模式。

具有“固定模式”才可以进行自动化。这就要求部署到服务器的应用经过规划,不能部署到随意的目录。即以组为单位,将某类应用部署到某个目录下。

或者以项目组为单位,某个项目组的单位部署到特定目录。