03-GitLab+Jenkins

一、GitLab

1、安装

• 官网：https://about.gitlab.com/
• 参考文档：https://docs.gitlab.com/ee/ci/
• 清华大学软件包下载地址：https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/
• 版本介绍： CE（社区版）、EE（企业版）

1. 上传rpm软件包

在线下载安装包：
wget https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el6/gitlab-ce-12.4.2-ce.0.el6.x86_64.rpm

2. 安装指令

[root@gitlab ~]# yum -y install gitlab-ce-14.1.0-ce.0.el7.x86_64.rpm

2、配置GitLab URL

• 修改主配置文件：/etc/gitlab/gitlab.rb

[root@gitlab ~]# vim /etc/gitlab/gitlab.rb
# 修改端口
listen_port = 82

...
external_url 'http://192.168.0.24' --本机IP

修改完主配置文件后，使用gitlab-ctl reconfifigure重新配置gitlab使配置生效

[root@gitlab ~]# gitlab-ctl reconfigure

查看服务状态

[root@gitlab ~]# gitlab-ctl start
[root@gitlab ~]# gitlab-ctl status

3、GitLab服务参数

常用参数如下：

路径	作用
/opt/gitlab	应用代码和相应的依赖程序
/etc/gitlab	配置文件目录
/etc/gitlab/gitlab.rb	gitlab配置文件
/var/log/gitlab	itlab各个组件产生的日志
/var/opt/gitlab/git-data/repositories	库默认存储目录
/var/opt/gitlab/backups/	备份文件生成的目录
/var/opt/gitlab/gitlab-rails/etc/unicorn.rb	unicorn配置文件
/var/opt/gitlab/nginx/conf/gitlab-http.conf	nginx配置文件

4、常用指令

指令	作用
gitlab-ctl start	启动全部服务（也可指定单个服务）
gitlab-ctl restart	重启全部服务（也可指定单个服务）
gitlab-ctl stop	停止全部服务（也可指定单个服务）
gitlab-ctl reconfifigure	使配置文件生效（修改主配置文件后使用）
gitlab-ctl show-confifig	验证配置文件
gitlab-ctl uninstall	卸载gitlab（保留数据）
gitlab-ctl cleanse	删除所有数据，从新开始
gitlab-ctl tail	查看服务的日志

5、关闭GitLab组件

由于GitLab核心功能是代码托管，避免资源浪费，有些额外的组件是不需要的，可以考虑关闭掉重新配置GitLab

#修改gitlab配置文件，关闭不需要的组件
[root@gitlab ~]# vim /etc/gitlab/gitlab.rb
#...该配置所在行数仅供参考，不同版本，有所差异，可搜索关键字查询
1801 prometheus['enable'] = false
1802 prometheus['monitor_kubernetes'] = false
1879 alertmanager['enable'] = false
1902 node_exporter['enable'] = false
1921 redis_exporter['enable'] = false
1939 postgres_exporter['enable'] = false
1970 gitlab_exporter['enable'] = false
1984 prometheus_monitoring['enable'] = false
1991 grafana['enable'] = false

重新配置

[root@gitlab ~]# gitlab-ctl reconfigure
[root@gitlab ~]# gitlab-ctl status

6、登录GitLab

• 浏览器访问GitLab服务器地址：http://server_ip

默认用户名：root

密码：rootroot

root初始密码所在文件：/etc/gitlab/initial_root_password

7、修改密码

通过个人资料中心修改root密码：

密码不验证复杂度，长度需满足8位：

设置密码后会跳转到登录页面重新登录

8、修改页面语言

在个人资料页面，也可以修改页面语言：

保存后刷新页面（提示：部分内容还没有支持中文）

9、定制logo

点击左上角的 **菜单（**Menu）→*Admin→设置→外观 处可以进行一些个性化设置：

配置完成后点击最下方的更改外观设置，退出账号重新登录时可看到更改后的外观。

关闭注册功能

由于我们Gitlab系统是私有仓库，一般用户都是由管理员创建和分派的，所以我们可以关闭注册功能，左上角 菜单（Menu）→管理（Admin）→通用 找到注册限制取消掉注册功能

下拉点击 **保存更改（**Save changes）

创建群组

群组就是把相关的项目和用户放在一起，进行统一的权限管理，点击 菜单（Menu）→管理（Admin）**点击 **新建群组

在可见性级别处我们选择私有，这样只有经过授权的用户才可以看到该组内的项目，其他用户无法查看，配置完相关信息点击最下方的创建群组

创建项目

回到Admin页面点击 新建项目→创建空白项目

此时我们会看到跟GitHub类型的一个指引页面，指引我们如何创建仓库或推送本地仓库到GitLab

设置SSH Key

在页面上方会出现添加SSH密钥的提示，此时可以按照提示添加：

安装git工具

#安装Git工具
yum -y install git

命令	功能
git init	初始化代码仓库
git config --global user.name	创建git用户
git config --global user.email	创建git用户邮箱
git add .	将文件提交至暂存区
git status	查看仓库当前状态，显示有变更的文件
git commit -m	提交暂存区到本地仓库
git remote	查看本机的远程仓库
git remote remove	仓库名称 删除远程仓库
git push	上传本地代码到远程仓库

配置git用户以及邮箱，因为每次Git提交都会使用该用户信息

