DevOps持续集成之Git、GitLab、GitLab CI篇
共 1868字，需浏览 4分钟
·
2020-11-07 11:19
为什么要使用Git
分布式
分支管理
节省磁盘空间
大家都在用(GitHub、Gitee、coding.net)
Git使用指南
Git 四个区域:
工作区:就是你克隆项目到本地后，项目所在的 文件夹目录。
暂存区:用于存储工作区中添加上来的变更(新 增、修改、删除)的文件的地方。
本地仓库:用于存储本地工作区和暂存区提交上 来的变更(新增、修改、删除)过的文件的地方。
远程仓库:托管代码的服务器，提供web服务， 供大家方便地进行下载，查看，提交和存储。
Git基本工作流程:
在工作目录中修改文件。
暂存文件，将文件的快照放入暂存区域。
提交更新，找到暂存区域的文件，将快照永久性 存储到 Git 仓库目录。
Git提交规范:
总体原则，从哪个分支checkout的代码就合回那个 分支，避免分支合并混乱导致代码错误。
必须以mergerequest的方式合回主分支，并且有 开发负责人对代码review后才能合入。
当合并发生冲突时，必须解决完冲突才能提交代码 以及合并分支。
分支命名尽量以功能点命名，比如 feature_accessdata，bugfix_dataquery。
Git分支管理最佳实践:
单主干的分支实践(Trunk-based development，TBD)，Google和Facebook都使用这种方式。
Git分支管理最佳实践:
Git-flow的分支实践，是目前流传最广的git分支管理， 围绕的核心概念是版本发布(release)。因此 Git- flow 适用于有较长版本发布周期的项目。
Git-flow 流程中包含 5 类分支，分别是 master、 develop、新功能分支(feature)、发布分支 (release)和 hotfix。
GitLab代码管理
用GitLab-CI进行持续集成
Gitlab-CI是什么?
gitlab-ci是CI/CD里面的一种。
CI/CD:
CI(Continuous integration)持续集成,是一种软件开发实践， 每次代码提交，都通过自动化的构建(包括编译、发布、自动测试)
CD(continuous deployment)持续部署是通过自动化的构建、 测试和部署来快速交付高质量的产品。
gitlab-ci是从gitlab 8.0开始，加入到gitlab中的，我们只需要在 项目中添加一个.gitlab-ci.yml文件，并添加一个gitlab-runner， 即可完成我们的CI/CD操作了。
常见的CI/CD:
jenkins
github上的travis-ci
Drone CI
Gitlab-ci
Gitlab-CI需要了解下面三个概念：
前面讲解了Gitlab-ci中的一些概念，那我们定义的这个构建任务是运行在哪里的呢?
我们需要先下载gitlab runner的工具,下载地址:https://docs.gitlab.com/runner/，然后我们能得到一个gitlab-runner可执行文件，然后 执行gitlab-runner register脚本。
这个脚本需要下面几个参数:
基本写法：
我们在工程里面创建.gitlab-ci.yml，最简单的写法如下: 这是一种类似json的一种描述方法，如果没了解过的可以搜索yaml进行了解。
定义了一个个pipeline，里面有两个stage，test和build。然后先执 行build，再执行test的构建阶段。build构建阶段是job2构成，test 构建阶段由job1构成。分别执行对应的script。
更多的关键字及具体介绍查看官网: http://docs.gitlab.com/ce/ci/yaml/README.html
简单例子：
.gitlab-ci.yml构建任务的定义文件中，描述了stage有 5个阶段。
同时设置了全局的cache。Job only表示只有对应的分 支才会触发运行对应的Jobs。
install_deps:安装依赖
test阶段:运行npmruntest
build阶段:执行build对应的操作
deploy_test阶段:使用pm2部署到测试服务器
deploy_production:部署到生产阶段
以上简单介绍了Git、Git分支策略、GitLab及GitLab CI，关于GitLab在DevOps的更多玩法欢迎大家去实践。
请关注微信公众号 【DevOpsHub】，获取更多关于DevOps研发运维一体化的信息