jenkins+gitlab自动化编译部署方案探索及服务端编译webpack实战
利用jenkins自动把服务端打包编译后的代码部署到测试和线上环境，省去了手动整理待发布文件列表的麻烦，也避免了发布文件遗漏的情况。为了提高开发流程质量，科学友好的规范开发流程，我们选择gitlab作为新的代码仓库，通过分支管理和代码review来提高开发效率，减少发布错误。
一. 背景
之前我们的开发流程为在本地进行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