CI(持续集成),每次代码更新时,通过自动化任务将改动应用到服务器。CI对编译型语言很友好,比如一个企业级的Java程序启动,需要一连串的N个步骤,不仅繁琐还费时,有时仅仅是一些小改动,就叫人重复做一些不必要的工作。
比如老牌的自动集成软件Jenkins,就做的非常好,通过它的GUI,开发者可以很直观的了解当前项目的状态。并且随着CI的发展,应用程序容器化也成了一种趋势,有一段时间,似乎不用用Docker和K8S就不配叫做程序员(可能现在也是),还诞生了一个离谱的词汇(DevOps)…
声明一点,我很喜欢Jenkins,如果让我用Java或者一些其他的重型语言开发一个大项目,我肯定也会考虑使用它。但问题是,有些很小的项目……我觉得都不需要使用这么重的东西。
当然,是个人都会想要偷懒,不管这个项目有多小…
比如,一个node后端项目,在每次代码更新时,可能只需要 拉取代码
-> 编译源码
-> 重启服务
这么三个步骤。
那么,我们要做的事,就是捕获到代码推送事件(push event),然后执行上面的三步操作。
捕获”推送事件”
以代码托管平台Github
为例(见下图):
- Payload URL 是你App用来接受推送事件的网关
- Secret 是稍后用于验证签名的key
在App的路由中,捕获此事件:
1 | /** |
我没有在这个路由里执行更多的操作,只是简单的增加了API_VERSION
的版本数。
⚠️ 注意:
如果你的App在单例模式下运行,那么你可以在这个路由中做完所有事,但是如果你的App运行多台服务器上,并且通过一个负载均衡扩展,那么你不能在这个路由中继续其他操作,因为一个推送事件,最终由一个选定的App运行,当存在跨越式更新时,会导致API的表现不一致,不仅对用户造成体验上的割裂感,更严重的是可能让数据发生不可预期的变动。
剩下的事
通过WebHook,我们的API版本得到更新,现在我们可以使用一个定时任务,比如每分钟/每小时/每天进行版本检查,也可以写到一个路由里由我们手动触发,或者,放到一个用于负载健康检查的路由中,都可以。
记住我们的宗旨: 不要复杂,要简单
1 | api.get('/check_loop', async (req, res) => { |