jenkins配置多分支流水线

**当 Jenkinsfile 不在业务代码仓库中时，如何配置多分支流水线（Multibranch Pipeline）**。

这是一个非常常见的最佳实践，特别是在企业级开发中，将 CI/CD 逻辑（Jenkinsfile）与业务代码分离，可以实现更好的管理和复用。

实现这个目标的核心是使用 Jenkins 的 **“Branch Source”** 插件（通常是 `Pipeline Multibranch` 插件）并结合 **“Pipeline from SCM”** 的配置，但需要进行一些特殊设置。

下面我将为你详细介绍两种主流的实现方式，并提供完整的步骤和代码示例。

### 核心思路

多分支流水线的核心是自动发现代码仓库中的所有分支，并为每个分支创建一个对应的流水线项目。当 Jenkinsfile 不在业务仓库时，我们需要告诉 Jenkins：

1.  **去哪里找业务代码分支**（这是多分支的基础）。
2.  **对于每个找到的分支，去哪里找对应的 Jenkinsfile** 来执行构建。

---

### 方法一：使用 "Pipeline from SCM" 并指定 Jenkinsfile 路径（推荐）

这是最直接、最常用的方法。它仍然利用了多分支流水线自动发现分支的能力，但在构建配置中动态指定 Jenkinsfile 的位置。

#### 前提条件

1.  你已经安装了 **Pipeline Multibranch** 插件。
2.  你有一个存放所有 Jenkinsfile 的**共享库仓库**（例如 `https://github.com/your-company/jenkins-pipelines.git`）。
3.  你的业务代码仓库（例如 `https://github.com/your-company/my-app.git`）已经配置好与 Jenkins 的连接（如 SSH 密钥或用户名/密码）。

#### 配置步骤

1.  **在 Jenkins 中创建一个新的“Multibranch Pipeline”项目**。
2.  **在“Branch Sources”部分，点击“Add source”**，选择你的代码仓库类型（如 Git）。
3.  **配置业务代码仓库的信息**：
    *   **Project Repository**: 填写你的业务代码仓库 URL (e.g., `https://github.com/your-company/my-app.git`)。
    *   **Credentials**: 选择或添加能够访问该仓库的凭证。
    *   **Behaviors**: 这里可以配置分支发现规则，例如只发现 `main`/`master` 和 `develop` 分支，或者基于命名模式（如 `feature/*`）。保持默认通常也可以，它会发现所有分支。
4.  **关键步骤：配置 "Build Configuration"**
    *   在“Build Configuration”下拉菜单中，选择 **"Pipeline script from SCM"**。
    *   **SCM**: 再次选择 Git。
    *   **Repository URL**: 这次填写你的**共享库仓库**的 URL (e.g., `https://github.com/your-company/jenkins-pipelines.git`)。
    *   **Credentials**: 选择或添加能够访问**共享库仓库**的凭证。
    *   **Branch Specifier (blank for 'any')**: 这里是一个关键点。你需要指定从共享库的哪个分支获取 Jenkinsfile。
        *   **固定分支**：如果你所有业务分支的构建逻辑都一样，或者你希望统一由共享库的某个分支（如 `main`）来管理，你可以直接填写 `*/main`。这意味着无论业务代码是哪个分支，都会使用共享库 `main` 分支下的 Jenkinsfile。
        *   **动态分支**：如果你希望为业务代码的不同分支（如 `feature/login`）匹配共享库中同名的分支（如 `feature/login`），你可以使用 Jenkins 的环境变量 `${BRANCH_NAME}`。填写 `*/${BRANCH_NAME}`。**注意**：这种方式要求你的共享库中必须存在与业务分支同名的分支，否则构建会失败。
    *   **Script Path**: 填写 Jenkinsfile 在共享库仓库中的相对路径。例如，如果你的 Jenkinsfile 存放在 `pipelines/my-app/Jenkinsfile`，那么这里就填写 `pipelines/my-app/Jenkinsfile`。

5.  **保存配置**。

#### 这种方法的优点

*   **配置简单**：所有配置都在一个地方完成。
*   **逻辑清晰**：明确指定了业务代码源和构建脚本源。
*   **灵活性高**：可以灵活控制共享库的分支策略。

---

### 方法二：使用 Jenkins 共享库（Shared Library）

这是一种更高级、更符合“基础设施即代码”理念的方法。Jenkinsfile 变得非常简洁，只负责调用共享库中定义好的函数。

#### 前提条件