#格式：git config --global user.name '用户名'
git config --global user.name "yesir"
#格式：git config –global user.email '邮箱'
git config --global user.email "yesir@example.com"

配置高亮颜色显示（增加体验感） 如果这个信息不配置，那么你与Git交互时，所有字体的颜色都将是默认系统的一个颜色

git config --global color.ui true

推送项目到GitLab

#先将前边添加的GitHub远程仓库删除掉
[root@gitlab data]# git remote remove origin
#添加远程仓库到本地
[root@gitlab data]# git remote add origin
git@192.168.0.24:test/choujiang.git
#推送本地项目到远程仓库
[root@gitlab data]# git push -u origin --all

创建用户

点击 **菜单（**Menu）→管理（Admin）→新建用户

其他默认即可，点击最下方创建用户

创建后，通过右上角编辑按钮为用户设置密码

点击最下方保存修改

接下来可以使用zhangsan用户登录（用户首次登录系统要求更改密码）

提示：此时zhangsan用户的身份是普通用户，就类似于我们在GitHub的身份一样。

提示：zhangsan用户也可以设置页面语言

• Guest:可以创建issue、发表评论，不能读写版本库
• Reporter: 可以克隆代码，不能提交，QA、PM可以赋予这个权限
• Developer:可以克隆代码、开发、提交、push，普通开发可以赋予这个权限
• Maintainer:可以创建项目、添加tag、保护分支、添加项目成员[编辑项目，核心开发可以赋予这个权限
• Owner: 可以设置项目访问权限 -Visibility Level、删除项目、迁移项目、管理组成员，开发组组长可以赋予这个权限

授权用户

我们需要将用户添加到对应的项目组内，他才能对组内项目进行管理，将

zhangsan添加至test组。

点击 **菜单（****Menu）→管理（Admin）在右下角找到test组：

将张三加入到test组，并赋予开发者（Developer）权限，此时zhangsan用户在GitLab可查看到自己所在组项目。

以下是对GitLab上几种用户身份及权限的介绍：

Guest：可以创建提问、发表评论，不能读写版本库。

Reporter：可以克隆代码，不能提交，QA（测试）、PM（产品经理）可以赋予这个权限。

Developer：可以克隆代码、提交代码、修改代码，普通开发可以赋予这个权限。

Maintainer：可以创建项目、添加标签、保护分支、添加项目成员、编辑项目，核心开发可以赋予这个权限。

Owner：可以设置项目访问权限 - Visibility Level、删除项目、迁移项目、管理组成员，开发组组长可以赋予这个权限。

二、Jenkins安装和持续集成环境配置

• 项目拉取下来的默认路径：/var/lib/jenkins/workspace

1、安装

1. 安装jdk1.8

yum install java-1.8.0-openjdk* -y

安装目录为：/usr/lib/jvm

2. 获取jenkins安装包

• 下载页面：https://jenkins.io/zh/download/

3. 安装

rpm -ivh jenkins-2.190.3-1.1.noarch.rpm

4. 修改Jenkins配置

vi /etc/syscofig/jenkins
修改内容：
JENKINS_USER="root"
JENKINS_PORT="8888"

5. 启动Jenkins

systemctl start jenkins

6. 访问

http://192.168.227.102:8888

7. 获取并输入admin账户密码

cat /var/lib/jenkins/secrets/initialAdminPassword

8. 跳过安装界面

• 因为Jenkins插件需要连接默认官网下载，速度非常慢，而且经过会失败，所以我们暂时先跳过插件安装

9. 添加一个管理员账户，并进入Jenkins后台

2、插件管理

修改Jenkins插件下载地址

Jenkins国外官方插件地址下载速度非常慢，所以可以修改为国内插件地址：

Jenkins->Manage Jenkins->Manage Plugins，点击Available

这样做是为了把Jenkins官方的插件列表下载到本地，接着修改地址文件，替换为国内插件地址

cd /var/lib/jenkins/updates
sed -i 's/http:\/\/updates.jenkins-ci.org\/download/https:\/\/mirrors.tuna.tsinghua.edu.cn\/jenkins/g' default.json && sed -i
's/http:\/\/www.google.com/https:\/\/www.baidu.com/g' default.json

# 最后，Manage Plugins点击Advanced，把Update Site改为国内插件下载地址
https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json

Sumbit后，在浏览器输入：

http://192.168.66.101:8888/restart ，重启Jenkins。

安装汉化插件

重启Jenkins后，就看到Jenkins汉化了！（PS：但可能部分菜单汉化会失败）

3、用户权限管理

3.1、创建角色

jenkins是通过角色的配分给予用户权限的。

点击"Manage Roles"

• Global roles（全局角色）：管理员等高级用户可以创建基于全局的角色
• Project roles（项目角色）：针对某个或者某些项目的角色 Slave roles（奴隶角色）：节点相关的权限

我们添加以下三个角色：

• baseRole：该角色为全局角色。这个角色需要绑定Overall下面的Read权限，是为了给所有用户绑定最基本的Jenkins访问权限。注意：如果不给后续用户绑定这个角色，会报错误：用户名 ismissing the Overall/Read permission
• role1：该角色为项目角色。使用正则表达式绑定"itcast."，意思是只能操作itcast开头的项目。
• role2：该角色也为项目角色。绑定"itheima.*"，意思是只能操作itheima开头的项目。

保存。

3.2、创建角色

在系统管理页面进入 Manage Users

分别创建两个用户：jack和eric

3.3、角色分配

系统管理页面进入Manage and Assign Roles，点击Assign Roles

绑定规则如下：

• eric用户分别绑定baseRole和role1角色
• jack用户分别绑定baseRole和role2角色

3.4、创建项目测试权限

以itcast管理员账户创建两个项目，分别为itcast01和itheima01

结果为：

• eric用户登录，只能看到itcast01项目
• jack用户登录，只能看到itheima01项目

4、集成gitlab-ctl

接下来就可以使用Jenkin从Gitlab拉取代码到jenkins本机进行后续的发布工作：

具体流程：

• 创建Jenkins与GitLab认证凭据
• Jenkins拉取项目到Jenkins本地
• 通过脚本自动发布项目到Nginx服务器

Jenkins服务器安装git工具

[root@jenkins ~]# yum -y install git

Jenkins创建凭据用于从GitLab拉取项目时的一种认证方式，点击右上角的Admin后在左侧栏可以看到凭据选项，点击凭据后如下图：

5、手动发布项目

1. 部署nginx服务器
2. 通过Shell部署项目

#创建一个目录，用于存放项目的发布脚本
[root@jenkins ~]# mkdir /var/lib/jenkins/script && cd /var/lib/jenkins/script
#以下是项目发布的脚本内容
cat deploy-nginx.sh
#!/bin/bash
#发布项目到Nginx
#定义Nginx网页根目录
WEB_DIR=/usr/share/nginx
#定义Jenkins项目所在路径
CODE_DIR=/var/lib/jenkins/workspace/choujiang
#项目发布时间
TIME=`date +%F-%H-%M-%S`
#打包项目
cd $CODE_DIR && tar -zcf /tmp/web-$TIME.tar.gz ./*
#发布项目
for IP in `cat /var/lib/jenkins/script/nginx`
do
    scp /tmp/web-$TIME.tar.gz root@$IP:$WEB_DIR
    ssh root@$IP "cd $WEB_DIR && mkdir web-$TIME"
    ssh root@$IP "cd $WEB_DIR && tar -xf web-$TIME.tar.gz -C web-$TIME && rm -rf web-$TIME.tar.gz"
    ssh root@$IP "cd $WEB_DIR && rm -rf html && ln -s web-$TIME html"
done
#把nginx主机的IP地址写到这个文件里
vim nginx 
server_ip

#添加执行权限
chmod +x deploy-nginx.sh

6、自动化部署项目

1. 配置Jenkins用户免密发布项目到Nginx的服务器

jenkins用户默认的权限就是nologin，这个权限是最低的权限不能登录

#切换到Jenkins用户
usermod -s /bin/sh jenkins && su - jenkins
#生成密钥文件
-sh-4.2$ ssh-keygen
#将公钥传给Nginx
-sh-4.2$ ssh-copy-id root@server_ip
#切换到脚本路径执行脚本（主要是首次连接需要确认yes，否则Jenkins直接
构建会失败）
-sh-4.2$ cd script/
-sh-4.2$ ./jenkins-nginx.sh

2. 回到 Jenkins的choujiang任务点击 设置→构建→增加构建步骤→Execute shell（shell命令）

7、自动发布项目

本实验实现只要GitLab的master分支有新代码提交，Jenkins 自动触发Build New（立即构建）功能，实现代码自动发布。

1）安装GitLab构建触发器插件 左侧栏 Manage Jenkins（管理Jenkins）→ Manage Plugins（管理插件）

2）构建webhook触发器

插件安装完毕后，进到任务中，在构建触发器会新增一个触发器选项，选择它并设置对应触发事件，具体配置如下图：

3）GitLab设置webhook

回到GitLab的choujiang项目中点击左侧 设置→webhooks 粘贴Jenkins的令牌到Secret token处：

提示：Webhooks的网址为Jenkins任务中构建触发器指定的地址，复制地址到GitLab的网址处。

上述操作表示当GitLab的choujiang项目中有新代码上传或合并到master分支后，GitLab通过令牌通知Jenkins触发构建操作。

配置完成后点击最下方的Add webhook会出现如下报错：

原因：gitlab 10.6 版本以后为了安全，不允许向本地网络发送webhook请求。

解决方法：通过 Menu→Admin→设置→网络→外发请求 配置如下图：

点击保存更改。

再次回到项目中重新添加并验证结果：

在页面最下方验证项目钩子，展开测试栏后点击Push events（推送事件）选项进行钩子测试：

8、jenkis返回构建状态到GitLab

Jenkins每次自动构建完成后可以把构建的结果反馈给Gitlab，这样在Gitlab上就可以查看每一次构建的结果。

1）首先在Jenkins上配置，打开 Manage jenkins（管理Jenkins）→confifigure System（系统设置）下拉找到GitLab部分

他需要一个API token，通过GitLab地址在结合GitLab生成的token就可以把结果反馈到GitLab，接下来还要去GitLab 生成一个token。

2）GitLab 生成一个token，具体流程如下：

创建后会在页面上方生成token：

回到Jenkins粘贴令牌创建凭据：

凭据添加成功后选择它，并Test Connection（测试访问）：

3）Jenkins增加构建后操作步骤

构建后操作就是你构建完以后，可以做些什么事情，我们希望某个项目构建后，就将结果返回到GitLab时，我们需要在具体任务中配置构建后操作骤，进到任务中点击 配置→构建后操作→步骤具体配置如下图：

回到任务主页面，执行Build Now：

三、Maven

1、maven安装

• 官网：http://maven.apache.org/download.cgi
• 清华大学仓库：https://mirrors.tuna.tsinghua.edu.cn/apache/maven/

Jenkins安装Maven（Maven是Java开发，运行需要配置JDK境）

[root@jenkins ~]# tar -xf apache-maven-3.8.1-bin.tar.gz
[root@jenkins ~]# mv apache-maven-3.8.1 /usr/local/maven
[root@jenkins ~]# ls /usr/local/maven

将 Maven 的 bin 目录添加到 PATH 环境变量以便后续使用mvn命令

#编辑/etc/profile文件
[root@jenkins ~]# vim /etc/profile
export PATH=/usr/local/maven/bin/:$PATH --在末尾添加
#使用source使配置生效
[root@jenkins ~]# source /etc/profile
#命令验证
[root@jenkins ~]# mvn -v

2、maven目录结构

• boot：该目录只包含一个文件plexus-classworlds-2.5.2.jar是一个类加载器框架，Maven使用该框架加载自己的类库，对于一般的 Maven 用户来说，不必关心该文件。
• conf：该目录包含了一个非常重要的settings.xml文件，是Maven的全局配置文件。
• lib：该目录包含了所有 Maven 运行时需要的 Java 类库。
• LICENSE：记录了 Maven 使用的软件许可证 。
• NOTICE：记录了 Maven 包含的第三方软件。
• README.txt：包含了 Maven 的简要介绍，包括安装需求及如何安装的简要指令等。

3、maven入门

命令	功能
mvn package	生成war
mvn clean	清空生成的文件

首先上传一个Java源码项目

[root@jenkins ~]# unzip spring-source-mvc-ano-v1.0.zip
[root@jenkins ~]# cd spring-source-mvc-ano-v1.0

mvn clean 命令用于清理项目产生的临时文件（在打包之前先执行清理工作）

[root@jenkins spring-source-mvc-ano-v1.0]# mvn clean

所有的项目配置信息都被定义在一个叫做POM.xml的文件中， 包含了项目的基本信息，用于描述项目如何构建，声明项目依赖等等，Maven会在当前目录中查找POM，读取POM，获取所需的配置信息，然后执行目标。

[root@jenkins spring-source-mvc-ano-v1.0]# mvn package
...
[INFO] BUILD SUCCESS --出现该提示表示构建成功
在target目录中就会发现有war文件

4、Maven仓库配置

本地仓库：本地仓库在安装 maven 后并不会创建，它是在第一次执行maven 命令的时候才被创建，maven 本地仓库的位置无论是 Windows 还是 Linux，在用户的家目录下都有一个.m2/repository/的仓库目录。

[root@jenkins ~]# ls -a /root/.m2
. .. repository

远程仓库：由于默认的官方maven仓库在国内下载速度太慢， 我们往往不会使用默认的中央仓库， 不仅是速度慢，可能项目的某些依赖中央仓库是没有的，而其他远程仓库中有，如最常用的是阿里Maven仓库。

修改配置文件重新指定仓库位置（提示：修改之前做个备份）

[root@jenkins ~]# vim /usr/local/maven/conf/settings.xml
...
<!-- 阿里云仓库 -->
<mirror>
    <id>alimaven</id>
    <mirrorOf>central</mirrorOf>
    <name>aliyun maven</name>
    <url>http://maven.aliyun.com/nexus/content/repositories/central/</url>
</mirror>

保存后回到项目中打包并观察依赖的下载地址：

#先执行清理在打包
[root@jenkins spring-source-mvc-ano-v1.0]# mvn clean

[root@jenkins spring-source-mvc-ano-v1.0]# mvn package

5、构建Maven项目

保存后我们解决Maven安装路径问题，回到主页面点击 Manage Jenkins**（管理Jenkins）→ Global Tool Confifiguration**（全局工具配置）下拉找到 maven 配置项，点击 新增Maven，把Install automatically（自动安装maven）的勾选取消掉，应为我们是手动安装的maven，所以Jenkins不知道具体安装路径，如下图：

再次回到任务中检查 Build（构建）发现提示消失。

[root@jenkins ~]# ls /var/lib/jenkins/workspace/mavenjob/target/
spring-source-mvc-ano-1.0-SNAPSHOT.war --这个war包就是构建
出来的web项目

JAR包：就是Java项目的依赖工具
WAR包：Java项目都是打成war包进行发布，将war包放在tomcat的webapps下，并且tomcat服务器能够自动识别，能够对war包进行自动解压

6、部署Tomcat

准备一台机器安装Tomcat服务（实验环境可以跟前边的Nginx部署在同一台机器，不冲突）

[root@tomcat ~]# yum -y install java-1.8.0-openjdk
[root@tomcat ~]# tar -xf apache-tomcat-8.0.30.tar -C /usr/local/
[root@tomcat ~]# mv /usr/local/apache-tomcat-8.0.30/ /usr/local/tomcat
[root@tomcat ~]# /usr/local/tomcat/bin/startup.sh

7、Jenkins发布Java项目

cat /var/lib/jenkins/script/jenkins-tomcat.sh
#!/bin/bash
#发布项目到tomcat
#定义tomcat网页根目录
WEB_DIR=/usr/local/tomcat/webapps/
#定义Jenkins项目所在路径
CODE_DIR=/var/lib/jenkins/workspace/maven-job/target
#项目发布时间
TIME=`date +%F-%H-%M-%S`
#打包项目
cd $CODE_DIR && tar -zcf /tmp/web-$TIME.tar.gz ./*.war
#发布项目
for IP in `cat /var/lib/jenkins/script/tomcat.txt`
do
    scp /tmp/web-$TIME.tar.gz root@$IP:$WEB_DIR
    ssh root@$IP "cd $WEB_DIR && mkdir web-$TIME"
    ssh root@$IP "cd $WEB_DIR && tar -xf web-$TIME.tar.gz -C web-$TIME && rm -rf web-$TIME.tar.gz"
    ssh root@$IP "cd $WEB_DIR && rm -rf ROOT* && \cp web-$TIME/*.war ROOT.war"
done

注意：Tomcat会自动解压war包，并且生成一个Root目录（用户访问目录）

#准备for循环的主机地址
cat /var/lib/jenkins/script/tomcat.txt
192.168.0.26

chmod +x jenkins-tomcat.sh

回到Jenkins任务中增加构建步骤

• 访问：http://server_ip:8080

四、Jenkins Pipline

Jenkinsfifile是用来编写 Pipeline 的脚本语法，在一个Pipeline中有如下几个基础概念：

• pipeline：声明此语法是声明式（Declarative）式语法（还有一种脚本式的语法）
• agent：是指定执行Step的具体节点，any表示所有（在Jenkins分布式环境下可以指定具体节点去执行任务）。
• stages：代表构建项目的阶段开头，里边包含多个stage。
• Stage（阶段）：一个Pipeline由多个Stage组成，每个Stag（阶段）可包含多个Step（步骤）。
• Steps（步骤）：可以是拉取代码、构建项目、发布项目等。

pipeline{
	agent any
    stages{
        stage("下载源码"){
            steps{
            	echo "get code from scm"
            }
        }
        stage("构建源码"){
            steps{
            	echo "packge code"
            }
        }
        stage("发布项目"){
            steps{
                echo "deploy"
        	}
        }
	}
}

Pipeline Job 示例

创建一个Pipeline（流水线）项目，点击 新建****Item 后如下图：

构建完成后，在页面以图形的形式显示 pipeline 的结构，点击对应的位置可以查看构建执行的情况。

案例：通过Pipeline发布项目

pipeline{
	agent any
	stages{
        stage("下载源码"){
            steps{
            //通过git拉取源码（通过流水线语法自动生成）
            git credentialsId: 'cf334a67-eee1-49e2-9a7b-5c2452b1398a',
            url:'http://web.gitlab.com/test/spring-source.git'
            }
		}
        stage("构建源码"){
            steps{
            	//进入到源码路径，通过mvn构建源码
            	sh "cd /var/lib/jenkins/workspace/springsource/ && /usr/local/maven/bin/mvn package"
            }
        }
        stage("发布项目"){
            steps{
                //通过脚本发布项目
                sh "/var/lib/jenkins/script/deploytomcat.sh"
        	}
		}
	}
}

五、面试题

一、DevOps 术语和定义

什么是DevOps

DevOps将开发（Development）和运维（Operations）两个环节紧密结合，通过自动化、持续集成和持续交付等实践，提高软件开发的速度、质量和稳定性。

什么是持续集成

持续集成（Continuous integration,缩写为Cl）是一种软件开发实践，团队开发成员经常集成他们的工作。

它强调开发人员经常性地将代码提交到共享仓库中，而不是等到整个功能开发完成再进行集成。这样可以及早发现潜在的冲突、错误和兼容性问题，从而更快地解决这些问题，提高软件交付的速度和质量。

什么是持续交付

持续交付（Continuous delivery,缩写为CD）以及持续集成为交付代码包提供了完整的流程。

持续交付的目标是实现软件交付的快速性、可靠性和可重复性。它强调在每次代码变更后，自动化地构建、测试和部署软件，以便随时都能够将新功能或修复的问题交付给用户。这种方式与传统的周期性发布相比，可以减少发布周期，更加灵活地响应用户需求。

什么是持续部署

持续部署(Continuous deployment)通过集成新的代码更改并将其自动交付到发布分支，从而将持续交付提升到一个新的水平。

更具体地说，一旦更新通过了生产流程的所有阶段，便将它们直接部署到最终用户，而无需人工干预。

因此，要想成功利用连续部署，软件工件必须先经过严格建立的自动化测试和工具，然后才能部署到生产环境中。

持续测试及其优点

连续测试是一种在软件交付管道中尽早、逐步和适当地应用自动化测试的实践。

在典型的CI/CDT作流程中，将小批量发布构建。因此，为每个交付手动执行测试用例是不切实际的。

自动化的连续测试消除了手动步骤，并将其转变为自动化例程，从而减少了人工。

因此，对于DevOps文化而言，自动连续测试至关重要。

持续测试的好处:

确保构建的质量和速度。

支持更快的软件交付和持续的反馈机制。

一旦系统中出现错误，请立即检测。

降低业务风险。在潜在问题变成实际问题之前进行评估。

什么是版本控制及其用途?

版本控制(或源代码控制)是一个存储库，源代码中的所有更改都始终存储在这个代码仓库中。

版本控件提供了代码开发的操作历史记录，追踪文件的变更内容、时间、人等信息忠实地了记录下来。

版本控制是持续集成和持续构建的源头。

什么是Git?

Git是一个分布式版本控制系统，可跟踪代码存储库中的更改。

利用GitHub流，Git围绕着一个基于分支的工作流，该工作流随着团队项目的不断发展而简化了团队协作。

二、实施DevOps的原因

DevOps为什么重要？

在当今的数字化世界中，组织必须重塑其产品部署系统，使其更强大，更灵活，以跟上竞争的步伐。

这就是DevOps概念出现的地方。

DevOps在为整个软件开发管道（从构思到部署，再到最终用户）产生移动性和敏捷性方面发挥着至关重要的作用。

DevOps是将不断更新和改进产品的更简化，更高效的流程整合在一起的解决方案。

DevOps对开发人员有何帮助？

在没有DevOps的世界中，开发人员的工作流程将首先建立新代码，交付并集成它们，然后，操作团队有责任打包和部署代码。之后，他们将不得不等待反馈。

而且如果出现问题，由于错误，他们将不得不重新执行一次，在项目中涉及的不同团队之间的无数手动沟通。

由于CI/CD实践已经合并并自动化了其余任务，因此应用DevOps可以将开发人员的任务简化为仅构建代码。

随着流程变得更加透明并且所有团队成员都可以访问,将工程团队和运营团队相结合有助于建立更好的沟通和协作。

为什么DevOps变得越来越流行?

DevOps在过去几年中受到关注，主要是因为它能够简化组织运营的开发，测试和部署流程，并将其转化为业务价值。

技术发展迅速。因此，组织必须采用一种新的工作流程-DevOps和Agile方法来简化和刺激其运营，而不能落后于其他公司。

DevOps的功能通过Facebook和Netflix的持续部署方法所取得的成功得到了清晰体现，该方法成功地促进了其增长，而没有中断正在进行的运营。

CI/CD有什么好处？

CI和CD的结合将所有代码更改统一到一个单一的存储库中，并通过自动化测试运行它们，从而在所有阶段全面开发产品，并随时准备部署。

CI/CD使组织能够按照客户期望的那样快速，高效和自动地推出产品更新。

简而言之，精心规划和执行良好的CI/CD管道可加快发布速度和可靠性，同时减轻产品的代码更改和缺陷。这最终将导致更高的客户满意度。

持续交付有什么好处?

通过手动发布代码更改，团队可以完全控制产品。在某些情况下，该产品的新版本将更有希望：具有明确业务目的的促销策略。

通过自动执行重复性和平凡的任务，IT专业人员可以拥有更多的思考能力来专注于改进产品，而不必担心集成进度。

持续部署有哪些好处?

通过持续部署，开发人员可以完全专注于产品，因为他们在管道中的最后任务是审查拉取请求并将其合并到分支。

通过在自动测试后立即发布新功能和修复，此方法可实现快速部署并缩短部署持续时间。

客户将是评估每个版本质量的人。新版本的错误修复更易于处理，因为现在每个版本都以小批量交付。

三、如何有效实施DevOps

DevOps工作流程

典型的DevOps工作流程可以简化为4个阶段:

版本控制：

这是存储和管理源代码的阶段。版本控件包含代码的不同版 本。

持续集成：

在这一步中，开发人员开始构建组件，并对其进行编译，验证，然后通过代码审查，单元测试和集成测试进行测试。

持续交付：

这是持续集成的下一个层次，其中发布和测试过程是完全自 动化的。CD确保将新版本快速，可持续地交付给最终用户。

持续部署：

应用程序成功通过所有测试要求后，将自动部署到生产服务 器上以进行发布，而无需任何人工干预。

DevOps的核心操作是什么？

DevOps在开发和基础架构方面的核心运营是Software development:

Infrastructure:

Provisioning

Configuration

Orchestration

Deployment

Code building

Code coverage

Unit testing

Packaging

Deployment

在实施DevOps之前，团队需要考虑哪些预防措施?

当组织尝试应用这种新方法时，对DevOps做法存在一些误解，有可能导致悲惨的失败:

DevOps不仅仅是简单地应用新工具或组建新的部门并期望它能正常工作。实际上，DevOps被认为是一种文化，开发团队和运营团队遵循共同的框架。

企业没有为其DevOps实践定义清晰的愿景。对开发团队和运营团队而言，应用DevOps计划是一项显着的变化。因此，拥有明确的路线图, 将DevOps集成到你的组织中的目标和期望将消除任何混乱，并从早期就提供清晰的指导方针。

在整个组织中应用DevOps做法之后，管理团队需要建立持续的学习和改进文化。系统中的故障和问题应被视为团队从错误中学习并防止这些错误再次发生的宝贵媒介。

SCM团队在DevOps中扮演什么角色？

软件配置管理(SCM)是跟踪和保留开发环境记录的实践，包括在操作系统中进行的所有更改和调整。

在DevOps中，将SCM作为代码构建在基础架构即代码实践的保护下。

SCM为开发人员简化了任务，因为他们不再需要手动管理配置过程。现在，此过程以机器可读的形式构建，并且会自动复制和标准化。

质量保证(QA)团队在DevOps中扮演什么角色？

随着DevOps实践在创新组织中变得越来越受欢迎，QA团队的职责和相关性在当今的自动化世界中已显示出下降的迹象。但是，这可以被认为是神话。

DevOps的增加并不等于QA角色的结束。这仅意味着他们的工作环境和所需的专业知识正在发生变化。因此，他们的主要重点是专业

发展以跟上这种不断变化的趋势。

在DevOps中，质量保证团队在确保连续交付实践的稳定性以及执行自动重复性测试无法完成的探索性测试任务方面发挥战略作用。他们在评估测试和检测最有价值的测试方面的见识仍然在缓解发布的最后步骤中的错误方面起着至关重要的作用。

DevOps使用哪些工具？描述你使用任何这些工具的经验

在典型的DevOps生命周期中，有不同的工具来支持产品开发的不同阶段。因此，用于DevOps的最常用工具可以分为6个关键阶段:

持续开发：Git, SVN, Mercurial, CVS, Jira

持续整合：Jenkins, Bamboo, Circled

持续交付：Nexus, Archiva, Tomcat

持续部署：Puppet, Chef, Docker

持续监控：Splunk, ELK Stack, Nagios

连续测试：Selenium, Kataion Studio

如何在DevOps实践中进行变更管理

典型的变更管理方法需要与DevOps的现代实践适当集成。

第一步是将变更集中到一个平台中，以简化变更，问题和事件管理流程。

接下来，企业应建立高透明度标准，以确保每个人都在同一页面上，并确保内部信息和沟通的准确性。对即将到来的变更进行分层并建立可靠的策略，将有助于最大程度地降低风险并缩短变更周期。

最后，组织应将自动化应用到其流程中，并与DevOps软件集成。

四、如何有效实施CI/CD

CI/CD的一些核心组件是什么？

稳定的CI/CD管道需要用作版本控制系统的存储库管理工具。这样开发人员就可以跟踪软件版本中的更改。

在版本控制系统中，开发人员还可以在项目上进行协作，在版本之间进行比较并消除他们犯的任何错误，从而减轻对所有团队成员的干扰。

连续测试和自动化测试是成功建立无缝CI / CD管道的两个最关键的关键。

自动化测试必须集成到所有产品开发阶段（包括单元测试，集成测试和系统测试），以涵盖所有功能，例如性能，可用性，性能，负载，压力和安全性。

CI/CD的一些常见做法是什么？

以下是建立有效的CI/CD管道的一些最佳实践:

发展DevOps文化

实施和利用持续集成

以相同的方式部署到每个环境

失败并重新启动管道

应用版本控制

将数据库包含在管道中

监控你的持续交付流程

使你的CD流水线流畅

什么时候是实施CI/CD的最佳时间？

向DevOps的过渡需要彻底重塑其软件开发文化，包括工作流，组织结构和基础架构。

因此，组织必须为实施DevOps的重大变化做好准备。

有哪些常见的CI/CD服务器

Visual Studio Visual Studio：支持具有敏捷计划，源代码控制，包管理，测试和发布自动化以及持续监视的完整开发的DevOps系统。

TeamCity TeamCity：是一款智能Cl服务器，可提供框架支持和代码覆盖，而无需安装任何额外的插件，也无需模块来构建脚本。

Jenkins ：它是一个独立的Cl服务器，通过共享管道和错误跟踪功能支持开发和运营团队之间的协作。它也可以与数百个仪表板插件结合使用。

GitLab GitLab：用户可以自定义平台，以进行有效的持续集成和部署。GitLab帮助CI/CD团队加快代码交付，错误识别和恢复程序的速度。

Bamboo Bamboo：是用于产品发布管理自动化的连续集成服务器。Bamboo跟踪所有工具上的所有部署，并实时传达错误。

描述持续集成的有效工作流程

实施持续集成的成功工作流程包括以下实践:

实施和维护项目源代码的存储库

自动化构建和集成

使构建自检

每天将更改提交到基准

构建所有添加到基准的提交

保持快速构建

在生产环境的克隆中运行测试

轻松获取最新交付物

使构建结果易于所有人监视

自动化部署

五、每种术语之间的差异

1.敏捷和DevOps之间有哪些主要区别？

基本上，DevOps和敏捷是相互补充的。

敏捷更加关注开发新软件和以更有效的方式管理复杂过程的价值和原则。同时，DevOps只在增强由开发人员和运营团队组成的不同团队之间的沟通，集成和协作。

它需要采用敏捷方法和DevOps方法来形成无缝工作的产品开发生命周期：敏捷原理有助于塑造和引导正确的开发方向，而DevOps利用这些工具来确保将产品完全交付给客户。

2.持续集成，持续交付和持续部署之间有什么区别？

持续集成（CI）是一种将代码版本连续集成到共享存储库中的实践。这种做法可确保自动测试新代码，并能快速检测和修复错误。

持续交付使 CI 进一步迈出了一步，确保集成后，随时可以在一个按钮内就可以释放代码库。因此，CI可以视为持续交付的先决条件，这是CI/CD管道的另一个重要组成部分。

对于连续部署，不需要任何手动步骤。这些代码通过测试后，便会自动推送到生产环境。

所有这三个组件：持续集成，持续交付和持续部署是实施DevOps的重要阶段。

一方面，连续交付更适合于活跃用户已经存在的应用程序，这样事情就可以变慢一些并进行更好的调整。

另一方面，如果你打算发布一个全新的软件并且将整个过程指定为完全自动化的，则连续部署是你产品的更合适选择。

连续交付和连续部署之间有哪些根本区别?

指定为完全自动化的，则连续部署是你产品的更合适选择。

在连续交付的情况下，主分支中的代码始终可以手动部署。通过这种做法，开 发团队可以决定何时发布新的更改或功能，以最大程度地使组织受益。

同时，连续部署将在测试阶段之后立即将代码中的所有更新和修补程序自动部署到生产环境中，而无需任何人工干预。

持续集成和持续交付之间的区别是什么？

生产环境中，而无需任何人工干预。

持续集成有助于确保软件组件紧密协作。整合应该经常进行；最好每小时或每 天一次。持续集成有助于提高代码提交的频率，并降低连接多个开发人员的代码的复杂性。最终，此过程减少了不兼容代码和冗余工作的机会。

持续交付是CI/CD流程中的下一步。由于代码不断集成到共享存储库中，因此可 以持续测试该代码。在等待代码完成之前，没有间隙可以进行测试。这样可确保找到尽可能多的错误，然后将其连续交付给生产。

DevOps和持续交付之间有什么区别？

DevOps更像是一种组织和文化方法，可促进工程团队和运营团队之间的协作 和沟通。 同时，持续交付是成功将DevOps实施到产品开发工作流程中的重要因素。持续交付实践有助于使新发行的版本更加乏味和可靠，并建立更加无缝和短的流程。

DevOps的主要目的是有效地结合Dev和Ops角色，消除所有孤岛，并实现独立于持续交付实践的业务目标。

另一方面，如果已经有DevOps流程，则连续交付效果最佳。因此，它扩大了协作并简化了组织的统一产品开发周期。

敏捷，精益IT和DevOps之间有什么区别？

敏捷是仅专注于软件开发的方法。敏捷旨在迭代开发，建立持续交付，缩短反馈循环以及在整个软件开发生命周期(SDLC)中改善团队协作。

精益IT是一种旨在简化产品开发周期价值流的方法。精益专注于消除不必要的过 程，这些过程不会增加价值，并创建流程来优化价值流。

DevOps专注于开发和部署-产品开发过程的Dev和0pso其目标是有效整合自动化工具和IT专业人员之间的角色，以实现更简化和自动化的流程。
CI）是一种将代码版本连续集成到共享存储库中的实践。这种做法可确保自动测试新代码，并能快速检测和修复错误。

持续交付使 CI 进一步迈出了一步，确保集成后，随时可以在一个按钮内就可以释放代码库。因此，CI可以视为持续交付的先决条件，这是CI/CD管道的另一个重要组成部分。

对于连续部署，不需要任何手动步骤。这些代码通过测试后，便会自动推送到生产环境。

所有这三个组件：持续集成，持续交付和持续部署是实施DevOps的重要阶段。

一方面，连续交付更适合于活跃用户已经存在的应用程序，这样事情就可以变慢一些并进行更好的调整。

另一方面，如果你打算发布一个全新的软件并且将整个过程指定为完全自动化的，则连续部署是你产品的更合适选择。

连续交付和连续部署之间有哪些根本区别?

指定为完全自动化的，则连续部署是你产品的更合适选择。

在连续交付的情况下，主分支中的代码始终可以手动部署。通过这种做法，开 发团队可以决定何时发布新的更改或功能，以最大程度地使组织受益。

同时，连续部署将在测试阶段之后立即将代码中的所有更新和修补程序自动部署到生产环境中，而无需任何人工干预。

持续集成和持续交付之间的区别是什么？

生产环境中，而无需任何人工干预。

持续集成有助于确保软件组件紧密协作。整合应该经常进行；最好每小时或每 天一次。持续集成有助于提高代码提交的频率，并降低连接多个开发人员的代码的复杂性。最终，此过程减少了不兼容代码和冗余工作的机会。

持续交付是CI/CD流程中的下一步。由于代码不断集成到共享存储库中，因此可 以持续测试该代码。在等待代码完成之前，没有间隙可以进行测试。这样可确保找到尽可能多的错误，然后将其连续交付给生产。

DevOps和持续交付之间有什么区别？

DevOps更像是一种组织和文化方法，可促进工程团队和运营团队之间的协作 和沟通。 同时，持续交付是成功将DevOps实施到产品开发工作流程中的重要因素。持续交付实践有助于使新发行的版本更加乏味和可靠，并建立更加无缝和短的流程。

DevOps的主要目的是有效地结合Dev和Ops角色，消除所有孤岛，并实现独立于持续交付实践的业务目标。

另一方面，如果已经有DevOps流程，则连续交付效果最佳。因此，它扩大了协作并简化了组织的统一产品开发周期。

敏捷，精益IT和DevOps之间有什么区别？

敏捷是仅专注于软件开发的方法。敏捷旨在迭代开发，建立持续交付，缩短反馈循环以及在整个软件开发生命周期(SDLC)中改善团队协作。

精益IT是一种旨在简化产品开发周期价值流的方法。精益专注于消除不必要的过 程，这些过程不会增加价值，并创建流程来优化价值流。

DevOps专注于开发和部署-产品开发过程的Dev和0pso其目标是有效整合自动化工具和IT专业人员之间的角色，以实现更简化和自动化的流程。