持续集成工具Jenkins

持续部署的关注点在于项目功能部署至服务器后可以运行，为下一步测试环境测试环节或最终用户正式使用做好准备。
经常性，频繁的吧所有的模块集成在一起进行测试，有问题尽早发现，这就是持续集成。
持续集成的关注点在于尽早发现项目整体运行问题，尽早解决。使用小版本不断进行快速迭代，不断收集用户反馈信息，用最快的速度改进优化。
持续交付的关注点在于研发团队的最新代码能够让最终用户体验到。

#####CI（持续集成）
持续集成是软件开发过程中的一种实现，通过将代码仓库与jenkins集成，是开发人员的每一次代码提交都能够在jenkins上自动进行任务的build构建，帮助开发团队第一时间发现问题并解决问题。

#####CD（持续交付）
在CI的基础上将构建好的软件版本通过jenkins的测试自动化部署，持续、安全、快速地交付到用户手中。

总体目标：
降低风险
减少重复过程
任何时间任何地点生成可部署软件
增强项目的可见性
建立团队对开发团队的信心

Jenkins可以整合GitHub和Subversion

自动化部署的实现：向版本库提交新的代码后，应用服务器上自动部署，用户或者测试员使用的马上就是最新的应用程序。

#####系统结构描述：
版本控制子系统
Subversion服务器
项目对应版本库
版本库中的钩子程序
持续集成系统
#####Jenkins
        主体程序
        SVN插件
        Mavn插件
        Deploy web container插件
#####应用发布子系统
JDK
TomCat

Jenkins使用天气来表示构建成功率
curl命令用来发送HTTP请求
```
～]# curl –X post –v [Jenkins_user_name]:[Jenkins_Password] –H“请求消息头信息” –http://[server_IP]:[Port]/Jenkins/job/[Jenkins_Project]/build?token=[身份验证令牌]
```
-X  指定请求方式
-v  显示响应结果
-u  携带用户名和密码
-H  携带请求消息头信息
Jenkins_URL/job/Project_Name/build?token=TOKEN_NAME
Jenkins_URL  http://Server_IP:8080/jenkins
job  固定名称
Project_Name  自定义项目名称
build  固定名称
?token=TOKEN_VALUE  值在jenkins界面自定义
当触发该触发器后会完成自动构建（浏览器访问该地址也会触发构建[代码提交通知jenkins的方法]）
![](http://fxme.top/usr/uploads/2019/05/1767111016.png)
Jenkins：
Jenkins Build的版本比代码库晚一个版本的解决办法：在Jenkins源码管理工程配置中，Repository URL为URL@HEAD，“@HEAD”意思为指向最新版区下载代码，GitHub上使用的每个repository的WebHook方式远程触发Jenkins的构建。

GitLab：开源分布式版本控制系统，使用ruby开发，管理项目源代码，版本控制复用与查找。

GitHub：分布式在线代码托管仓库，个人版本可以直接在线免费使用，企业版本收费且需要服务器安装。

GitLab的优势和应用场景：
开源免费适合中小型公司将源代码放置在该系统中
差异化的版本管理，离线同步以及强大的分支管理功能
便捷的GUI操作界面以及强大的账户权限管理功能。
集成度很高，能够集成绝大多数的开发工具
支持HA，保证在高并发下仍旧实现高可用性。

GitLab主要服务构成
    1. Nginx静态web服务器，GitLab的proxy处理所有HTTPS静态访问请求。
    2. GitLab-workhorse  轻量级的反向代理服务器，处理较大文件的上传下载（如push操作）
    3. GitLab-shell用于处理Git命令和修改authorized keys列表
    4. Logrotate  日志文件管理工具，负责处理日志的切割/打包等操作
    5. Postgre sql数据库，保存所有的gitlab数据信息
    6. Redis缓存服务器，加快前台的访问速度

本地需安装gitclient，保证能够进行clone
gitlab的工作流程（可使开发人员并行完成后自身的feature需求，而又不会对主分支代码产生影响）：
创建并clone项目
创建项目某Feature分支
编写代码并提交至该分支
（实际环境中，管理员会创建好项目仓库，并在该仓库下根据我们的业务需求去创建若干个feature特征分支，这些feature分支会以任务的形式分发给我们的开发）
推送该项目分支至远程Gitlab服务器
在Gitlab图形界面下找到自己的代码进行代码检查并提交master主分支合并申请
项目领导审查代码并确认合并申请

GitLab应用：
Gitlab拥有强大的分布式版本控制系统，也有着出色的后台管理能力，后台的管理可以针对不同的项目/不同的用户去定制不同的访问策略。
GitLab运维需要获取的系统的关键值：
    CPU利用率/内存/磁盘使用率
    保证在gitlab在一个高并发的情况下依旧能够快速稳定运转
admin需要分配不同的人对不同的项目拥有不同的权限
    保证开发人员具有分支的克隆/删除/推送/提交/合并/创建分支等权限
    保证项目领导在具有开发人员权限的基础的同时，具有检查项目用户/开启/禁用/保护分支/编辑项目信息/审核确认分支的申请的权限
```
～]# git -c http.sslVerify=flase clone CodeRepo_Addredd(仓库地址)
#输入开发人员账号密码进行代码仓库的克隆
～]# git check -b release-1.0    #创建名为release-1.0的分支并切换进该分支
#该分支下依旧存在clone的代码文件，在该分支下进行代码的编写
～]# git add
~]# git commit -m “release-1.0”   #本地提交feature更新
~]# git -c http.sslVerify=flase push origin release-1.0    #将代码同步到远程的release-1.0的分支中
    登陆到gitlab Dev账号，在界面上可以看到新提交的代码，点击create merge request将代码合并到master分支（申请）
leader登陆gitlab界面通过合并申请
```

「一键投喂软糖/蛋糕/布丁/牛奶/冰阔乐！」