搭建过程

Gitlab

GitLab 是一个用于仓库管理系统的开源项目，使用Git作为代码管理工具，它是版本管理，代码review，任务管理，项目管理，持续集成五合一的平台，方便代码版本控制和管理，同时优化了团队开发项目中源代码的交流。相比起Github，他们两个都是基于Web的Git远程仓库，都提供了分享开源项目的平台，为开发团队提供了存储、分享、发布和合作开发项目的中心化云存储的场所。对于开源项目而言，GitHub 依然是代码托管的首选。从代码的私有性上来看，GitLab 是一个更好的选择，它有更完善的管理界面和权限控制，适合企业团队进行开发。
1）拉取镜像，安装最新版即可。

docker pull gitlab/gitlab-ce

2）创建容器，其中需要注意的是“hostname”需要使用内网（可以用于域名解析ip，服务器远程登录ip，是最主要的服务器ip地址。而内网主要作用是跟当前帐号下的其他同集群的机器通信。这里起初我使用外网是没有问题的，但之后在禅道因为一些原因重新部署后，外网不能在使用，原因未知，可能是设置、DNS的问题。如果报“xxx execute POST against ip POST against ip xxx ”应该就是这里的原因）；每个“–”前需要有空格；每行结尾处需要有“\”；注意端口冲突，第二个“publish”是将web:80映射到外部端口8083，第一个指HTTP，第三个指SSH。

docker run --detach \
 --hostname 182.92.232.9 \
 --publish 443:443 --publish 8083:80 --publish 2222:22 \
 --name gitlab \
 --restart always \
 --volume /srv/gitlab/config:/etc/gitlab \
 --volume /srv/gitlab/logs:/var/log/gitlab \
 --volume /srv/gitlab/data:/var/opt/gitlab \
 gitlab/gitlab-ce:latest

3）修改“gitlab/config/gitlab.rb”文件，将“external_url”修改为你的端口号，这步主要是为了之后Gitlab Runner的使用，当然也有别的方式，之后我会在SonarQube的配置中提到。在使用VIM时，不建议使用CMD直接书写，会异常的卡，在Windows端可以使用Xshell，在Mac端可以使用Termius。需要注意的是在VIM中输入“:wq”这些结束语句时，需要先按“esc”，才可以输入（会自动跳到页面末端）。

vim /gitlab/config/gitlab.rb
external_url 'http://47.122.4.93:8084'
:wq

4）这样就完成Gitlab的服务器搭建，其中初始账号是root，在版本14之前密码也是root，但之后的版本，你需要进入gitlab容器，在/etc/gitlab/initial_password，这个文件会在以第一次进入后24小时内删除，所以要及时改密码，并且如果你不改密码，Gitlab会在你登录一段时间后就会自动退出。

Git

我们采用Git来实现本地版本控制，相比于SVN，它们最大的区别就是Git是分布式的，这样的好处是跟其他同事不会有太多的冲突，有强大的分支功能，自己写的代码放在自己电脑上，一段时间后再提交、合并，也可以不用联网在本地提交，而且有非常多的强大功能，可以让开发者们更能够舒适的协同开发。而SVN是集中式版本控制系統，版本库是集中放在中央服务器的，所以开发人员工作的时候，首先要从中央服务器下载最新的版本，然后开发，开发完后，需要把自己开发的代码提交到中央服务器，提交慢的人就会遇到冲突问题。这样的好处是每个人都可以一定程度上看到项目中的其他人正在做些什么，管理员也可以轻松掌控每个开发者的权限。
1）去官网进行下载，如果系统是Mac的话，原机自带，不需要进行下载。
2）设置环境变量。

3）开始安装一直下一步即可，其中在设置默认编辑器是，你可以改成Notepad++，或者Visual Studio Code等。安装过后需要在git config文件加中设置用户名和邮箱。之后就可以正式开始使用了。

SonarQube

SonarQube是一个用于管理代码质量的开放平台，可以持续分析和评测项目源代码的质量，快速定位代码中潜在的或者明显的错误，代码规范，安全性漏洞等问题。目前支持java、Python、JavaScrip等二十几种编程语言的代码质量管理与检测。
在使用SonarQube是，会涉及到CI/CD、GitLab Runner、Sonar Scanner的使用。
CI/CD，是对项目实现指持续集成、持续交付、持续部署。软件开发的持续方法基于自动执行脚本，以最大程度地减少在开发应用程序时引入错误的机会。从开发新代码到部署新代码，几乎不需要人工干预。在敏捷开发每次小的迭代中就不断地构建、测试和部署代码更改，从而减少了基于已经存在bug或失败的先前版本开发新代码的机会。
GitLab Runner，它其实就是GitLab CI 是内置的进行持续集成的工具，每次提交的时候，GitLab将自动识别到.gitlab-ci.yml文件，并且使用Gitlab Runner执行该脚本。从而可以做到随时的开源持续集成服务，用于协调作业。
Sonar Scanner，SonarQube是Web服务端，用来发布应用和在线浏览分析，Sonar Scanner用于扫描源码， 将代码写入数据库，便于之后SonarQube进行分析。
1）安装PostgreSQL数据库，并创建其映射目录，Sonarqube7.9后，由于性能与扩展的原因不再支持MySQL。

