“CICD”持续集成与持续交付----＞Gitlab |QAQ| Jinkens ----（1）git讲解

“CICD”持续集成与持续交付---->Gitlab |QAQ| Jinkens ----（1）git讲解

1.CICD介绍

大家可能对自动化并不陌生，那什么是CICD呢？

我的理解的话CICD他就是一种利用自动化进行持续集成，持续交付，持续部署的方式，CD代表的是持续交付(Continuous Delivery)，而不是持续部署（Continuous Deploy），因为部署也包括部署到测试环境，而持续交付代表的是功能的上线，交付给用户使用。

​ 那我们使用CICD可以帮助我们完善流水线，加快我们的发部进度，如果大家使用过应该也已在工作中认识到了他的便捷，那么他都有什么优点和缺点呢？这里我们大概来整理一下：

优点：

• 节省时间和成本

缩短了发布周期，保证构建速度不会太慢

• 减少错误

起初需求有理解错了，可能就直接将错误的代码进行上传，还有可能将不好的配置带入流水线

• 避免人工部署

避免依赖人工部署时会因为一些重复性的工作出现错误，机器就可以规避手工容易出错的问题

• 部署灵活性

有了部署流水线，部署的灵活性也会大大提升，在一个全新环境上运行应用程序变成了一件相当简单的事。只要配置好一些关于具体运行环境相关的特定选项，就可以指定版本进行部署了

• 可视化

大家都能看到构建过程及结果，更直观的体现进度

不足：

• 当项目变大时，很难集成。

• 团队缺少互动从而会产生一系列的代码问题。

• CI 不可避免地需要工具，这需要成本。

  存在即合理，并且它的作用已经体现到工作中了，为我们提供了便捷，说明对于我们这个受众群体来说他的优点是大于缺点的，那介绍就到这里结束，我们一起来看一下我们是如果利用Git，Gitlab和jinkens来实现一个持续集成，持续部署的过程吧。

2.Git部署和使用

1. Git简介

首先我们先进行Git的部署和使用，因为我们后面的中间件都是建立在Git之上的，我们进行包的上传更新拉取也都是通过Git，首先我们先准备两台虚拟机。

主机名	IP地址	角色
git	192.168.4.21	git服务端
gitlab	192.168.4.22	git客户端

接下来我们就进行简单的部署，在部署之前可以先检查自己的虚拟机环境，例如IP，yum仓库的配置。

1. 前期环境

[root@localhost ~]# systemctl stop firewalld   ##首先我们先stop掉我们的防火墙
[root@localhost ~]# systemctl disable firewalld    ##关闭我们firewall防火墙开机自启
Removed symlink /etc/systemd/system/multi-user.target.wants/firewalld.service.
Removed symlink /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service.
[root@localhost ~]# sed -i '/^SELINUX=/s/enforcing/disabled/' /etc/sysconfig/selinux 
[root@localhost ~]# cat /etc/sysconfig/selinux | grep "SELINUX=" 
# SELINUX= can take one of these three values:
SELINUX=disabled    ##然后我们利用sed命令去非交互式修改selinux的策略

进行完上述命令的操作，我们就完成了前期基本环境的搭建，当然这是每台机器都需要去执行的操作，因为firewalld和SELINUX会影响我们各个主机之间的通讯，当然在真实的生产环境都会利用物理防火墙设备或者iptable来来进行网络的过滤，当然这方面就不是我们目前需要考虑的问题了，那么我们就步入正题，来进行git的部署和基本操作吧

2. Git部署和 使用

