CI/CD

typescript不检查node_moduls

月盾
tsconfig.json 中 exclude node_modules,但 tsc 还是报错。 node_modules/connect-mongo/src/types.d.ts:113:66 - error TS2694: Namespace 'global.Express' has no exported member 'SessionData'. 113 get: (sid: string, callback: (err: any, session: Express.SessionData | null) => void) => void; ~~~~~~~~~~~ node_modules/connect-mongo/src/types.d.ts:114:45 - error TS2694: Namespace 'global.Express' has no exported member 'SessionData'. 114 set: (sid: string, session: Express.SessionData, callback?: (err: any) => void) => void; ~~~~~~~~~~~ node_modules/connect-mongo/src/types.d.ts:118:47 - error TS2694: Namespace 'global.Express' has no exported member 'SessionData'. 118 touch: (sid: string, session: Express.
朱雀发布系统支持scp(rsync)发布

朱雀发布系统支持scp(rsync)发布

月盾
去年花了三天时间开发了一个简易版的nodejs发布系统,它是基于pm2自带的deploy机制开发的,主要原理就是在两台装有pm2的机器直接通信,并执行相应的命令。再往简单了说就是在发布机上远程执行命令,而朱雀发布系统提供了一个图形界面而已。 当时把这个系统定位为nodejs专用发布系统,因为它依赖了pm2,而pm2则是nodejs专用的进程管理工具,其他语言用不到。这个系统的上线也算是解决了我司一直以来没有合适的nodejs发布系统的空缺。 经过9个月的使用,也算比较稳定。但是也存在问题,最大的问题是部署应用方面比较繁琐。 基本流程如下: 发布机和应用服务器设置ssh通信配置。 应用服务器安装git(有自带,但是版本太旧)。 配置git用户名,邮箱。 生成ssh公钥。 把应用服务器的公钥配置到git代码服务器上。以便能拉代码。 发布机远程执行git pull来代码操作,各应用服务把代码拉取下来。 执行编译打包操作。 执行重启服务操作。 部署一次系统还是比较麻烦的,如果应用服务器有多台,可能还要重复这样的操作多次,实在比较麻烦。 使用scp同步代码的方式会比较简单一些,但是像nodejs这样的项目,node_module占了很大比重,如果每次都打包的话会拖慢同步速度,而scp又不具备排除文件夹的能力。 最后找到了rsync命令可以满足需求。然后就是基于rsync实现了一版。不用再依赖pm2,应用服务器也不用强制使用git了。 朱雀和Jenkins对比如何? 要说Jenkins那绝对是持续集成领域的老大哥,自然是功能强大。但是每个团队和产品有其特殊性,Jenkins并不完全适用。而朱雀也有其优势。 朱雀本身部署简单,使用go开发,不依赖运行时,无需安装,开箱即用。 目前支持和测试过的数据库有sqlite3(目前用的,不需要繁琐的安装过程)和mysql。 配置简单。 部署发布一键完成,不需要单独的部署过程。 并行发布。 审批,通知,权限。 开源,可定制开发。 项目地址:朱雀发布系统
nodejs专用发布系统

nodejs专用发布系统

月盾
Nodejs项目部署到服务器以后接下来做的最多的操作就是上线发布了。因为nodejs的语言特性决定了其开发效率高,发布自然就频繁,每个公司或个人都有自己的发布方式。 有的公司会有严格的流程,必须通过CI/CD工具进行发布,有可能使用现成的工具,如:jenkins。有可能是自研发布系统。 有的公司会通过FTP上传代码到服务器发布。 有的公司使用更原始的发布方式,直接登录服务拉代码发布。 不论哪种发布方式都有其优缺点,越高级的工具会有诸多限制,比如有权限控制,有严格的审批流程,自然就不能随时发布,也就越僵化。越原始的方式越简单越灵活,自然风险也越高。 至于采用哪种发布方式,依据需要选择即可。 而关于nodejs的发布方式,本人也是也是多种方式都有使用,公司项目也经历过多次变迁。公司最开始是直接登录服务器拉代码发布,后来有了运维团队,领导说开发自己发布不安全,于是就由运维搭建了Jenkins环境来发布,但是每次发布都需要走流程,后来因为发布太频繁,每1-2天要发布一次,又要灰度发布,运维也会觉得烦。于是开发就搭建了某个发布系统自己来发布,不过这个发布系统有个缺点,就是发布集群的时候是串行的,每次发布要十几分钟。 另外说明一下Jenkins。它应该是使用最多的发布系统了,Jenkins基于Java开发,它已经是成熟的系统了,成熟同时也代表着复杂,复杂代表修改困难,我想大家也不太会基于Jenkins定制开发。 然后是部署困难,相比较nodejs三条命令搞定linux安装nodejs——快捷版,go直接放二进制文件部署,Jenkins部署可能就略显复杂了。 于是下定决心自己开发一个发布系统,朱雀发布系统因此诞生。 基于以往的发布系统使用经历,我想要的是一款使用够灵活,部署够简单的发布系统。市面上现有的系统为了满足各种语言的发布,做的大而全。我自然是不想重蹈覆辙再做一个大而全的系统,我要的是小而美。正好之前了解过PM2本身集成了远程发布功能,可以在此基础上开发。PM2本身的发布过程其实已经很简单了,而且足够灵活,能够满足我的部分要求,但是公司的环境是不能在本地直接连接应用服务器的,所以需要一个中间层代理一下,放一张简单的架构图: 和其他工具架构逻辑一样,都是通过ssh来通信,不同的是朱雀没有直接使用ssh,而是利用了pm2,由pm2来实现通信,它已经为了做了一部分工作,比如拉代码,回滚,执行远程脚本。 由于nodejs的项目特性,它依赖了node_modules包,如果按照打包的方式发布会又大又费时,所以还是选择拉git代码的方式发布比较合适。 所以我只需要给它做一个图形界面,并有一定的管理和审批流程(可根据环境跳过)。 放一张图来看一下: 项目地址:nodejs发布系统 朱雀发布系统支持scp(rsync)发布