脑袋竟然抽了，要研究这个？
当我有这个想法的时候，脑袋确实抽了一下。作为传统应用开发人员，应该把自己的精力放到业务逻辑上，把完成客户需求作为第一目标。如果把精力放到这个上面，那要架构师干嘛？所以当听到架构师跟我说这番话的时候，我更加感到好奇了，就好像某水中学的孩子想努力学习以后好去大城市拱白菜一样。
所以想到这里，我毅然放下了手里繁重的工作，开始找各种文档研究这个听起来非常美的GitLab单词，我合计当我研究成功了，是不是可以和领导多要点？或者以后当个小架构师给别人挖挖坑？
1、到底什么是GitLab，我要用它干嘛？
无论咱用什么语言写代码，无论咱用什么工具写代码，最后都要把代码上传到代码库里。我最开始使用的代码管理工具是svn，后来换成了git，这些工具会把代码传到Repository。这样有个统一的库来管理代码，后续发布或维护交给其他人时也会方便很多，直接checkout或pull下来就好了。而GitLab就是一个使用git来管理仓库的系统软件。通过构建一个GitLab服务，让开发人员使用你分发的权限来写代码，最后把写好的代码部署到测试或生产环境。GitLab是所有项目开发的第一步，看来还是很重要的。万事开头难，先来部署下服务吧。
2、GitLab的部署，好像很简单
首先去官网溜溜，找到菜单里的安装菜单。
映入眼帘的是一句我看不懂的普通话？总之是让我准备的服务器要4g内存是吧？
Linux installation is quicker to install, easier to upgrade and contains features to enhance reliability not found in other methods. Install via a single package (also known as Omnibus) that bundles all the different services and tools required to run GitLab. At least 4 GB of RAM is recommended.
我弄了个虚拟机，给了4g内存，准备部署，下面是教用户怎么部署的，还分各种不同的系统，感觉好贴心啊，比老师上来就让我开发个OA打卡系统强了好多呢。
我选择CentOS7来安装，下面是安装命令:
安装依赖：
sudo yum install -y curl policycoreutils-python openssh-server perl
# Enable OpenSSH server daemon if not enabled: sudo systemctl status sshd
sudo systemctl enable sshd
sudo systemctl start sshd
# Check if opening the firewall is needed with: sudo systemctl status firewalld
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo systemctl reload firewalld
安装邮箱：
sudo yum install postfix
sudo systemctl enable postfix
sudo systemctl start postfix安装GitLab
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.rpm.sh | sudo bash
sudo EXTERNAL_URL="https://gitlab.example.com" yum install -y gitlab-ee
https://gitlab.example.com 这个可以更改为ip地址并且用http协议，如果后面要改域名可以再配置dns，我是设置成
http://192.168.153.129:10220，这样我可以在本机访问到这个虚拟机的GitLab，当然要开防火墙端口，或者关闭防火墙
防火墙开端口命令：firewall-cmd --zone=public --add-port=10220/tcp --permanent
关闭防火墙命令：service firewalld stop
重启防火墙配置：firewall-cmd --reload
如果上面的url地址设置错了，可以到文件里面去修改
gitlab.rb
修改external_url 'http://192.168.153.129:10220'
安装完了，请求下看看效果，这里需要用户名和密码，GitLab提示用户名用root，密码存到一个密码文件中，第一次需要登录去复制出来。
密码位置：
/etc/gitlab/initial_root_password
先浏览下GitLab吧
可能会遇到502错误，大概率端口设置不对，我的经验是设置大端口一般没问题，10000以后的很安全，如果8080、9090、8090这种很容易就冲突了。
成功登录说明安装没问题了，成功部署了GitLab服务，第一阶段完成了，下面咱看看怎么建库吧。
3、GitLab建库，存点小代码
建个代码仓库，这里非常简单，看到按钮按一按，就创建了一个代码仓库。
New Project->Create blank project->Create project
我创建了一个mountain项目，这里配合Idea上传点代码。
这里要上传ssh密钥，不然没有代码权限。
ssh-keygen -t rsa -C your@xx.com -b 4096，可以设置自己的密码，这样会生成密钥对在本地，找到生成的公钥，把里面的字符串配置到GitLab。
在GitLab点击头像下的Preference进行设置
到这里仓库和账户权限都设置差不多了，可以通过IDEA等IDE下载代码了。是不是到此为止了？就这？
4、CI与CD是个什么？能骗个女朋友？
完成了部署与代码库搭建，好像真的不算什么，拿这个找白菜貌似差了点啥。下班后我涌进拥挤的通勤车，看着谢顶的师弟挽着撒娇的白嫩师姐，貌似想到了什么：如果下班后能有人自动把我放到通勤车，再把车里容易和我发生冲突的师弟赶出去留下我喜欢的师姐岂不是很美？开到地方了直接把我放回家，我都不用走了。如果每天都这样，我还买什么私家车啊，通勤就是我的邂逅车，爱情早晚从这里开始。所以代码是不是会和爱情一样，有人从中推波助澜呢？
所以看了看CI/CD的概念，这个东西正好在GitLab中：
CI:Continuous Integration works by pushing small code chunks to your application’s codebase hosted in a Git repository, and to every push, run a pipeline of scripts to build, test, and validate the code changes before merging them into the main branch.
CD:Continuous Delivery and Deployment consist of a step further CI, deploying your application to production at every push to the default branch of the repository.
大概就是帮助我把代码创建、测试、部署一遍。CI可以实现持续集成，把各种开发者推送的代码自动测试、构建一遍，如果有问题会提示他们改好，没有问题就提示可以合并，这样就不用靠脑袋想起来了构建一遍，再解决冲突。而CD可以实现持续部署，可以把构建好的打包发布到应用服务器，这样就不用原始的手动拷贝了，这里和Jenkins很像。
概念理解很重要，这东西就像ppt，咱不会造电动车也要明白啥是特斯拉。
5、配置CI/CD
以我的这个测试项目代码为例，点击CI/CD configuration进入配置页。
这里其实是在项目根目录下要创建一个文件，名字为.gitlab-ci.yml，这个就是ci、cd的配置文件，点击这个Browse templates可以浏览模板。我用的gradle，但是浏览了大神的文档感觉不知所以，这东西应该我复制过来，还是学一遍？好吧，学一遍吧。。
stages：按顺序执行的阶段任务标签，一般都是三个，build、test、deploy，代表了构建、测试、部署
variables：定义变量，这里我定义了三个，GRADLE_OPTS关闭daemon功能，因为模板让关的，不过开了也没事，是加速构建的一个功能。upload_path定义了我之后要上传目标应用服务器的文件地址，jar_name是自定义的jar名称。
before_script：执行下面的阶段任务之前，要执行一些操作作为前置条件。这里是添加项目相对目录的一个配置，并且创建两个文件夹，不然后面会因为找不到文件报错。
下面配置一下构建任务：
build-bootJar：任务名称，随便起
stage: build 对应阶段任务名
image: 定义使用gradle版本，这里是之前装好的
script：执行的脚本内容，这个非常重要，所有操作都在这里来写。
cache：设置缓存，不然每次都会下载依赖，非常慢
cache:key：设置缓存的文件名称，"$CI_PROJECT_NAME"这个是项目名称，GitLab内部设置的可识别变量，设置后会自动以这个来命名。
cache:paths：设置缓存位置
cache:policy：设置策略，这里pull-push是拉取和推送都要设置缓存。
artifacts：构建，生成的打包文件必须要用到这个命令来传输给下一个阶段任务，不然下面找不到文件。
only：设置master，只管master的打包，其他分支不管。
设置好任务后，可以看到CI/CD菜单中，构建的过程。每个小绿点代表的每个任务阶段。
可以点击前面这个按钮查看详情
接着可以点下面的阶段任务查看详情，比如点击这个build-bootjar
如果这个步骤显示不出日志，可能是gitlab-runner版本太低了，可以升级一下。
build任务会利用gradle把代码打包成jar包，并存起来，GitLab可以下载手工发布。
下面是测试的脚本，比较简单，获取代码时候利用gradle check检查代码
以上就是CI的配置，完成的目的是利用脚本在接收到pull或push请求后做一些构建和测试的动作，结果会显示到列表中，提示管理员是否有代码问题。到这里实现了一半的目标，下面弄一下CD的配置。
首先需要在应用服务器生成密钥对，然后把私钥内容设置到GitLab，后续远程到目标应用服务器执行命令会用到。
然后回到.gitlab-ci.yml，配置deploy-jar
when: manual 配置需要手动发布，不然每次提交master都发布一次，可能非常频繁没有必要。
before_script:发布之前，执行ssh命令添加之前提交的远程应用服务器的私钥。
script：发布脚本，非常重要，这里通过sshpass将之前build阶段产生的jar包取出传送到目标服务器。再通过命令"systemctl restart chessboard.service"重新启动远程服务。
注：systemctl restart chessboard.service 说明之前要手工部署一次，将jar包使用systemctl方式注册成服务，这样下次重启会自动启动，相当于windows的windows service。注册systemctl也很简单，可以自行百度一下。
needs：依赖的任务，指定build-bootJar必须构建完成，并且artifacts中有jar包。
配置之后执行一下，如果是两个绿点，一个发布按钮就成功了，然后点击deploy-jar发布按钮，就会发布到远程服务器。
登录到远程服务器查看是否发布成功：
敲命令看看服务是否正常：
systemctl status chessboard.service
一切顺利，看来运行的还算可以。
6、配置合并请求
下一步可以设置下存储库，把权限设置成主干只允许管理员合并与提交，分支不管。这样开发者必须在GitLab提交合并申请才行。
下面是设置权限目录
创建分支合并请求，这里可以创建多个分支合并请求，这样各种开发分支的合并请求都可以显示到这个列表中，实时查看分支的内容和状态，是否有合并冲突等。
点击进去可以查看详情，并且有提示按钮，管理员进行批准合并。
7、涨薪了？
结束了，首先没有谢顶，然后通勤车早就开走了，我没上去车。我把研究结果告诉了架构师，能高看我了吧？听说最近要涨薪了，不知道工资会不会提高点，听领导说肯定有我的份，因为看我天天加班肯定是干活呢，但是我要不要告诉他我一天净整没用的了呢？GitLab之后我想再看看Jenkins咋用，听说也是非常好的开源软件，小伙伴们咱一起再努努力赶赶车上的师姐啊？