Skip to content

Latest commit

 

History

History
executable file
·
141 lines (98 loc) · 7.38 KB

01.webhooks.md

File metadata and controls

executable file
·
141 lines (98 loc) · 7.38 KB

webhooks

<style>.github-corner:hover .octo-arm{animation:octocat-wave 560ms ease-in-out}@keyframes octocat-wave{0%,100%{transform:rotate(0)}20%,60%{transform:rotate(-25deg)}40%,80%{transform:rotate(10deg)}}@media (max-width:500px){.github-corner:hover .octo-arm{animation:none}.github-corner .octo-arm{animation:octocat-wave 560ms ease-in-out}}</style>

背景

公司用 github 管理项目，而且这些项目（包括纯静态和 node APP）大都是我们自己上服务器部署的

场景

我正在埋头写代码，突然，

  • pm 过来说：xxx 项目改个东西，很简单（例如换个图片，按钮，文案。。。）

  • 我：哦，那就改呗，按要求先在本地，切到 test 分支改动后的上测试步骤：

    • git add .
    • git commit -m fix(xxx): xxx
    • git fetch upstream test
    • git rebase upstream/test test 合并 conflict 后
    • git push upstream test

    以上只是把 test 分支代码同步到 github 上，接下来，还要上服务器 pull 代码，重启项目：

    • ssh ubuntu@xxx
    • tmux a -t xxx
    • git checkout test
    • git log
    • git pull origin test
    • npm run build:test

    现在成功上到测试了，看看效果，没问题就要上到生产了，步骤和上面差不多，先切到生产（我的是：next 分支）上生产步骤：

    • git fetch upstream next
    • git rebase upstream/next next
    • git merge test，合并 conflict 后
    • git push upstream next

    以上只是把 next 分支代码同步到 github 上，接下来，还要上服务器 pull 代码，重启项目：

    • ssh ubuntu@xxx

    • tmux a -t xxx

    • git checkout next

    • git log

    • git pull origin next

    • npm run build:next

      终于完成领导交给的任务了，就为了一个小小的改动，用了这么多步骤，是不是很蛋疼，过了一会儿，pm 又跑过来说还有一个地方要改。。。

以上经历是否有过呢

确实太繁琐了，为了简化开发，js 已经在工程化方面做的不错了，由前些年的 grunt ，到 glup ，又到现在的 webpack ，以及 rollup ，可以说是很成熟了，但是项目部署，可能很多前端小伙伴接触的还不多，可能只是打包出文件（ dist ）甩给后端

接下来我就讲讲如何简单的优化这些繁琐的步骤，不依靠ci，仅仅借助webhooks来简单的实现

那么什么是 webhooks

  • 简单的来说是一种回调，和异步编程中的"订阅-发布模式"很类似，一端触发事件，一端监听执行，webhooks 是异步编程模型的一种实现，具体的可以看webhooks

流程

  1. git push xxx 本地代码提交至远程 github 仓库
  2. github 仓库收到 push 后进行回调，发 post（ Payload url 是来自 webhooks 的配置）请求
  3. 基于 Payload url 的服务根据传回来的信息进行提取，拉取最新代码并重新构建项目
  4. 可以看到，我们只需把代码提交到 github 仓库即可，不用再上服务器进行一些列的操作了

img

开始

  1. 搭建 github-hook 服务

    • 目的是为 webhooks 提供 payload url，并取得 github 回调发来的信息，执行构建部署命令

    • 选择：

      a. copy 我的github-hook，基于 koa b. 用这个自己写github-webhook-handler，基于 node 原生 http 服务的 c. 其他

    • 介绍一下我的 github-hook :

      目录:

      .
├── README.md
├── config
│   ├── data.example.js
│   ├── data.js （配置项目的 dir/分支/启动命令）
│   └── index.js （配置secret，与github的webhooks配置相同）
├── ecosystem.config.js （pm2启动配置文件）
├── package-lock.json
├── package.json
└── src
    ├── controlers
    │   └── token.js （用于生成token，webhooks加密用）
    ├── index.js （启动文件）
    ├── jobs
    │   └── index.js （解析回调发来的信息，执行命令）
    └── routes
        └── index.js （路由，处理请求）

  2. 在服务器启动 github-hook 服务

    • 登录服务器，进入工作目录（我的是 /var/nodejs ，可根据喜好自己改，别忘了改对应的 config/data.js 文件的 DIR ）
    • git clone xxxgithub-hook.git
    • cd github-hook
    • npm i
    • npm run start ，用的是pm2，请先全局安装 pm2
    • curl ip:9002 ，若有 success 字样，则成功
      • 注：本服务的端口是 9002，若已占用，请自行更改 /index.js ，别忘记安全组开放端口

  3. github 配置 webhooks

    打开 github，找到要配置的项目，进入 setting-->webhooks-->新增一个：

    • Payload URL: 输入上一步测试的 api，即 http://ip:9002/payload/{reponame} ，我这里的 reponame 即 github-hook
    • Content type：选择 application/json
    • Secret：与上面 /config/index.js 中的 appSecrcet 保持一致
    • Which events would you like to trigger this webhook？选择第一项 Just the push event 即可
    • 配置完成，提交即可，配置后如下图： img

  4. 测试

    在本机更改 github-hook 代码，提交，然后打开刚刚的 github 页面看看下面是否有 Recent Deliveries：

    img

结语

  • 不需要登录服务器，pull 代码，重启服务，直接在本地提交代码就可以重新构建部署是不是提高了效率？
  • 当然这只是简单的应用，想要更好地管理还是要靠 ci 系统，在版本回退，单元测试等方面更完善，也就是我下次要讲的，将项目放到 docker 容器中 "用 jenkins 打包构建部署项目"

== ps: ==刚开始写东西，以前没有这个习惯，还请多多提意见，谢谢~