1.  你已经安装了 **Pipeline Shared Groovy Libraries** 插件。
2.  你有一个 Git 仓库作为**共享库仓库**。
3.  你已经在 Jenkins **系统配置**中全局配置了这个共享库。

    *   进入 **Manage Jenkins > System > Global Pipeline Libraries**。
    *   点击 **Add**。
    *   **Name**: 给你的库起一个名字，例如 `my-company-pipelines`。这个名字会在 Jenkinsfile 中使用。
    *   **Default version**: 可以指定一个默认分支，如 `main`。
    *   **Retrieval method**: 选择 `Modern SCM`。
    *   **Source Code Management**: 选择 Git，并填写共享库的仓库 URL 和凭证。
    *   保存。

#### 配置步骤

1.  **在共享库仓库中编写构建逻辑**。
    创建目录结构 `vars/`，并在其中创建一个 Groovy 文件，例如 `buildMyApp.groovy`。

    `// vars/buildMyApp.groovy`
    ```groovy
    def call() {
        pipeline {
            agent any

            stages {
                stage('Checkout') {
                    steps {
                        // 注意：这里的 checkout scm 会 checkout 触发构建的业务代码仓库
                        checkout scm 
                        echo "Checked out business code from branch: ${env.BRANCH_NAME}"
                    }
                }
                stage('Build') {
                    steps {
                        echo "Building the application..."
                        // sh 'mvn clean package'  // 示例命令
                    }
                }
                stage('Test') {
                    steps {
                        echo "Running tests..."
                        // sh 'mvn test' // 示例命令
                    }
                }
                // ... 其他阶段
            }
        }
    }
    ```

2.  **在业务代码仓库的每个分支中添加一个极简的 Jenkinsfile**。
    这个 Jenkinsfile 的唯一作用就是加载共享库并调用其中的函数。

    `// Jenkinsfile (放在业务代码仓库的根目录)`
    ```groovy
    @Library('my-company-pipelines') _ // 'my-company-pipelines' 是你在系统配置中给共享库起的名字

    buildMyApp() // 调用共享库中定义的 buildMyApp 函数
    ```
    *注意*：文件名必须是 `Jenkinsfile`，并且要提交到业务代码仓库的每个分支中。虽然每个分支的 Jenkinsfile 内容一样，但它的存在是触发多分支流水线的必要条件。

3.  **在 Jenkins 中创建“Multibranch Pipeline”项目**。
    *   **Branch Sources**: 添加你的**业务代码仓库**。
    *   **Build Configuration**: 选择 **"Jenkinsfile"**。
    *   **Script Path**: 填写 `Jenkinsfile` (因为它现在在业务代码仓库的根目录)。

#### 这种方法的优点

*   **极高的复用性**：构建逻辑集中管理，多个项目可以共享。
*   **业务代码仓库干净**：业务仓库只关心业务逻辑，CI/CD 逻辑的变更不会污染业务提交历史。
*   **易于维护和版本控制**：共享库本身就是一个代码仓库，可以进行版本管理、Code Review 等。
*   **Jenkinsfile 极简**：业务仓库中的 Jenkinsfile 非常简单，几乎不需要修改。

### 总结与对比

| 特性 | 方法一 (指定 Jenkinsfile 路径) | 方法二 (共享库) |
| :--- | :--- | :--- |
| **复杂度** | **低** | **中** |
| **适用场景** | 单个或少数几个项目，CI/CD 逻辑相对独立。 | 多个项目，希望统一 CI/CD 标准和实践。 |
| **业务仓库** | 不需要包含任何 Jenkinsfile。 | 需要在每个分支包含一个极简的 Jenkinsfile。 |
| **配置位置** | 多在项目配置中。 | 大部分逻辑在共享库代码中，项目配置很简单。 |
| **灵活性** | 很高，可以为不同项目指定不同的 Jenkinsfile 路径。 | 非常高，通过函数参数可以实现高度可配置的流水线。 |
| **维护成本** | 中，如果逻辑变更，需要修改项目配置。 | **低**，逻辑变更只需更新共享库，所有引用项目自动生效。 |

### 最佳实践建议

*   **对于中小型团队或项目**，**方法一** 通常就足够了，它简单直观，容易上手。
*   **对于大型团队或拥有多个项目的组织**，强烈推荐 **方法二**。它能带来更好的一致性、可维护性和开发效率，是 Jenkins 流水线的“黄金标准”。

无论选择哪种方法，核心都是将业务代码和构建逻辑解耦，这是现代化 CI/CD 实践中的重要一环。