在非云原生的持续部署方面，目前主要有两种持续部署的方案，一种是由客户端主导的持续部署，一种是以jenkins为例子，使用jenkins在服务端部署jenkins服务和各种制品库和依赖组件，做持续部署。
那么为什么要做持续部署呢？比如，我们有好几个服务，假如需要经常发布，上云的时候没有持续部署流水线的话，每次都需要使用sftp工具上传到跳板机，再由跳板机部署到好几台服务器，操作太麻烦，太容易出错。
好了，先说下两种部署方式的优缺点：
（1）服务端主导的部署流水线
这里以jenkins为例子，因为jenkins比较经典，很多人都使用过。
流水线的逻辑由jenkins脚本来实现，使用者要有一定的jenkins脚本技术，指定流水线的流程。比如拉取git仓库最新代码、执行mvn package、npm run build或者npm run build等命令，执行编译。然后编写scp脚本或docker打包脚本，将运行文件推送虚拟机或者docker镜像仓库，最后再编写脚本启动服务或者通过docker/j8s命令启动服务。
这里可以看出，jenkins属于重量级持续部署的方案，需要安装很多的依赖。比如git客户端、git制品仓库、maven制品仓库、npm制品仓库、maven客户端、node客户端等等。而这些环境，一般是我们开发机所具备的，因此，能不能直接使用开发机的环境编译，不使用服务端编译呢？因此，就有了方案二，客户端主导的持续部署。
（2）客户端主导的部署流水线
这里使用yunedit-ssh来实现，yunedit-ssh是一个sftp客户端和流水线工具。流水线的特点是轻量级，利用本地的编译环境或者编译好的文件直接批量上传。
这里主要使用yunedit-ssh的ssh隧道+流水线功能来实现。都是可视化的。
ssh隧道可以通过ssh跳板机作为跳版，直接访问到跳板机机房内网的服务。
比如如下例子：
这里创建了两个ssh连接，一个是跳板机的ssh连接，用来打通ssh隧道做端口映射。
使用ssh隧道，将远程内网的机器，映射端口到本地22端口后，就可以创建一个本地的ssh连接，连接本地端口即可管理到机房内网的机器了。
上图第二个连接，就是我发布文件需要推送的服务器。
然后就是配置流水线，如如下图所示：
点击创建流水线，即可创建流水线了：
下面是一个创建好的流水线的步骤：
点击其中一个步骤，可以看到，流水线可以上传文件，也可以执行本地命令，也可以执行远程命令，如下图：
比如步骤类型是执行远程命令的话，是这样配置：
这样通过可视化的方式来配置，无论是开发人员还是运维人员，都容易理解，没有信息黑洞，也无需去学习复杂的jenkins语法和制品库安装。