[root@localhost ~]# yum install -y git ##我们首先进行git的安装
[root@localhost ~]# git init /root/gtest/
初始化空的 Git 版本库于 /root/gtest/.git/
[root@localhost gtest]# ls -A 
.git     ##在我们新创建的git目录中都会存在一个隐藏的git文件，可以看看有没有这个文件
[root@localhost gtest]# git config --global user.name MRL
[root@localhost gtest]# git  config --global user.email MRL@zz.cn   ##配置一下我们使用的用户和邮箱
[root@localhost gtest]# git status 
# 位于分支 master
#
# 初始提交
#
无文件要提交（创建/拷贝文件并使用 "git add" 建立跟踪）
[root@localhost gtest]# ls 
[root@localhost gtest]# echo "hello world" > ./readme.txt
[root@localhost gtest]# ls 
readme.txt              ##创建一个readme文件用作测试
[root@localhost gtest]# cat readme.txt 
hello world
[root@localhost gtest]# git add .
[root@localhost gtest]# git status
# 位于分支 master
#
# 初始提交
#
# 要提交的变更：
#   （使用 "git rm --cached <file>..." 撤出暂存区）
#
#       新文件：    readme.txt       ##将文件传到暂存区
[root@localhost gtest]# git commit -m "readme"
[master（根提交） fe1eff5] readme
1 file changed, 1 insertion(+)
create mode 100644 readme.txt     ##将文件进行提交
[root@localhost gtest]# git status 
# 位于分支 master
无文件要提交，干净的工作区
[root@localhost gtest]# git log
commit fe1eff54ab2d4234401e990e87d0e374af311bf7   ##上传快照的唯一ID
Author: MRL <MRL@zz.cn>                     ##上传快照的用户
Date:   Mon Dec 11 13:44:38 2023 -0800         ##上传快照的时间日期

   readme                 ##上传的文件名称
[root@localhost gtest]# git log --pretty=oneline
fe1eff54ab2d4234401e990e87d0e374af311bf7 readme       ##让上传的文件以行显示
[root@localhost gtest]# git log --oneline
fe1eff5 readme          ##让日志更简单的显示，前面的一列是显示文件的唯一ID的前七个字符

上面我们进行文件的制作和上传，包括查看日志的方法，那么我们如果在操作过程中进行了误操作怎么办呢，能不能还原以前的版本呢？下面我们就来统一的操作一下

[root@localhost gtest]# echo "123" > ./1.txt
[root@localhost gtest]# git add .
[root@localhost gtest]# git commit -m "新增1.txt"
[root@localhost gtest]# echo 'one two three' > ./2.txt
[root@localhost gtest]# git add .
[root@localhost gtest]# git commit -m "增加2.txt"
[root@localhost gtest]# git log --oneline 
a41eace 增加2.txt
536af48 新增1.txt
fe1eff5 readme
[root@localhost gtest]# ls 
1.txt  2.txt  readme.txt
[root@localhost gtest]# git reset --hard 536af48
HEAD 现在位于 536af48 新增1.txt
[root@localhost gtest]# ls 
1.txt  readme.txt           

可以看到我们上述测试已经将版本还原了，回溯到新增1.txt的时候，那么支持我们达到这种操作的就是HARD指针，HEAD是一个可移动的指针，它可以指向任何分支或版本，通过移动指针，可以将数据还原至任何版本。

Git分支

使用分支可以把我们的工作从开发主线上分离开来，以免影响开发主线。分支分为Master主分支，Develop开发分支，Release预发行分支等，当然这些在我们这次的测试中基本不会使用，如果大家有需求可以去了解一下，下面我们就简单测一下分时的合并和使用

[root@localhost gtest]# git branch 
* master      ##查看分支
[root@localhost gtest]# git branch z1
[root@localhost gtest]# git branch 
* master
  z1            ##创建分支
[root@localhost gtest]# git checkout z1
切换到分支 'z1'       ##切换分支           我们将测试在分支z1上上传文件到主分支master上
[root@localhost gtest]# echo "456" > ./ok.txt
[root@localhost gtest]# git add .
[root@localhost gtest]# git commit -m "Z1分支提交"
[z1 18241eb] Z1分支提交
 1 file changed, 1 insertion(+)
 create mode 100644 ok.txt
Already up-to-date.
[root@localhost gtest]# git checkout master 
切换到分支 'master'
[root@localhost gtest]# ls 
1.txt  readme.txt
[root@localhost gtest]# git merge z1 -m "合并分支内容"
更新 536af48..18241eb
Fast-forward (no commit created; -m option ignored)
 ok.txt | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 ok.txt
[root@localhost gtest]# ls 
1.txt  ok.txt  readme.txt

还有git标签功能但是咱们就不详说了，接下来我们就进行gitlab的认识，gitlab相对于git来说少一些命令行的输入，但是更好理解，下一篇文章我们就一起测试Gitlab的部署和使用。