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:[email protected]: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

此插件是通过设定分支,定时检查分支有没有收到Merge Request请求来决定是否进行构建。gitlab是个审核管理 ,当jenkins构建完成之后,gitlab便会合并分支。

配置如下:

如果想在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语法有五位,分别的意义是:

  1. MINUTES Minutes in one hour (0-59)
  2. HOURS Hours in one day (0-23)
  3. DAYMONTH Day in a month (1-31)
  4. MONTH Month in a year (1-12)
  5. 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

原文地址:https://www.cnblogs.com/saysmy/p/8806975.html

时间: 2024-10-08 03:10:47

jenkins+gitlab自动化编译部署方案探索及服务端编译webpack实战的相关文章

开源jms服务ActiveMQ的负载均衡+高可用部署方案探索

一个文件(或目录)拥有若干个属性,包括(r/w/x)等基本属性,以及是否为目录(d)与文件(-)或连接文件(l)等属性.此外,Linux还可以设置其他系统安全属性,使用chattr来设置,以lsattr来查看,最重要的是可以设置其不可修改的特性,即便是文件的拥有者都不能进行修改.这个属性相当重要,尤其是在安全机制方面(security). 文件默认权限:umask 当建立一个新的文件或目录时,它的默认属性是与umask有关的.通常,umask就是指定当前用户在建立文件或目录时的属性默认值.那么,

Jenkins spring boot 自动部署方案

原文地址:http://www.cnblogs.com/skyblog/p/5632869.html 现在主流的自动部署方案大都是基于Docker的了,但传统的自动部署方案比较适合中小型公司,下面的方案就是比较传统的自动部署方案. 1.为什么需要自动部署 基于微服务的架构,自动部署显得非常重要.因为每一个服务都需要部署.如果是手动部署,那么有M个服务,那么至少需要部署M次,如果每个同样的服务部署N个实例,那么就需要部署M*N次.所以自动部署对于微服务架构几乎是必须的,这一点不同于传统应用. 2.

jenkins+gitlab+maven+docker部署项目之jenkins用户权限管理

一.用户管理 jenkins自身带有权限管理,入口:系统管理-->全局安全配置,这里的权限配置太过简略,没有角色的概念,显然无法满足我们复杂的需求,所以在这个时候引入了 Jenkins 的一个插件:Role-based Authorization Strategy 安装插件:Role-based Authorization Strategy,插件管理-->可选插件搜索一下点击安装,安装完后重启就可以使用该插件 系统管理-->全局安全配置,然后用重新登录一下 系统管理-->Manag

java自动化测试成长日记-之CVS客户端和服务端安装和部署1:CVS服务端的配置和基本使用

CVS服务端的配置和基本使用 在做java自动化测试集成环境搭建的时候,无论怎样,你都会选择一个源代码管理工具,如:SVN,CVS,VSS等:但如果你使用Eclipse工具,建议你使用CVS源代码管理工具,因为它本身就自带了CVS客户端插件,可以直接使用(具体使用情况,可参考:java自动化测试成长日记-之CVS客户端和服务端安装和部署2:CVS客户端的配置和基本使用章节): 首先,你需要下载:cvsnt-2.5.03.2151安装包.msi,服务端安装软件(可在百度里面搜索找到,相应的资源).

企业级Docker+Jenkins+Gitlab自动化流水线构建

随着DevOps理念和敏捷理念的发展,我们都希望通过自动化技术,加快项目的迭代.尤其是当使用微服务系统架构之后,功能的叠加,对应服务的数量也在增加,大小功能的快速迭代,更加要求部署的快速化,智能化.因此,传统的人工部署已经心有余而力不足,所以合理的使用持续集成,持续部署可以极大的提高生产效率,提高团队整体效率不可或缺的一环.那么Jenkins可以帮你构建一个自动化的持续集成环境,你可以使用它来"自动化"编译.打包.分发部署你的应用,同时跟svn.git能无缝集成,也支持直接与知名源代码

jenkins +gitlab 自动化代码秒级上线

一,配置脚本 1 #!/bin/bash 2 #目标服务器IP地址 3 host=$1 4 #job名称 5 job_name=$2 6 #包名 7 name=web-$(date +%F)-$(($RANDOM+10000)) 8 #打包 9 cd /var/lib/jenkins/workspace/${job_name} && tar czf /opt/${name}.tar.gz ./* 10 #发送包到目标服务器 11 ssh ${host} "cd /var/www/

jmter ant Jenkins 接口自动化环境部署

目录 环境配置 一.安装JDK1.8 二.下载安装Jmeter 三.下载安装ANT 四.安装配置tomcat+Jenkins 环境配置 windows 10 + jdk1.8.0_171 + apache-jmeter-3.3 + apache-ant-1.9.12 一.安装JDK1.8 a.下载安装jdk1.8 b.配置系统环境变量 变量名:JAVA_HOME 变量值:C:\ProgramFiles\Java\jdk1.8.0_171 变量名:CLASSPATH 变量值:.;%JAVA_HOM

python自动化运维——OMserver平台Web服务端部署过程

1.下载源代码(简单不讲述) 2.安装pcre,pcre是一个轻量级的正则表达式函数库,nginx的HTTP Rewrite模块会用到. wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.34.tar.gz tar -zxvf pcre-8.34.tar.gz cd pcre-8.34 ./configure make && make install 3.安装nginx. wget http://nginx.

GoBelieve IM 服务端编译

#部署im1. 安装go编译环境参考链接:https://golang.org/doc/install 2. 下载im_service代码 cd $GOPATH/src/github.com/GoBelieveIO git clone https://github.com/GoBelieveIO/im_service.git 3 编译proto文件 cd im_service //注意需要FQ go get google.golang.org/grpc go get -u github.com/