通知与协作集成

构建结束不通知 = 没有反馈。通知要解决两个问题：谁关心结果（开发者、值班群、管理员）和什么样的结果需要通知（成功/失败/恢复）。

本篇目标：能对接飞书、钉钉、企业微信、邮件等渠道，用 post 按结果分级发送通知，并避免通知风暴。

---

1. 通知方式对比

渠道	插件 / 方式	适用
飞书	飞书 Webhook 插件 / sh curl	国内团队即时消息
钉钉	钉钉 Webhook 插件 / sh curl	国内团队即时消息
企业微信	企业微信群机器人 / Webhook	国内团队即时消息
Slack	Slack 插件	国际团队
邮件	Email Extension 插件	正式记录、异步通知
自建	自定义 Webhook / 内部平台	已有一体化告警平台

优先用 Webhook 直发，少装插件

飞书/钉钉/企业微信本质上都是"向机器人 Webhook POST JSON"。用一个 sh curl 步骤就能实现，不必为每个渠道装插件。把通知逻辑放进共享库（第 8 篇），各团队复用。

2. Webhook 通知实现

2.1 飞书机器人

// 共享库：vars/notifyFeishu.groovy
def call(Map config) {
    def webhook = config.webhook
    def title = config.title
    def text = config.text
    sh """
        curl -s -X POST '$webhook' \
          -H 'Content-Type: application/json' \
          -d '{
            "msg_type": "text",
            "content": {
              "text": "[$title] $text\\n${env.BUILD_URL}"
            }
          }'
    """
}

2.2 钉钉机器人

sh """
    curl -s -X POST '$DINGTALK_WEBHOOK' \
      -H 'Content-Type: application/json' \
      -d '{
        "msgtype": "text",
        "text": {"content": "$BUILD_RESULT: ${JOB_NAME} #${BUILD_NUMBER}\\n${BUILD_URL}"}
      }'
"""

机器人关键字

飞书/钉钉机器人默认有"关键字 / 加签 / IP 白名单"安全校验。配置 Webhook 后先在本地 curl 测一条，确认消息能收到，再接入流水线，否则排障时很难分清是通知问题还是构建问题。

3. 在流水线中按结果通知

pipeline {
    agent any
    environment {
        // 从凭证引用（第 4 篇），不要写死
        FEISHU_WEBHOOK = credentials('feishu-ci-webhook')
    }
    post {
        always { cleanWs() }
        success {
            notifyFeishu(
                webhook: env.FEISHU_WEBHOOK,
                title: '✅ 构建成功',
                text: "${env.JOB_NAME} #${env.BUILD_NUMBER}"
            )
        }
        failure {
            notifyFeishu(
                webhook: env.FEISHU_WEBHOOK,
                title: '❌ 构建失败',
                text: "${env.JOB_NAME} #${env.BUILD_NUMBER}"
            )
        }
    }
}

3.1 分级通知策略

结果	通知对象	内容
成功	项目群（可选）	简洁：Job + 构建号 + 链接
失败	项目群 + 责任开发	含失败 stage、日志链接、提交人
恢复	项目群	"已恢复正常"，标记曾失败
超时/取消	运维群	关注资源与卡顿

// 失败时带更多上下文
failure {
    notifyFeishu(
        title: '❌ 构建失败',
        text: """
            Job: ${env.JOB_NAME}
            构建: #${env.BUILD_NUMBER}
            提交: ${env.GIT_COMMIT}
            失败 stage: ${currentBuild.currentResult}
            日志: ${env.BUILD_URL}console
        """
    )
}

4. 邮件通知（Email Extension）

Manage Jenkins → System → Extended E-mail Notification
SMTP server: smtp.company.com
Default recipients: devops@company.com

post {
    failure {
        emailext(
            subject: "❌ 构建失败: ${env.JOB_NAME} #${env.BUILD_NUMBER}",
            body: "日志: ${env.BUILD_URL}console\n提交: ${env.GIT_COMMIT}",
            to: 'team@company.com',
            attachLog: true
        )
    }
}

邮件 vs 即时消息

即时消息快、适合值班和开发；邮件正式、可归档，适合周报和审计。两者结合：失败即时消息 + 关键发布邮件留痕。

5. 避免通知风暴

手段	说明
只在结果变化时通知	用 changed 条件，避免每次都刷
失败收敛	连续失败只发一次 + 恢复通知，避免轰炸
按 Job 分级	核心 Job 通知值班群，边缘 Job 只进日志
通知合并	批量失败汇总一条（配合定时任务统计）
Webhook 限流	通知步骤加 sleep / 幂等，防循环触发

post {
    // changed：只在结果变化时通知，避免成功也每次都发
    changed {
        notifyFeishu(title: "结果变化: ${currentBuild.currentResult}", ...)
    }
}

6. 集成到统一告警

如果团队已有 Prometheus + Alertmanager 或一体化运维平台，可以让 Jenkins 构建事件作为指标/告警源：

Jenkins 暴露 /prometheus 指标（Prometheus 插件）
  → 构建失败次数、排队时长、构建时长
  → Alertmanager 规则：构建失败率突增告警

详见监控 / Prometheus 手册。

---

7. 练习与验收

练习 A

1. 创建飞书或钉钉机器人，获取 Webhook，用 curl 手动发一条测试
2. 把 Webhook 存入 Jenkins 凭证，流水线 post 中成功/失败各发一条
3. 故意让构建失败，确认收到失败通知

练习 B

1. 配置 Email Extension，失败时发邮件并附日志
2. 用 changed 让通知只在结果变化时发送
3. （可选）接入 Prometheus 的 Jenkins 指标，观察构建失败率

验收清单

• 会对接飞书 / 钉钉 / 企业微信至少一个渠道
• 会用 post 按结果分级发送通知
• 理解 changed 和收敛策略避免通知风暴
• 会用 Email Extension 做正式留痕
• 知道通知逻辑应放共享库复用

下一篇：主从架构与性能调优。