# 拉取镜像
docker pull postgres:13
# 创建映射目录
mkdir -p /dwz/docker-volume/postgresql
mkdir -p /dwz/docker-volume/postgres/data
# 实例化对象
docker run --name postgres13 -d -p 5432:5432 \
-v /dwz/docker-volume/postgresql:/var/lib/postgresql \
-v /dwz/docker-volume/postgres/data:/var/lib/postgresql/data \
-v /etc/localtime:/etc/localtime:ro \  # 设置容器与宿主机时间一致
-e POSTGRES_USER=sonar \  # 设置数据库用户名
-e POSTGRES_PASSWORD=sonar \  # 设置数据库密码
-e POSTGRES_DB=sonar \  # 新建database
-e TZ=Asia/Shanghai \  # 设置时区
--restart always \
--privileged=true \  # 解决挂载问题
postgres:13

2）安装SonarQube，由于最新版本每次commit后加载过慢，需要起码30分钟，不利于刚开始的学习，所以我们决定将版本降至7.9，这样每次启动只需要大约10分钟左右。

# 拉取镜像
docker pull sonarqube:7.9-community
# 创建映射目录
mkdir -p /dwz/docker-volume/sonarqube
# 修改系统参数
echo "vm.max_map_count=262144" > /etc/sysctl.conf
sysctl -p
# 修改文件夹权限
chmod -R 777 /dwz/docker-volume/sonarqube
# 实例化容器
docker run -d --name sonar -p 9000:9000 \
 -e ALLOW_EMPTY_PASSWORD=yes \  # 配置数据库
 -e SONARQUBE_DATABASE_USER=sonar \
 -e SONARQUBE_DATABASE_NAME=sonar \
 -e SONARQUBE_DATABASE_PASSWORD=sonar \
 -e SONARQUBE_JDBC_URL="jdbc:postgresql://postgres:5432/sonar" \
 --privileged=true \
 --restart always \
 -v /dwz/docker-volume/sonarqube/logs:/opt/sonarqube/logs \
 -v /dwz/docker-volume/sonarqube/conf:/opt/sonarqube/conf \
 -v /dwz/docker-volume/sonarqube/data:/opt/sonarqube/data \
 -v /dwz/docker-volume/sonarqube/extensions:/opt/sonarqube/extensions\
 sonarqube:7.9-community

3）安装GitLab Runner，它的版本需要与GitLab版本一一对应，起初我们GitLab安装的是15而Gitlab Runner安装的是13，这样产生的runner是无法使用的，也不会报错，如下图，它只会出现在amdin中的Runner中显示出来，而且他的edit也是无法使用的，并不会单独出现在项目的Settings下CI/CD里的Runners里。在注册Runner时，上文提到过，你如果不去添加“external_url”，而且你的端口不是默认的80，在这里需要添加“clone-url”，否则它只会去访问80端口。

# 实例化gitlab-runner
docker run -d --name gitlab-runner --restart always \
-v /srv/gitlab-runner/config:/etc/gitlab-runner \
-v /var/run/docker.sock:/var/run/docker.sock \
gitlab/gitlab-runner:latest

docker run --rm -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register \
 --non-interactive \
 --executor "docker" \
 --docker-image alpine:latest \
 --url "http://172.27.210.177:8083/" \
 --registration-token "GR1348941W_xccj6KnMzQkL4rF_mD" \
 --description "runner1x  \
 --tag-list "runnerx” \
 --run-untagged="true" \
 --locked="false" \
 --access-level="not_protected" \
 --clone-url "http://172.27.210.177:8083/"

4）在SonarQube中创建新的项目，并获得token。

5）在Gitlab项目中填写Editor生成.gitlab-ci.yml，这个文件其实对应了sonar-project.properties，主要配置一些连接信息、扫描要求等。这里需要注意一定要添加“-Dsonar.java.binaries=target/”，否则会报compile的错。

6）之后进入漫长等待。

SourceTree

SourceTree是Git的可视化工具，支持创建、克隆、提交、push、pull、和合并等操作，同时也会显示未提交和未拉取最新代码等提示功能，大大简化了开发者与代码库之间的Git操作方式。在使用时IDEA和禅道会对GitLab改变及时做出反应，但是SourceTree不会，需要每次手动更新。


在IDEA自带的可视化Git工具也很好使用，可以更快速的开发。不过需要注意在IDEA上执行分支合并操作，GitLab远程操作会将Developer的相关分支删除，导致本地分支丢失，如IDEA处于当前分支则分支源代码会全部删除，同时失去git文件导致IDEA与GitLab失联，所以每次merge时一定要及时切换正确的本地分支。

如果使用Github的化，可以使用Github Desktop来实现Git的可视化操作，也是非常方便。

钉钉集成Gitlab

