背景

目前公司测试环境前端我的项目部署，是由测试人员负责手动操作。当须要更新测试环境版本时，测试共事须要手动操作以下过程。

  1. 连贯打包服务器
  2. 关上svn管理工具，找到指标svn版本号并拉取我的项目
  3. 拉取我的项目后，关上命令行，下载依赖。
  4. 期待依赖下载完结后。敲下打包命令
  5. 期待构建完结，并将资源文件压缩成压缩包复制到桌面
  6. 链接部署服务器
  7. 找到须要部署的站点文件夹
  8. 粘贴至指标文件夹并解压

在我的项目多的时候，反复操作极大的浪费时间。如果遇到同一时间不同项目组打包我的项目，打包和部署服务器就要排队应用，测试人员只能在期待中浪费时间。为了解决这些问题，抉择寻找适合的继续集成计划。来自动化实现反复的步骤。

我尝试过轻量的主动部署计划（walle，spug）。但因为两者对于Windows零碎和svn反对太低。最初还是抉择了老牌持重的Jenkins。

咱们利用Jenkins来自动化解决上述问题。（拉取代码，打包构建，将资源送往指标服务器）。让测试共事不再须要关怀打包环节，并从这一繁琐的过程中解放出来，回到本应专一的测试程序工作环节上。

下载docker与Jenkins镜像

借助docker这个搭环境的神器来搭建Jenkins，首先装置docker

# 装置dockeryum install docker
# 启动dockersystemctl start docker
# 设置镜像源，减速下载镜像vim etc/docker/daemon.json{"registry-mirrors": ["http://hub-mirror.c.163.com"]}# 服务重启systemctl restart docker.service
# 装置docker Jenkinsdocker pull jenkins/jenkins# 建设Jenkins数据存储文件夹mkdir /usr/jenkins# 设置权限chown -R 1000:1000 /usr/jenkins# 启动Jenkins，映射到 9527 端口docker run -itd --name jenkins -p 50000:50000 -p 9527:8080   --privileged=true -v   /usr/jenkins:/var/jenkins jenkins/jenkins

Jenkins初始化

胜利启动容器后，拜访Jenkins服务器IP地址加端口号，进行Jenkins初始化，初始化的管理员明码从日志中能够获取。

#查看容器IDdocker ps -a#查看容器日志docker logs 容器ID

抉择举荐装置，期待装置后即可。

装置Jenkins插件

初始化完后。应用刚刚创立的账号登录Jenkins进入界面，须要装置几个插件来反对咱们的业务。

在系统管理——插件治理中，装置以下三个插件。

  1. Subversion Plug-in（svn反对）
  2. Publish Over SSH（近程连贯）
  3. NodeJS Plugin（前端资源构建）

插件配置

插件装置完后，须要对插件进行配置。

ssh插件配置

在系统管理——零碎设置中，找到 publish over SSH。点击新增按钮，增加须要公布的近程机配置。

比方须要公布到开发环境的近程机，增加以下信息。

部署机器操作系统为windows，须要给部署机器装置ssh并开启服务，以反对ssh链接。

windows装置ssh

局部机器可能设置了防火墙，须要在防火墙给22端口增加出站入站规定。容许ssh连贯。

node.js插件配置

在系统管理-全局工具配置中，找到 NodeJS。

须要留神的是Node.js版本防止过高，抉择开发稳固版本，能防止不少版本过高导致部署过程呈现一些奇怪的问题。

插件配置结束后，就可能新建构建工作了。

新建构建工作

工作类型抉择自在格调软件我的项目。

工作信息

增加参数化构建过程，用于解决不同状况解决的构建。这边须要关注两个参数 env, svnUrl，对应着：构建及公布环境、构建的svn版本号。

env 在前端我的项目构建时，会当作变量传入。用于动静批改构建的我的项目环境类型。

svnUrl 为每次我的项目构建时，拉取代码的SVN地址。

svn仓库配置

因为是代码版本控制工具是SVN，须要抉择 Subversion 选项，在 Repository URL 中填入变量 $svnUrl。代表构建时应用传入的地址参数。

同时还须要提供一个svn账号凭证，用于拉取SVN代码。

配置node.js打包前端我的项目

抉择node.js进行构建。

在构建中，可能借助命令行给node.js环境来装置某些源工具，比方yarn、cnpm、nrm。后续可将装置源工具的命令去掉，间接执行装置依赖命令。

此处的命令负责打印常见信息，并执行构建命令。在构建完结后将 dist 文件夹的内容压缩成压缩包："dist.tar.gz"

配置构建后操作

在前端资源打包实现后，咱们须要将文件送到指标服务器。此处增加送往的指标服务器。

点击Add Server增加构建后须要将文件传送的指标服务器，并指定传送的文件名称dist.tar.gz，并编写传送后须要执行的命令。

