使用Webhook实现前端自动发布

本文将会涉及的内容—

Webhook是啥？什么时候该使用它？

该怎么利用Webhook解放我们的双手？

小结

Webhook是啥？什么时候该使用它？

以我司为例，我们团队内部使用Gitlab作为代码仓库，所以以下内容都是在Gitlab中进行实践的，当然在Github上其实也是大同小异的。

Webhook顾名思义，其实就是一钩子。当我们在Gitlab上做出某些特定操作时，可以触发钩子，去进行一些我们事先设定好的脚本，以达到某些特定功能（例如—前端项目自动发布）。

也许熟悉Gitlab的同学会说了，这不就是CI吗，为什么好好的CI放着不用要去搞webhook呢？确实，CI也能完成一样的功能，但是也要结合业务实际状况而言。该项目并非公司核心项目，跑CI的runner需要有Gitlab控制权限的同事帮忙配置，本着不骚扰同事的原则，个人认为应该自己动手丰衣足食，既然有简单便捷的webhook为什么不用呢？

什么时候才应该去使用它呢？个人认为至少要有这几点：

项目不是一成不变的

你是项目的负责人

你有权限进入部署项目的服务器

你能挤得出时间来踩坑

该怎么利用Webhook解放我们的双手？

上图是Gitlab中有关webhook的配置页面，当我们成功进行了[Trigger]内部的某些或某些操作时，比如Push events—成功push了一次代码，无论是向哪个分支push，都可以触发hook……

之后Gitlab将会自动的替我们向URL中的链接发去POST请求，这里可以是脚本也可以是服务，只要能够成功接收来自Gitlab的请求即可。在本次实践中，我起了一个node服务来帮助完成自动化部署。

那么就有一个问题了，请求那个URL就会触发node服务中的部署流程，那么万一有人一直在玩那个接口，会不会把服务搞挂或是把网站搞挂呢？还真有可能…所以Gitlab给了我们设置Secret Token的机会，我们检测到请求有带有这段特殊的token才能认为本次请求是安全可接受的。

It will be sent with the request in the X-Gitlab-Token HTTP header.

这里需要注意一下的是，实际上我们并不会找到X-Gitlab-Token这个请求头，我们只会匹配到x-gitlab-token这个字段，别问我为什么知道的，大家注意避坑就好:)

下面讲讲在服务器上我们是怎么接收Gitlab的请求并且执行部署的—

在项目部署的机器上，跑了这个简单的node服务，大意是当Gitlab POST一个请求过来时，我们进行鉴权，随后通过node去执行一段命令行语句，根据执行的结果调用不同的方法。这里有几个坑点—

node服务搭建

贪图方便，依赖了一下express，当然我们是可以用http模块来完成这些操作的，另外监听端口的时候需要确认当前端口是否可被外网访问。

node执行服务器命令行

我们可以使用node中’child_process’模块的exec方法来执行命令行语句，将定义好的命令行语句字符串传入exec方法作为第一个参数即可，后面一个参数则是执行结果的回调，依照业务需要设计即可。

发布鉴权&&发布状态

通过Gitlab请求中带来的token来鉴定本次请求是否能够触发下面的部署，并且需要设定一个”发布中”的状态，防止多次请求带来的各种无法预知的后果。

上面的代码只是最基本的发布服务，在里面可以做任何事，发布完成或失败的各种通知，甚至还可以对提交的代码进行检测，倘若不符合规范还可以拒绝本次自动部署……只要想踩坑，一切皆有可能~这样反映出webhook的灵活，只需对git做一个简单的操作，就可以推倒多米诺骨牌，完成一些意想不到的操作。

小结