jenkins回滚,jenkins回滚nodejs

jenkins 怎样将代码回滚到上个版本

可以写一个回退版本的脚本命令，那些版本都在服务器上保存着，手工操作也是可以的，就是麻烦一点??网页链接

GO服务运维实践

在ezbuy业务里，GO服务被大规模的用在我们后端服务上，那么我们是如何运维GO服务的呢？我们分以下3个类别说起：

针对新的项目在uat上线，我们会通过CMDB工单系统，让开发提交工单填写项目名称，工单系统首先会通过gitlab api查看这个项目是否在gitlab有，如果没有，拒绝在uat上线，如果有则调用jenkins的api，通过jenkins模版在所有的uat环境生成uat项目。

针对已有的uat项目，通过gitlab的webhook功能，开发在提交分支的时候自动触发gitlab webhook功能，从而jenkins会自动执行编译步骤，编译成功后会解析每个项目下的conf.ctmpl配置文件，通过这个配置文件我们可以发现服务所需要暴露出来的端口，然后通过 Dockerfile模版文件生成Docker镜像，最后通过docker api下发到docker宿主机子上。

针对GO服务的配置文件，我们统一通过consul key 来实现，这样可以保持uat和线上一致

开发在合并master分支的时候，会自动触发webhook,实现jenkins编译go，编译通过后上传到svn，然后可以根据项目的选择调用CMDB api直接发送到线上，也可以不掉用CMDB api，通过登录到CMDB运维平台，手动发布到线上，如果线上发布失败，系统会自动回滚到上一个稳定的版本，发布后会调用钉钉和企业微信at到发布本人，全程发布运维不干预，发布权限下发到每个开发手中。

所有的GO权限都下发到每个开发手中，开发可以通过cmdb平台实时看到自己的服务运行状态，重启/停止服务，版本回滚，GO cronjob下发，cronjob列表查询，脚本运行

GO服务上线：

GO自动发现注册：

GO服务日志：

GO服务监控：

关于GO服务的运维我们暂时介绍到这，下一篇介绍下GO服务在运维的架构，尽请期待。

Windows使用Jenkins构建前后端分离项目+项目回滚和备份

公司服务器把Jenkins安装在了Windows上，很多构建都需要使用dos命令，十分难受，写这篇文章记录一下遇到的坑。

原本是想部署之后运行即可，结果还要备份。上网查了一下，有用 ThinBackup 插件进行备份的，还有自己创个目录备份的……五花八门。于是我先选择了自己创个目录备份的方案，设想是这样的：

结果说怎么可以是手动回退呢，让我改。再加上第4点用bat实在太难写了，于是就改成用Jenkins自带的备份（或者说是将生成的文件进行保存）。自带的备份方式如下：

这里使用到了 Jenkins的环境变量 。备份文件的路径和配置详见第5步。

还有更方便的 ，直接更改ProcessTreeKiller正在寻找的环境变量 BUILD_ID 即可暂时禁用ProcessTreeKiller。官网只给出了Shell命令的写法，在运行jar之前写上

BUT，我们是Windows， 故应该改成

之后再用Linux的 nohup 或者Windows的 javaw 命令即可后台运行jar包了。

还有一个打印日志的问题：在Linux中使用 nohup 命令还好办；而在Windows中，单独使用 javaw 命令并配合管道工具（ 和 ）可以打印日志，但即使改变了BUILD_ID，Jenkins也不会关闭，会一直提示“构建中”。我们使用了start命令，但是start命令只能运行一个命令，会忽略掉后面的管道工具，从而不能打印日志。解决方案是，写一个bat命令保存在本地，并使用外部参数来作为jar包的路径和日志的路径。bat命令内容如下：

上面的命令行则变成：

日志就会保存在每次构建的目录中。其中的 BUILD_NUMBER 即构建的序号。

后端写好了前端就好办了，直接照前端办即可。我的步骤是：

在前端部署之前，需要通过nginx反向代理将后端端口挂载到80端口的路径上，这里就不详说了。特别坑的地方是，反向代理有时候不能生效，是因为反复打开关闭nginx过程中产生了好几个nginx进程，把它们全部关闭再重新打开，反向代理就能够生效了。