通过钉钉与Gitlab的集成，可以让开发者实时看到Gitlab仓库的变化，从而做出及时的决策。
1）进入钉钉添加助手中。

2）获得机器人webhook地址

3）在Gitlab项目汇总添加webhook，并授予它相关权限。

4）成功实现

实践过程

GitLab与SonarQube协作开发流程图：

与禅道结合流程图：

Gitflow理念

对于GitFlow，流程是，首先项目的开始Master，分出来Develop，在它基础上进行开发；对于一些功能，单独分出来Feature分支，这些分支实现了，提出merge request，经过管理员同意后，在合并到Develop分支上，原来的Feature也会消失；当Develop开发的差不多了，就branch出Release分支，也就是预发布分支；经过测试没什么问题后，就提交到Master，并创建个标签，也就是第一代正式上线产品；如果有了问题，在branch出Hotfix，紧急修复后，在合并到Master，也可以再创个标签。

基于code review的思想，主要是对开发人员进行权限的设置，像是merge的权限，人员的相关各种权限。




在pull，push经常需要对冲突进行解决，需要开发人员进行选择。


在wiki中记录自己的笔记，总结所学知识。

SonarQube的使用

在每一个上传的项目中，有可靠性、安全性、可维护性、覆盖率、重复率五个指标。

我们可以在issue中查看代码的问题所在。其中问题主要分为三个类别，Bug ，编码错误，将破坏代码，需要立即修复。漏洞 ，代码中容易受到攻击的一点。异味，一个可维护性问题，使代码混乱且难以维护。安全热点，可能会出现的安全漏洞。
在每个种类下，错误又分为五个等级。阻塞（Blocked），极有可能影响应用程序的行为的问题，必须立即修复。严重（Critical），可能引起很小的错误或者安全性问题，必须立即检查代码。主要（Main），严重影响开发人员生产力的质量缺陷。次要（Minor），稍微影响开发人员生产力的质量缺陷。提示（Info），不是错误也不是质量缺陷，只是发现。我们可以根据这些来规划出我们处理的优先级。

在每个issue上有相应的生命周期。Open（打开），SonarQube发现问题时自动设置为open。Konfirmed（确认），手动确认此问题。（解决/误判/不会修复）。Resolved（解决），开发人员处理此问题提交代码后，手动设置为己解决。Reopened（重新开放），关闭后的问题SonarQube再次扫描出来，会自动设置为Reopened。Closed（关闭），SonarQube下次扫描时若问题己处理会自动设置为关闭。


官方建议优先修改最新的代码，防止代码变得越来越不易修改，我们可以通过左边工具栏进行日期的过滤。

在代码规则中，我们可以具体查看SonarQube评判代码的规范。

在质量配置中，我们可以自定义选择SonarQube执行的规范，形成自己的代码规范。



我们可以使用SonarLint在IDEA中及时看到代码的问题所在。我们也可以进行相应配置与SonarQube进行连接，让本地的评审与远程一致，更方便开发人员进行修改。

也可以查看代码的复杂度，复杂度越高也就意味着代码出错的概率越大，越不易读懂代码。

可以查看项目的具体大小，像是行数、方法数、文件数等。

查看项目问题整体概览。

查看项目的重复度。

查看项目的活动轨迹。

总结

在两个星期里，完成了以下工作，Gitlab部署，SonarQube部署，Gitlab与SonarQube集成，SonarQube与IDEA集成，并协助禅道小组与Jenkins小组完成整合。熟练使用了Git命令语句，Gitlab的使用，并实现GitFlow理念的操作流程，Git Review的思想，并且借助SourceTree可视化工具的使用，使得代码管理更加方便，代码质量管理工具SonarQube的使用，并与IDEA整合，便于开发者使用，我们也利用wiki以及博客的方式总结我们所学，构件知识库，积累经验。

参考

1. https://blog.csdn.net/Tri_C/article/details/86008480
2. https://blog.csdn.net/bpqdwo/article/details/92770385?spm=1001.2101.3001.6661.1&utm_medium=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7ECTRLIST%7Edefault-1-92770385-blog-81434220.pc_relevant_blogantidownloadv1&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7ECTRLIST%7Edefault-1-92770385-blog-81434220.pc_relevant_blogantidownloadv1&utm_relevant_index=1
3. https://www.bilibili.com/video/BV1Bi4y117Mj?spm_id_from=333.1007.top_right_bar_window_custom_collection.content.click&vd_source=92e059cc3f2abb4a9d79be75e6365393
4. https://www.bilibili.com/video/BV1Bi4y117Mj?spm_id_from=333.337.search-card.all.click&vd_source=92e059cc3f2abb4a9d79be75e6365393
5. https://www.bilibili.com/read/cv11160098
6. https://www.cnblogs.com/bafeiyu/p/12538861.html
7. https://blog.51cto.com/dongweizhen/3607363
8. https://blog.csdn.net/alvinliu2031/article/details/121946666
9. https://zhuanlan.zhihu.com/p/182553920