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 签名验证

