Gitlab的落地与应用(二)测试代码接入Gitlab实践

大刚测试开发实战

发布于 2022-11-14 14:16:35

7570

发布于 2022-11-14 14:16:35

写在前面

在上一篇私有化代码仓库Gitlab的落地与应用(一)中，重点介绍了Gitlab的搭建过程、数据迁移、自动备份等内容，本篇内容将重点回顾测试团队代码接入Gitlab的过程及经验。在正式开始前，先简述一下我们团队当前测试代码管理的现状、所面临的问题以及采用统一管理代码的优缺点分析

1.研发及测试团队代码管理现状

后端用的SVN、前端用的Gitlab
测试暂无统一代码管理，各人维护各人代码，或本地管理，或提交GitHub、Gitee等个人账户

2.未统一代码管理面临的问题：

各人维护各人代码，无法有效协同
各自为战，编码风格各异
编码进度无法感知
公共类、方法等需要编写和维护多份
无法有效利用他人编写的好用的测试方法、测试用例等，重复造轮子

3.测试代码统一管理的优缺点分析

优点：

协同编码，编码进度团队全员感知
统一编码风格，形成内部规范
避免重复造轮子，代码再利用
借鉴他人优秀设计经验
便于后期接入CICD流水线
团队的力量大于个人的力量
丰富测试框架能力
团队经验&能力沉淀

缺点：

需要一定Git基础(当然也可以借助source tree、pycharm、idea等工具进行管理)
前期没有约定好协同规范时易造成提交/拉取代码冲突
需要改变原有编码习惯、适用团队内部约定的统一的编码风格
一定的测试框架培训和学习成本：封装、分层、调用逻辑等

本文大纲

由于测试代码接入Gitlab需要了解Git一些原理及概念，因此：

前半部分为Git相关概念及原理的简介，涉及的内容有：

Git VS SVN：区别、优缺点分析、适用场景
Git各个目录的作用
Git核心概念：4个分区、3个步骤、5种状态

后半部分为测试代码接入Gitlab的实践过程，涉及的内容有：

Git环境搭建：生成密钥、建立连接、记住密码
测试代码接入Gitlab过程：创建仓库、克隆代码、提交代码、运行测试等

一、Git VS SVN

1.Git与SVN的区别

1）版本号区别：

Git分布式版本管理系统，采用40位长的哈希值作为版本号，不会出现重复；
SVN 的版本号是连续的，可以预判下一个版本号；

2）代码检出区别：

SVN中，每个子目录下都维护着自己的.svn目录，记录着该目录中文件的修改情况以及和服务器端仓库的对应关系。SVN可以checkout部分路径下的内容（部分检出），而不用 checkout整个版本库或分支；
Git的本地仓库信息完全维护在project根目录的.git目录下，没有部分检出的概念；

3）分支实现的区别：

SVN的分支和标签都是来自目录拷贝，通常拷贝在 branches/和tags/目录下，所谓分支、 tag等只是仓库中不同路径上的一个对象或索引；
Git中的分支实际上仅是一个包含所指对象校验和（40个字符长度SHA-1 哈希值）的文件。Git的分支是完全隔离的，一个提交一般只能发生在一个分支中；

2.Git与SVN的优缺点分析及适用场景

1）SVN优点：

管理方便，逻辑明确，符合一般人思维习惯；
代码一致性非常高；
易于管理，集中式服务器更能保证安全性；
适合开发人数不多的项目开发；

2）SVN缺点：

服务器压力太大，数据库容量暴增；
如果不能连接到服务器上，基本上不可以工作；
不适合开源项目或者大型团队协作开发的项目；

3）Git优点：

适合分布式团队多人协作，敏捷开发；
公共服务器压力和数据量都不会太大；
速度快、灵活、可离线工作；
任意两个开发者之间可以很容易的解决冲突；

4）Git缺点：

学习成本相对较高；
代码保密性差，个别开发克隆整个仓库后便可公开所有信息；

二、Git各目录作用

hooks目录：存放预置脚本，如代码检查的脚本；
logs目录：提交代码的日志信息，按照分支来进行记录；
config文件：存放项目的配置信息；
index文件：暂存区，git add后的内容；
HEAD文件：记录当前的分支指向；

三、Git核心概念

1.四个区

Workspace：工作区，为电脑中存放代码的目录；
Index / Stage：暂存区，类似于缓存区域，临时保存改动代码的地方；
Local Repository：仓库区（或本地仓库），在.git目录下；
Remote Repository：远程仓库；

2.三个步骤

git add 把文件放入暂存区；
git commit 把文件从暂存区提交至本地仓库；
git push 把文件从本地仓库推送至远程仓库；

