Webhook 自动化部署实战配置
重复部署这件事，最适合交给 webhook。它不复杂，但很适合做成一套稳定的自动化流程：代码一推送，服务器就按预设脚本跑完构建和部署，省掉手工登录、复制命令、反复确认这几个最容易出错的环节。
webhook 到底解决什么问题
webhook 本质上就是一个接收外部 HTTP 请求的入口。请求到达后，它根据配置去执行对应的 shell 命令。和传统的定时任务不同，它是事件驱动的，触发点通常来自 Git 提交、CI 状态变化，或者其他系统发来的通知。
它带来的好处很直接：
- 触发快，推送后马上能开始部署
- 流程固定，每次都走同一套脚本
- 少一些人工介入，出错概率也低一点
当然，它也不是'连上就能放心不管'。触发规则和签名验证没配好，自动化反而会把风险放大。
项目准备
先把 webhook 项目拉下来并编译：
git clone https://github.com/adnanh/webhook
cd webhook
go build
构建完成后，核心工作其实就变成两部分：写 hooks 配置，写部署脚本。
基础配置
在项目根目录创建 hooks.yaml：
- id: auto-deploy
execute-command: /scripts/deploy.sh
command-working-directory: /var/www
response-message: 自动化部署任务已启动
pass-arguments-to-command:
- source: payload
name: head_commit.id
这个配置的意思很简单：收到匹配的请求后，执行 /scripts/deploy.sh，工作目录切到 /var/www，并把提交 ID 传给脚本。
部署脚本可以写成这样：
#!/bin/bash
echo "开始自动化部署流程..."
cd /var/www
git pull origin main
npm install && npm run build
echo "部署完成！提交 ID: $1"
这套脚本够朴素，也够实用。很多场景里，能稳定跑通比写得漂亮更重要。
安全配置别省
自动化部署最容易忽略的就是安全。没有校验的 webhook，基本等于把执行入口直接暴露出去。
HMAC 签名验证
