Global Vars vs. Class Implementations

我们很少使用全局变量的方式来实现共享库，主要原因是：
1）全局变量，其难以进行层次化的组织和管理；

Declarative vs. Scripted

我们将采用指令式流水线，其是 Jenkins Pipeline 的新特性，也是官方推荐的做法；

Shared Libraries vs. Jenkinsfile

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

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

共享库的包组织方法

共享库及流水线使用 Groovy 语言，程序文件以包的方式存在，那应该如何组织这些包呢？

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

最后，在 Jenkinsfile 中，通常调用「应用逻辑」包中的实现来完成具体任务；

是否开发公共类库

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

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

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

关于配置文件

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

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

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