jenkins+gitlab自动化编译部署方案探索及服务端编译webpack实战
一. 背景
之前我们的开发流程为在本地进行webpack打包编译，然后svn提交源代码和编译后的代码。同时每次提交前也会从svn更新源代码和编译后的代码。这样做有几个缺点：
1. svn 更新和提交编译后的代码造成大量冲突文件
2. 由于我们使用非覆盖式发布的命名方式，在经过小组多人多次优化提交测试之后，在整理需要发布的文件列表时，很容易遗漏一些文件
3. 在涉及到多人开发同一功能时容易产生代码被覆盖、人工安排发布优先级、手动注释他人未上线代码等情况
4. svn的分支开发繁琐不友好，加重工作量
最不能容忍的是第一第二点，于是我们改成服务端打包编码，本地只提交和更新源代码，这样就会大大减少冲突。同时，利用jenkins自动把服务端打包编译后的代码部署到测试和线上环境，省去了手动整理待发布文件列表的麻烦，也避免了发布文件遗漏的情况。为了提高开发流程质量，科学友好的规范开发流程，我们选择gitlab作为新的代码仓库，通过分支管理和代码review来提高开发效率，减少发布错误。
二. 自动化部署架构
完成功能：
1. 代码仓库用gitlab托管，使用AoneFlow分支管理模式（阿里命名的一种分支管理模式，借鉴于gitflow, githubflow和gitlabflow）。
2. 源代码合并到测试分支后，jenkins自动打包编译并将编译后的代码部署到测试环境。
3. 源代码合并到发布分支后，jenkins自动打包编译并将编译后的代码部署到线上环境。
4. 给Master稳定分支打版本tag，同时增加tag版本说明。
5. 脚手架和代码分离，保留一个脚手架仓库，提供给各个环境编译。
部署方案探索
A. jenkins合并代码并编译，ssh发送编译后代码到测试环境
缺点：发送代码量大，耗时严重
B. jenkins合并代码并编译，编译结果提交到gitlab，ssh连接测试环境从gitlab更新代码
缺点：编译后代码合并到gitlab冲突多，麻烦
C. jenkins合并代码，ssh连接测试环境更新gitlab代码，然后运行编译命令
优点：速度快，冲突少
综上，我们选择方案C进行部署代码。
发布到线上，不能通过merge到release/prop发布分支后自动触发jenkins构建，因为我可能同时有多个feature分支需要一次性发布到线上，这个时候需要多个feature分支挨个合并到发布分支，然后才能执行构建操作。所以合并到发布分支和构建部署到线上应该分为两个独立部分，分别执行。
一图胜千言，结合我司的实际开发环境，目前整体架构如下：
三. jenkins 配置实战
关于jenkins安装的方案网上有很多，可以另行查询。
1. 首先安装插件：
- Gitlab Hook Plugin
- GitLab Plugin
- Publish Over SSH
系统管理--管理插件--可选插件
2. 新建job
3. 配置git源码
点击新建的job，点击配置--源码管理
Repository URL ： 填写git仓库地址
点击add--jenkins
选择 ssh username with private key (需要提前在jenkins服务器生成ssh keys)
- username: root
- enter directly: 私钥内容 或者 From a file on Jenkins master ： 私钥的存放路径比如/home/role/.ssh/id_rsa
- passphrase: 生成ssh keys时填的密码，如果当时没设置则不填
如果选择私钥内容，那就需要在gitlab上把你的公钥填到gitlab ssh keys:
点击Credentials选择刚添加的证书，如果此时没有红字报错，证明设置成功！
4. 设置webhook
webhook按我的理解就是可以触发的一个接口，可以用它来在一定条件下触发某个任务。
在job配置中找到如下选项：如果没有，则先安装Gitlab Hook Plugin
复制红框中的webhook url， 打开gitlab如下图在URL处填写webhook地址
add后点击test，如果提示
则设置成功，jenkins成功触发！
！！！注意：
gitlab的webhooks url 是根据jenkins构建权限连接设置的，如果必须登录才能构建就必须获取jenkins的用户名及token，可以在jenkins用户-设置里面查看到 ，url格式
http://<username>:<api-token>@<jenkins-server>/
如果不须登录就能构建就直接设置为 http//jenkins-server/job/security_Usm/build?delay=0sec ，security_Usm是job名称
所以，如果你出现如下错误提示：
Hook executed successfully but returned HTTP 403 <!doctype html><html lang="en"><head><title>HTTP Status 403 – Forbidden</title><style type="text/css">h1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} h2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} h3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} body {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} b {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} p {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;} a {color:black;} a.name {color:black;} .line {height:1px;background-color:#525D76;border:none;}</style></head><body><h1>HTTP Status 403 – Forbidden</h1><hr class="line" /><p><b>Type</b> Status Report</p><p><b>Message</b> anonymous is missing the Job/Build permission</p><p><b>Description</b> The server understood the request but refuses to authorize it.</p><hr class="line" /><h3>Apache Tomcat/8.5.24</h3></body></html>
需要更改你的gitlab中webhook地址为如下形式：
http://maoyu:89w3fseydf96934hy@10.95.10.10:8080/jenkins/project/front-end
5. ssh部署到服务器
全局配置ssh服务器：系统管理--系统设置
、
配置好后点击Test，出现success即表示成功。
然后配置具体的发布内容：
- source files: jenkins中工作空间下的路径
- remote directory: 是相对全局配置中Publish over SSH -- SSH server -- Remote Directory的路径
source files亦可不填，直接连接服务器后执行exec command.
6. 显示构建日志的时间
如果想在console output中显示如下的时间
配置如下即可：
7. 自动合并Gitlab Merge Request
如果你想在Merge request后使用jenkins自动合并代码，可以使用下面的方法，如果不需要这样，比如push到某个分支直接触发webhook则可以跳过此步骤。
我的目前构建方案中，在发布到测试环境时，两种都有，即既可以通过Merge Request触发自动合并然后构建，也可以手动合并后产生push事件触发webhook。但很可能之后会改成提交到对应分支后，自动触发webhook，jenkins合并到相应分支然后编译部署。看具体公司的使用习惯和一些规范吧。
使用插件：Gitlab Merge Request Builder
配置如下：
如果想在gitlab pipeline成功之后自动执行merge操作，需要勾上下面的配置，可以说这是必须的，不然你就完不成自动合并：
gitlab对应的合并界面有如下变化：
初始界面如下，可以在右上角close 合并请求：
在建立合并请求到合并成功，可能会出现如下的红叉提示Could not connect to the CI server. 不用管它，可以忽略。
如果合并失败，界面提示如下，则需要去jenkins查看日志具体为什么合并失败：
或者你可能会看到如下的提示：
合并成功如下，在discussion中会有jenkins自动添加的一些comment：
Gitlab Merge Request Builder会触发gitlab的pipeline, 无需配置gitlab的CI/CD。
如果在gitlab 的merge requests部分，Discussion没有Build Started，Build triggered, Build finished Test Passed.这些提示，说明Gitlab Merge Request Builder插件没有起作用，仔细检查配置Gitlab Project Path等是否正确，如果都正确可以尝试重启jenkins，重新发起merge request。
如果在配置构建触发器下的 Gitlab Merge Request Builder，点击apply时报如下错误，则在系统管理--系统配置中检查Gitlab Merge Request Builder配置Jenkins Username和Jenkins API Token是否正确。
Gitlab merge冲突：
点击 解决冲突 手动编辑解决冲突，保存即可重新触发merge request，然后自动合并
8. 参数化构建
参数化构建即第一你需要手动点击构建按钮，第二你可以设置一些参数变量在构建中使用，比如开发环境，分支参数等。
为什么需要参数化构建？我们目前项目比较简单，其实无需参数化构建，但在部署到线上后给master打tag时，遇到点麻烦，即不能给tag设置一些个性化的说明文案，这样找起tag单纯看版本号可能很难知道某个版本里面完成什么功能。所以我们在发布到线上时，增加了deploymsg即要发布功能的描述，用来作为tag的描述信息。
参数化构建可以使用jenkins自带的参数化构建过程，如下：
参加参数中选择string parameter， 第一项名字即你要添加的变量名。
设置好后保存，即完成了参数化构建的设置。
第二种方法可以使用jenkins插件，jenkins有着几千款各种功能插件，非常丰富，基本我们想要的功能都会有插件支持。
这里我们使用的插件是：Generic Webhook Trigger
按照以上配置即配置了一个ref变量。
附1：如何从jenkins知道 gitlab webhook是哪个分支触发的呢？
看下图
更简便的方法是gitlab plugin提供的变量：
可以再shell中打印如下查看：
echo "gitlabBranch: ${gitlabBranch}";
附2：同一服务器生成多个ssh key:
只需要对文件名命名不同的名字即可，如下：
附3：Jenkins定时语法：
如以下表示每2分钟执行一次任务：
cron语法有五位，分别的意义是：
- MINUTES Minutes in one hour (0-59)
- HOURS Hours in one day (0-23)
- DAYMONTH Day in a month (1-31)
- MONTH Month in a year (1-12)
- DAYWEEK Day of the week (0-7) where 0 and 7 are sunday
其中每个字段除了可以使用取值范围内的值外，还能使用一些特殊的字符。
- * 匹配范围内所有值
- M-N 匹配M~N范围内所有值
- M-N/X 或者 */X 在指定M~N范围内或整个有效区间内每隔X构建一次
- A,B,...,Z 匹配多个值
为了在系统中生成定时任务，符号H（代表“Hash”，后面用“散列”代替）应该用在可能用到的地方，例如：为十几个日常任务配置0 0 * * *将会在午夜产生较大峰值。相比之下，配置H H * * * 仍将每天一次执行每个任务，不是都在同一时刻，可以更好的使用有限资源。
符号H可用于范围，例如，H H(0-7) * * * 代表凌晨0:00到 上午7:59一段时间。你还可以用H代表有或无范围的区间。
符号H 在一定范围内可被认为是一个随机值，但实际上它是任务名称的一个散列而不是随机函数。
需要注意的是，月份中的某天-DOM字段，类似于*/3 或者 H/3 的短周期由于月份的天数不固定，在大多数月尾总不会工作。例如，*/3 将会在一个月里面的第一天、第四天。。。第31天执行，下个月的那天继续重复执行。散列一般被选择在1-28天内，所以H/3将会在跑到月底的3-6天内导致空白。（长时间循环将会导致长度不一，但是这种影响也是不明显的。）
空行和以#开头的行将会被认为是注释。
另外，@yearly, @annually, @monthly, @weekly, @daily, @midnight, 和 @hourly也支持别名。这些使用散列系统自动匹配，例如：@hourly 和 H * * * * 一样代表一个小时内的任何时刻。@midnight实际上代表凌晨0:00到凌晨2:59之间的一段时间。
例如：
# 每隔15分钟。(或许:07, :22, :37, :52)
H/15 * * * *
# 每前半小时中每隔10分钟。 (3次, 或许:04, :14, :24)
H(0-29)/10 * * * *
# 每个工作日从早上9点45分开始到下午3点45分结束这段时间内每间隔2小时的45分钟那一刻。
45 9-16/2 * * 1-5
#每个工作日从早上9点到下午5点这段时间内每间隔2小时之间的某刻。(或许在上午10:38, 下午12:38, 下午2:38 , 下午4:38)
H H(9-16)/2 * * 1-5
#每月（除了12月）从1号到15号这段时间内某刻。
H H 1,15 1-11 *
附4：jenkins 关闭和重启方法：
1、关闭Jenkins
只需要在访问jenkins服务器的网址url地址后加上exit。例如我jenkins的地址http://localhost:8080/，那么我只需要在浏览器地址栏上敲下http://localhost:8080/exit 网址就能关闭jenkins服务.
2、重启Jenkies
http://localhost:8080/restart
3、重新加载配置信息
http://localhost:8080/reload
附5：错误集锦：
1. GitLab: The project you were looking for could not be found.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
解决方案：
查看git用户是否具有提交到gitlab仓库的权限
2. Could not open a connection to your authentication agent.
需手动开启ssh，如下；
eval `ssh-agent -s`
再次执行ssh-add 即可
3. Exception when publishing, exception message [Exec timed out or was interrupted after 120,001 ms
适当调大超时时间，比如调成300000
4. ssh_exchange_identification: Connection closed by remote host
解决方法一. 把SSH连接数改大
修改服务器上的这个文件：/etc/ssh/sshd_config 找到这行 # MaxSessions 10 ：
去掉前面的"#" 并把数字改大，最后重启sshd service sshd restart 然后重新连接即可.
解决方法二. 每次正常退出SSH连接
每次执行完命令后用输入"exit" 退出, 防止连接数过多.
附6：svn批量检测提交shell脚本
见github: https://github.com/saysmy/svnsh