Exec command 中的命令在不同的操作系统中是不一样的，当零碎为unix零碎时，执行的为unix命令。当为windows零碎时，执行的为批处理命令。

Exec command 中的 superDeploy.bat 为指标服务器预留的批处理文件，负责将文件解压缩，送往部署目录的解决。

实现以上配置后，保留此工作。

在近程机器增加批处理文件

当配置的指标机器为windows零碎时，文件会被送到配置近程链接的账户所属用户文件夹下。在传输结束后，预留的 superDeploy.bat 文件会被执行。

superDeploy.bat 接管两个参数，以后构建的环境，和构建后文件传送的门路。

批处理文件负责复制压缩包到指标文件夹，在指标文件夹解压缩等操作。

这里通过命令行来调用 7z 的解压缩性能，须要给部署机装置 7z解压软件。也能更换为其余解压缩软件。

7z官网中文站

开始第一次构建

实现配置后，点击 Build with Parameters 开始构建，构建前须要填写构建参数。

此时会依照SVN我的项目地址拉取代码，构建前端资源时，会执行npm run build:${传入的环境参数} 命令。对应的为前端我的项目 package.json 中各环境的打包命令。

{    "scripts": {        "build:dev": "vue-cli-service build --mode=dev",        "build:test": "vue-cli-service build --mode=test",        "build:prod": "vue-cli-service build --mode=prod"    }}

此处利用了 vue-cli3.0 提供的构建命令和环境变量文件，来提供各环境的打包命令。前端我的项目须要配置多种打包命令，来反对Jenkins的动静环境构建。

前端我的项目增加多环境打包命令

所有就绪，点击开始构建。Jenkins就会依照SVN地址拉取代码，并且执行构建命令，在构建实现后将dist文件夹压缩成压缩包，送到指标服务器并且执行预留在指标服务器的批处理文件。批处理文件将压缩包挪动到执行的目标目录，解决解压缩的动作。一个主动构建和部署的过程就实现了。

理论构建工夫须要40秒~70秒，但对于手工操作来说要强太多了。

踩过的坑

  1. 文件传送的用户目录名称不一样

在某些电脑上呈现，登录的用户名为 user，但理论传输到指标的文件夹为 user.iZjenfhextasd 这样的文件夹。须要留神脚本的正确寄存地位。

  1. cnpm装置依赖偶然超时

须要批改Jenkins镜像中装置的cnpm源码文件的超时工夫配置。

docker cp jenkins:/var/jenkins_home/tools/jenkins.plugins.nodejs.tools.NodeJSInstallation/Node_JS_12.18.4/lib/node_modules/cnpm/node_modules/urllib/lib/urllib.js /usr/jenkins/#批改文件中的内容docker cp /usr/jenkins/urllib.js jenkins:/tmp/docker exec -u root -it jenkins /bin/bashmv /tmp/urllib.js /var/jenkins_home/tools/jenkins.plugins.nodejs.tools.NodeJSInstallation/Node_JS_12.18.4/lib/node_modules/cnpm/node_modules/urllib/lib/urllib.js

或者能更换为其余依赖下载命令，比方yarn。

  1. 部署机网络或性能问题，偶然无奈连贯

保障部署机可能失常运行，不爆满内存与CPU应用。

  1. ssh连贯失败

查看openSSH服务是否启用，或者防火墙是否禁用了22端口的出入。

  1. 依赖更新问题

Jenkins首次装置依赖会依据我的项目中锁定版本号的文件进行依赖版本装置（package-lock.json，yarn-lock），装置过后 node_modules 文件夹会存留。如须要更新特定依赖版本，须要手动批改 package.json 中的版本号并从新提交构建，或者抉择工作中的 “清空工作区选项”。

写在最初的碎碎念

在公司没有运维的状况下。一开始只是抱着尝试的心理来摸索继续集成的计划，在尝试了 walle/spug 这样的轻量部署计划均失败后曾打算放弃。但听到测试共事的一句吐槽：“主动部署说了三年了，都没有做进去”。于是下定决心肯定要将这个指标实现。

我始终深信着，如果某件事情迟迟实现不了，那它应该是在期待某个人来实现。我就要尝试来成为这个人。

于是开始一直收集材料，查阅文档，从零开始搭建。windows与svn总有大量奇奇怪怪的问题，在搭建的过程频频碰壁。好不容易搭建好了，依赖却装置不了了，阻碍一个接一个。

在间断失败了95次之后，第96次终于胜利将所有的流程走通。胜利的喜悦无以言表，差点就冲动得在座位上跳了起来。

就这样，测试共事的生产力失去了解放。不再须要为打包的事件苦恼，所有都变得这么简略。

感激TL始终的信赖和反对，在我提出有这样的想法时，一直的帮我争取借用到各个生产服务器环境的权限。也让我领悟到，只有一直跳出固定畛域。一直挑战本人不相熟的内容，本身的能力才有更大的晋升。

心愿这篇文章可能帮到你，have a nice day :)