3.五种状态

Git对应的4个区，进入每一个区成功之后会产生一个状态，再加上最初始的一个状态，一共是5种状态：

未修改(Origin)
已修改(Modified)&未追踪(Untracked)
已暂存(Staged)
已提交(Committed)
已推送(Pushed)

四、Git环境搭建

1.下载

Windows下，下载后双击安装即可

官方网站：https://git-scm.com/downloads

淘宝镜像：https://npm.taobao.org/mirrors/git-for-windows/

2.配置个人信息

git config --global user.name "姓名"   # 设置用户姓名
git config --global user.email "联系邮箱"  # 设置邮箱地址 
git config --global --list  # 查看全局配置列表

3.生成SSH密钥

ssh-keygen -t rsa -C "your_email@example.com"  # -C 备注信息、没有实际作用;-f 指定生成的文件名称;

生成密钥主要是为了使本机和服务器之间进行配对识别、免密通信，公钥上传到服务器，私钥保存于本地。生成的密钥文件默认保存在C:\Users\Administrator.ssh\目录下：id_rsa是私钥，id_rsa.pub是公钥；

若同一份代码想要托管在多个平台，则可以生成多份密钥对，名字区分开，如下图所示：

4.验证服务器连通性

① 编写配置文件

在用户目录的.ssh目录下新建config文件，配置密钥路径，各个Host需要与各个私钥文件一一对应

② 将公钥文件的内容拷贝到服务器仓库

Gitlab的设置-SSH密钥-添加SSH密钥

③ 验证服务器连通性

可以通过以下命令进行验证，若验证成功，则会提示欢迎语，若验证不成功，则可以借鉴下一步记住密码的方法后，再次进行验证：

ssh -T git@192.168.1.211

注意事项：

首次认证可能需要确认连接、提示登录用户名密码等

若SSH端口号不是默认的22，则ssh地址前需要带上ssh://

5.SSH方式记住密码

eval $(ssh-agent)  # 先开启一个ssh代理
ssh-add ~/.ssh/id_rsa  # 再将私钥文件添加到代理，前提是：①已生成密钥对②公钥文件已添加到Gitlab、GitHub等平台

验证结果：

五、测试代码接入Gitlab过程

1.创建远程仓库

前面环境搭建等前期工作准备好后，就可以正式进入测试代码接入远程仓库的过程了。首先需要创建一个远程仓库：

这里需要说明一点的是，如果希望这个项目是被本团队成员访问，那么需要提前在Gitlab中创建一个组织，然后向里面添加指定的成员，在创建项目时，可见性级别选择“私有”。这样，此项目就是仅团队成员可见了。

创建完成后，会给出命令指引：

2.推送现有的文件夹至远程仓库

由于我本地已经存在了代码工程的目录，因此这个地方可以选择“推送现有文件夹”这一方式。当然，如果你的目录已经关联过其他仓库，也可以选择最后一种“推送现有的Git仓库”。整体过程分为5步：

① 初始化目录

cd auto_test_project  # 我的工程目录名为auto_test_project，先进入目录
git init --initial-branch=main # 初始化目录，若在仓库外操作，则需带上目录名称

② 本地目录关联远程仓库

git remote add origin git@192.168.1.211/test_team/auto_test_project.git  # 关联远程仓库

关联成功后，项目的配置文件config中会新增关联的远程仓库信息，这里取名origin，也可以叫其他名字，后期也可以修改

③ 将工作区文件添加到暂存区

git add .  # . 是添加所有文件，也可以带上文件或文件夹名添加指定文件或目录

④ 将暂存区文件提交到本地仓库

git commit -m "首次提交"

⑤ 本地仓库提交远程仓库

git push origin main

提交后的项目详情页面：

3.其他成员克隆代码

以上代码提交至远程仓库后，其他小伙伴在同样搭建了Git环境、建立与服务器连接等前期工作后，就可以克隆代码到他的本机了

git@192.168.1.211/test_team/auto_test_project.git

4.各个成员编写、提交代码

其他团队成功在完成各自的编码任务后，即可提交代码至远程仓库。值得注意的是，提交代码需要团队内部提前约定好规则，如：每次提交代码前，先拉取、再提交；下图为项目组各个成员的提交记录：

小结

以上，就是测试代码接入Gitlab的总体过程，整体没什么技术难度，主要为一次内部的实践记录，所以写的比较粗糙，很多细节点，如：代码冲突如何处理，包含各自测试账号的配置文件是否需要提交，包含测试各自测试数据的数据文件如何处理等都没有提及；还有Git常用操作命令也没有详细列出，不过网上随便就能找到一大堆，在此就不过多赘述。下面总结一下本次实践心得：