在实现了基础的 Jenkins 自动化部署后，为了进一步提升研发效率和流水线的可靠性，我们需要引入 Webhook 触发机制、自定义邮件通知以及条件化构建等高级特性。本文将深入探讨如何基于 Jenkins 与 Docker 实现 .NET Core 项目的进阶持续集成与持续部署（CI/CD）。

一、配置 Webhook 自动化触发机制

通过 Webhook，代码托管平台（如 Gitee、GitHub 或 GitLab）可以在开发者提交代码时自动通知 Jenkins 启动构建任务，无需人工干预。

1. 插件准备

在 Jenkins 插件管理中安装 Gitee 或 Gogs 插件，根据你使用的 Git 托管平台而定。安装完成后，在 Jenkins 项目配置中会看到相应的触发器选项。

2. 生成安全令牌

为了保证通信安全，在 Jenkins 项目的"构建触发器"部分，勾选"Gitee WebHook"，点击"生成"按钮获取 Secret Token。这个令牌将用于代码仓库的身份验证。

3. 代码平台回调设置

登录你的 Gitee 仓库，进入"管理" -> "WebHooks"，点击"添加 WebHook"。

• URL：填写 Jenkins 项目提供的回调地址。
• 密码/令牌：填写上一步生成的 Secret Token。
• 触发事件：通常选择"Push"事件。

配置完成后，每次 git push 都会触发 Jenkins 自动执行流水线。

二、自定义可视化邮件通知

基础的邮件通知过于简单，通过安装 Email Extension 插件，我们可以自定义 HTML 模板，将构建编号、状态、分支、提交摘要及日志链接通过邮件发送给团队成员。

1. 扩展邮件配置

在 Jenkins 系统配置的"Extended E-mail Notification"中设置 SMTP 服务器地址、用户名及密码。随后可定义全局的 HTML 邮件模板。

2. HTML 邮件模板参考

<html>
<body>
    <h2>项目构建报告：${PROJECT_NAME}</h2>
    <table border="1" cellspacing="0" cellpadding="5">
        <tr><td>构建编号</td><td>第 ${BUILD_NUMBER} 次构建</td></tr>
        <tr><td>构建状态</td><td><b style="color:red">${BUILD_STATUS}</b></td></tr>
        <tr><td>触发原因</td><td>${CAUSE}</td></tr>
        <tr><td>控制台日志</td><td><a href="${BUILD_URL}console">点击查看</a></td></tr>
    </table>
</body>
</html>

三、进阶 Jenkinsfile 流水线设计

以下是一个重构后的 Jenkinsfile，支持 Docker 镜像版本化管理、远程 SSH 部署以及构建结果邮件推送。

def targetServer = [:]
targetServer.name = 'ProductionServer'
targetServer.host = '192.168.1.100'
targetServer.user = 'admin'
targetServer.password = 'your-password'
targetServer.allowAnyHosts = true

pipeline {
    agent any

    environment {
        APP_NAME = "core-web-api"
        DOCKER_REGISTRY = "registry.cn-hangzhou.aliyuncs.com"
        REGISTRY_CREDS = credentials('docker-hub-secret')
        PUB_DIR = "${WORKSPACE}/out"
    }

    stages {
        stage('Restore & Build') {
            steps {
                sh "dotnet restore"
                sh "dotnet build --configuration Release"
            }
        }

        stage('Publish Artifacts') {
            steps {
                sh "dotnet publish -c Release -o ${PUB_DIR}"
            }
        }

        stage('Containerize') {
            steps {
                script {
                    sh "docker login -u ${REGISTRY_CREDS_USR} -p ${REGISTRY_CREDS_PSW}"
                    sh "docker build -t ${APP_NAME}:${BUILD_NUMBER} ${PUB_DIR}"
                    sh "docker tag ${APP_NAME}:${BUILD_NUMBER} ${DOCKER_REGISTRY}/${APP_NAME}:${BUILD_NUMBER}"
                    sh "docker push ${DOCKER_REGISTRY}/${APP_NAME}:${BUILD_NUMBER}"
                }
            }
        }

        stage('Remote Deployment') {
            steps {
                sshCommand remote: targetServer, command: """
                    docker pull ${DOCKER_REGISTRY}/${APP_NAME}:${BUILD_NUMBER}
                    docker stop ${APP_NAME} || true
                    docker rm ${APP_NAME} || true
                    docker run -d --name ${APP_NAME} -p 8080:80 ${DOCKER_REGISTRY}/${APP_NAME}:${BUILD_NUMBER}
                """
            }
        }
    }

    post {
        always {
            emailext (
                subject: "构建通知: ${PROJECT_NAME} - Build #${BUILD_NUMBER}",
                body: '${DEFAULT_CONTENT}',
                to: "dev-team@example.com"
            )
        }
    }
}

四、按需触发：基于 Commit Message 的构建过滤

在某些场景下，我们不希望每一次代码提交都触发正式环境的发布。可以通过配置 Gitee 插件的策略，设置"正则过滤"。

例如，在 Jenkins 项目配置中设置：只有当 Commit Message 包含 [release] 关键字时才触发流水线。这样，开发者在日常提交（如修复拼写错误）时，不会造成昂贵的构建资源浪费，只有在确定需要发布时才手动加入关键字触发 CI/CD。