泰安新闻联播,seo排名优化收费,做网站的技术,品牌网站建设方案pptDevOps持续交付
随着DevOps⼤规模化的落地和应⽤#xff0c;持续集成以及持续交付已经是⼀种常态的。CI指的是持续集成#xff0c;使⽤的开源⼯具是Jenkins#xff0c;CD指的是持续交付和持续部署#xff0c;⼀个完整的软件开发⽣命周期为: 主要流程可以具体为:
构建阶段…DevOps持续交付
随着DevOps⼤规模化的落地和应⽤持续集成以及持续交付已经是⼀种常态的。CI指的是持续集成使⽤的开源⼯具是JenkinsCD指的是持续交付和持续部署⼀个完整的软件开发⽣命周期为: 主要流程可以具体为:
构建阶段-单元测试阶段-部署阶段-⾃动化测试阶段-部署到⽣产环境阶段-度量和验证阶段。
DevOps体系
持续集成
持续集成(Continuous Integration)的⽬的就是让产品可以快速交付同时还能保 持⾼质量的业务交付。它的核⼼代码集成到主⼲分⽀后必须通过 ⾃动化测试只要有⼀个测试⽤例失败那么就不能集成。这样互联⽹的产品研发就形成了⼀套标准化的流程。 如上是互联⽹产品交付的基本形态。持续集成指的是频繁地(⼀天多次)将代码集成到主⼲分⽀。它的好处具体有两点:
1、快速发现错误每完成⼀点更新就集成到主⼲分⽀可以快速发现错误 定位错误也是很容易
2、防⽌分⽀⼤幅度偏离主⼲。如果不是经常集成主⼲⼜在不断更新会导致以后集成的难度变⼤也有可能导致难以集成。
持续交付
持续交付(Continuous delivery)指的是频繁地将软件的新版本交付给测 试团队或者是客户以供评审。如果评审通过代码就进⼊到⽣产阶段 。持续交付可以把它理解为持续集成的下⼀步它强调的是不管怎么更新软件 是随时随地都可以进⾏交付
持续部署
持续部署(Continuous deployment)是持续交付的下⼀步指的是代码通过 评审以后⾃动部署到⽣产环境。持续部署的⽬标是代码在任何时刻都是 可以部署的可以进⼊到⽣产阶段。持续部署的前提是⾃动化测试完成构建 部署等步骤。持续部署与持续交付的区别如下所示: Jenkins
Jenkins环境搭建
在https://get.jenkins.io/war-stable/2.277.4/的地址下载最新稳定版的Jenkins下载成功后把它放在tomcat下的webapps下的⽬录下然后启动tomcat启动成功后在链接地址http://localhost:8080/jenkins/login?from%2Fjenkins%2F就会显示出登录的信息密码显示在/Users//.jenkins/secrets/initialAdminPassword的⽬录下在该⽬录下获取密码然后输⼊到输⼊框⾥⾯点击继续。如下图所示: 我们选择推荐安装的插件就会⾃动安装插件,如下所示: 备注:如果是离线的情况需要解决的思路使⽤ skip-certificate-check.hpi 插件来解决Jenkins离线的问题。
参数话构建
⾸先需要安装插件Persistent Parameter,Git Parameter,Build With Parameters,Active Choices(动态选择参数,可以根据不同需求选择不同执⾏的的动态参数)。
Git
认识Git
Git是Linus Torvalds为了帮助管理Linux内核开发⽽开发的⼀个开放源码的版本控制软件它采⽤了分布式版本库的⽅式 不必服务器端软件⽀持。可以说它是⼀个开源的分布式版本控制系统⽤于敏捷⾼效地处理任何⼩或者⼤的项⽬。 集中式分布式 集中式 从中央代码服务器获取具体的代码把代码下载到⾃⼰的本地然后把代码必须在有⽹络的情况下提交到中央服务器。典型的产品是SVN所谓集中式的版本控制系统只有⼀个中央数据仓库如果中央数据仓库瘫痪或者是不可访问的情况下所有的使⽤者⽆法使⽤SVN⽆法进⾏提交或者备份⽂件。 分布式 分布式版本控制系统在每个使⽤者电脑上就有⼀个完整的数据仓库没有⽹络依然可以使⽤Git。当然为了团队协作会把本地数据同步到GitLab服务器或者是GitHub等代码仓库。 Git安装 需要到https://git-scm.com/downloads进⾏下载根据具体的操作系统来下载具体的安装包。 Git配置 system 针对任意登录到Linux系统的⽤户⽣效 global 全局只针对当前登录的⽤户⽣效git配置写⼊~/.config/config local 本地只针对某⼀个⽂件夹⽣效。 ⼀般配置的时候使⽤的是全局配置建议使⽤全局配置的⽅式。具体配置name和email如下 在mac的系统中配置信息就会写在该⽬录下cat ~/.gitconfig 查看显示全局的配置信息使⽤到的命令为 Git核⼼原理 操作的⼀般都是⼯作⽬录如果执⾏了git add的命令后那么就会从⼯作区进⼊到暂存区如果再执⾏了git commit的命令后等于是从暂存区进⼊到本地仓库如果再执⾏git push就是从本地仓库进⼊到原地仓库。本地仓库主要记录的是所有⽂件的修改删除这些Git都会记录下来⽬的是可以进⾏历史回退追踪信息。
Git使⽤
本地已有代码需要使⽤git来进⾏管理本地没有代码需要创建⼀个新的git版本仓库本地没有代码也没有仓库去GitLab平台下载⼀个git版本代码仓库.使⽤到的命令为git clone
创建仓库的命令为:git init
Git命令
git本地仓库就是⼀个git的版本库也就是说在代码⽬录下的⼀个.git的⽂件夹这就是管理⽂件信息的⽬录也是git核⼼的本地仓库。github是共有代码托管平台⽽Gitlab是私有代码托管平台。A、本地有代码进⾏管理 直接到这个⽬录执⾏git init就可以创建本地仓库了那么后⾯的所有代码修改都会记录相关的信息。B、需要新创建本地仓库 git init来创建新的仓库信息。具体创建的过程如下 C、托管平台下载 git clone来创建代码仓库在公司⾥⾯很多时候使⽤的是这种⽅式。
Git⽣命周期
它的⽣命周期可以完整的描述为: git init #⽣成git⼯作区 git status #掌握git⼯作区的信息 git add #确认需要添加以及跟踪的⽂件 git commit -m 注释信息#提交到本地仓库 Git⽂件命名
在git中对⽂件进⾏重命名因为修改都会进⾏监测到那么操作的步骤为如果使⽤常规的命令mv那么就⼜需要进⾏add和commit的过程这个过程可以说是有了删除的操作也进⾏创建的过程我们可以使⽤git mv的命令来轻松的解决命令为 修改⽂件名称后也是需要进⾏提交到本地仓库的也就是使⽤git commit -m的命令
Git的log
查看Git的⽇志信息主要使⽤到的命令具体汇总如下 git log --oneline #查看简陋的信息 git log git log -1 #显示最新的⼀条提交记录信息 git log --all --graph #查看提交的版本演变 git reflog #记录git所有的操作包含了提交以及回退
Git回退
git的版本管理是通过指针来进⾏管理的这个指针就是HEAD那么也就是说HEAD表示当前版本HEAD^表示的是上⼀个版本HEAD^^表的是上上个版本。 git reset --hard 版本ID git reset --hard HEAD管理
备注结合git reflog可以回到过去也是可以到未来的版本信息也就是回退了也是可以还原回去的
Git Stash
git stash可以称为临时空间。它的使⽤场景主要可以总结为git stash就是把暂存区未提交的内容临时存放到⼀个区域⽅便⽇后取回来再次使⽤。场景可以描述为修改⼀个⽂件后进⾏了git add fileName⽂件但是不进⾏具体的commit这个时候可能需要⼲其他的事⽐如需要修复线上的紧急bug那么就需要把这个临时的存放到⼀个区域。具体命令如下
localhost:learnGit liwangping$ git add index.py
localhost:learnGit liwangping$ git status
位于分⽀ master
要提交的变更
使⽤ git restore --staged ⽂件... 以取消暂存
修改 index.py
localhost:learnGit liwangping$ git stash save 保存新增的⽂件信息
保存⼯作⽬录和索引状态 On master: 保存新增的⽂件信息
localhost:learnGit liwangping$ git status
位于分⽀ master
⽆⽂件要提交⼲净的⼯作区
⼲完其他事后可以再把stash区域的⽂件恢复回来使⽤到的命令具体为git stash list #查看stash区域的⽂件信息 git stash pop #恢复最新的stash进度到⼯作区 git stash pop stash_id#恢复指定的stash的进度 git stash clear #清空所有存储的stash进度
Git分⽀管理
master是主⼲分⽀⼀般我们的分⽀可以分为test dev stage的分⽀。分⽀涉及的命令具体如下 git branch #查看当前的分⽀ git branch test #创建⼀个测试分⽀ git checkout test #切换分⽀ git checkout -b 分⽀名称#创建新的分⽀并且⽴即切换到新的分⽀信息 git branch -D 分⽀名称 git merge 分⽀名称#分⽀的合并信息,如下就是显示的是把test的分⽀代码合并到master的分⽀ Git冲突解决
git merge分⽀合并的时候就需要解决各个冲突的问题那么下⾯就具体的说明怎么样来解决冲突的问题。
git merge dev
⾃动合并 index.py
冲突内容合并冲突于 index.py
⾃动合并失败修正冲突然后提交修正的结果。
localhost:learnGit liwangping$
如下是显示出图的⽂件内容信息具体如下HEAD
def func():print(this is a test branch)针对合并出现如上的问题解决的思路是
出现冲突
查看冲突⽂件的内容
怎么修改⽂件就需要⼈为处于进去
修改完成后再针对⽂件进⾏add和commit的操作
Git标签
git tag可以理解为这对每个版本加上⼀个标签。标签涉及到的命令具体可以总结为:
git tag -a tagName -m 标签注释:创建⼀个标签并且加上注释
git tag #查看标签信息
git log --decorate #查看标签的详细信息
git log --oneline --decorate #命令如上是⼀样的
git tag -a标签名称 commitID -m 标签注释
git show tagName #查看标签的具体详细的信息
Gitlab
Gitlab环境搭建
代码版本的管理是持续集成⾥⾯很重要的⼀个环节在现代企业⾥⾯对代码的管理都是通过Gitlab来进⾏管理
的。Gitlab是基于Ruby的代码来进⾏开发的。下⾯具体演示下Gitlab的安装。在Linux中安装Gitlab的依赖项具体
为:
针对防⽕墙的处理具体如下:
下来进⾏下载安装:def func():print(this is a dev branch)dev
针对合并出现如上的问题解决的思路是 出现冲突 查看冲突⽂件的内容 怎么修改⽂件就需要⼈为处于进去 修改完成后再针对⽂件进⾏add和commit的操作
Git标签
git tag可以理解为这对每个版本加上⼀个标签。标签涉及到的命令具体可以总结为: git tag -a tagName -m 标签注释:创建⼀个标签并且加上注释 git tag #查看标签信息 git log --decorate #查看标签的详细信息 git log --oneline --decorate #命令如上是⼀样的 git tag -a标签名称 commitID -m 标签注释 git show tagName #查看标签的具体详细的信息
Gitlab
Gitlab环境搭建
代码版本的管理是持续集成⾥⾯很重要的⼀个环节在现代企业⾥⾯对代码的管理都是通过Gitlab来进⾏管理的。Gitlab是基于Ruby的代码来进⾏开发的。下⾯具体演示下Gitlab的安装。在Linux中安装Gitlab的依赖项具体为: yum install curl policycoreutils openssh-server openssh-clients systemctl enable sshd systemctl start sshd yum install postfix systemctl enable postfix systemctl start postfix yum install -y policycoreutils-python 针对防⽕墙的处理具体如下: firewall-cmd --permanent --add-servicehttp systemctl reload firewalld 下来进⾏下载安装: wget --content-disposition https://packages.gitlab.com/gitlab/gitlab- ce/packages/el/7/gitlab-ce-12.0.2-ce.0.el 7.x86_64.rpm/download.rpm rpm -i gitlab-ce-12.0.2-ce.0.el7.x86_64.rpm 启动gitlab: gitlab-ctl reconfigure #就会启动gitlab⾸次启动时间⽐较⻓ 启动后在浏览器访问默认端⼝是80⾸次显示的⻚⾯: 在后⾯的启动中就没有⾸次启动那么⻓的时间了启动的命令为: gitlab-ctl start ssh-key配置
下来是配置ssh以及本地提交代码到Gitlab具体配置如下: 下来配置user和email具体如下: 然后会在当前的⽬录下⽣成.ssh的⽬录进⼊后可以看到对应的⽂件。把id_rsa.pub的内容复制然后加到Gitlab的密钥中具体如下: 点击AddKey进⾏添加然后就会出现如下的界⾯信息: 下来在Gitlab上创建项⽬然后把本地的代码提交上去。
localhost:saas $ git log
commit 42ed46bce3d68c03b9c52f47742e17c6a9a9a11a (HEAD - master)
Author: wuya 759178811qq.com
Date: Wed Jun 16 15:41:35 2021 0800
this is a test code
commit 87c9cc43f0f5dfd80baeb9db8669622f81475db8 (origin/master, origin/HEAD)
Author: wuya 759178811qq.com
Date: Wed Jun 16 15:36:03 2021 0800
Initial commit
localhost:saas $ git push
Username for http://47.95.142.233: 759178811qq.com
Password for http://759178811qq.com47.95.142.233:然后就会在Gitlab的系统⾥⾯看到提交的代码具体如下:
Gitlab之CICD
基于Gitlba-ci的需要安装gitlab-ci的插件安装的命令为:
执⾏如上命令后显示如下的信息
枚举对象: 4, 完成.
对象计数中: 100% (4/4), 完成.
使⽤ 8 个线程进⾏压缩
压缩对象中: 100% (3/3), 完成.
写⼊对象中: 100% (3/3), 327 字节 | 327.00 KiB/s, 完成. 总共 3 (差异 0)复⽤ 0 (差异 0)
To http://47.95.142.233/wuya/saas.git 87c9cc4..42ed46b master - master
然后就会在Gitlab的系统⾥⾯看到提交的代码具体如下: Gitlab之CICD
基于Gitlba-ci的需要安装gitlab-ci的插件安装的命令为: curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi- runner/script.rpm.sh | bash 安装成功后下来进⾏插件的安装安装的命令为:
yum install gitlab-ci-multi-runner -y
#执⾏后输出的信息为
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
runner_gitlab-ci-multi-runner/x86_64/signature
| 862 B 00:00:00
runner_gitlab-ci-multi-runner/x86_64/signature
| 1.0 kB 00:00:00 !!!
runner_gitlab-ci-multi-runner-source/signature
| 862 B 00:00:00
runner_gitlab-ci-multi-runner-source/signature
| 951 B 00:00:00 !!!
Package gitlab-ci-multi-runner-9.5.1-1.x86_64 already installed and latest version 下来查看gitlab-ci-multi-runner是否可以正常的启动以及它的状态具体如下: 下来进⾏gitlab-ci的注册注册需要获取到具体的URL和TOKEN的信息步骤为:
打开项⽬在项⽬⾥⾯选择settings⾥⾯的CICD 然后选择Runners,如下所示: 下来进⾏CICD的注册的信息具体命令为:
[rootiz2ze4dcz1c36xtn6io522z ~]# gitlab-ci-multi-runner register
Running in system-mode.
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
http://47.95.142.233/
Please enter the gitlab-ci token for this runner:9pzo1oicss-T6f7nVz_Q
Please enter the gitlab-ci description for this runner:[iz2ze4dcz1c36xtn6io522z]:
Please enter the gitlab-ci tags for this runner (comma separated):test
Whether to run untagged builds [true/false]:
[false]:
Whether to lock Runner to current project [true/false]:
[false]:
Registering runner... succeeded runner9pzo1oic
Please enter the executor: docker, parallels, shell, ssh, dockermachine, docker-ssh,
virtualbox, docker-sshmachine, kubernetes:
shell
Runner registered successfully. Feel free to start it, but if its running already the
config should be automatically reloaded! 注册成功后就可以在Gitlab⾥⾯进⾏基于shell的⽅式来进⾏CICD的交互了。下⾯来看是否注册成功具体如下: 在Gitlab的CICD中也就能看到刚才注册成功的CI的信息了如下所示:
下来在具体的项⽬⾥⾯增加⼀个.gitlab-ci.yml的⽂件来进⾏具体如下: 下来在具体的项⽬⾥⾯增加⼀个.gitlab-ci.yml的⽂件来进⾏具体如下: 实际案例知行命令行如下 保存提交后再次到项⽬的CICD⾥⾯就可以看到我们新增的CICD具体如下: 我们再次查看执⾏的结果信息如下所示: 基于GitLab的框架执⾏
下来我们在Gitlab⾥⾯执⾏测试框架的代码整体代码的结构图具体如下: 我们需要在执⾏的服务器安装需要的第三⽅的库安装好后在.gitlab-ci.yml⽂件⾥⾯编写如下内容: 下来我们就可以看到它会在gitlab⾥⾯被执⾏具体执⾏结果的信息如下所示: Running with gitlab-ci-multi-runner 9.5.1 (96b34cc) on iz2ze4dcz1c36xtn6io522z (Td6rjStK) Using Shell executor... Running on iz2ze4dcz1c36xtn6io522z... Fetching changes... Removing tests/.pytest_cache/ Removing tests/__pycache__/test_login_token_book.cpython-37-pytest-5.4.3.pyc Skipping Git submodules setup $ cd tests/ $ python3 -m pytest -v test_login_token_book.py Jenkins整合Gitlab JenkinsGitlab通信 在Jenkins的系统管理中找到Gitlab然后配置Connection name以及填写Gitlab服务的地址信息具体如下 下来需要配置认证授权的信息也就是说从Jenkins获取Gitlab的代码在Gitlab的Settings中找到Access Tokens具体如下 test session starts platform linux -- Python 3.7.1, pytest-5.4.3, py-1.10.0, pluggy-0.13.1 -- /usr/bin/python3 collecting ... collected 6 items test_login_token_book.py::test_login_book[datas0] PASSED [ 16%] test_login_token_book.py::test_login_book[datas1] PASSED [ 33%] test_login_token_book.py::test_login_book[datas2] PASSED [ 50%] test_login_token_book.py::test_login_book[datas3] PASSED [ 66%] test_login_token_book.py::test_login_book[datas4] PASSED [ 83%] test_login_token_book.py::test_login_book[datas5] PASSED [100%] 6 passed in 1.12s Job succeeded Jenkins整合Gitlab
JenkinsGitlab通信
在Jenkins的系统管理中找到Gitlab然后配置Connection name以及填写Gitlab服务的地址信息具体如下 下来需要配置认证授权的信息也就是说从Jenkins获取Gitlab的代码在Gitlab的Settings中找到AccessTokens具体如下 然后选择不同的权限来⽣成⼀个token的授权信息拿到该信息后在Jenkins的系统管理的GitLab的填写token的信息然后点击添加具体如下 添加后的信息如下所示
下来点击右边的Test Connection来进⾏测试具体测试结果如下所示 ⾃动触发构建
我们期望的⽬的是⾃动push后进⾏智能化的构建⽽不需要设置什么定时任务或者是⼿动触发构建下⾯具体详细的来说这部分的应⽤。
Jenkins插件安装
在CI中安装插件Gitlab hooks具体的插件名称为:GitLab,Gitlab Hook Plugin,GitGit client。
Jenkins配置
在项⽬的代码管理中把分⽀部分取消也就是任意分⽀提交都是能够进⾏⾃动触发的如下所示: 在Jenkins中选择要触发的项⽬如saas的项⽬然后点击配置在构建触发器中选择Build when a change is pushed to GitLab如下所示: 然后点击⾼级到Secret token中点击Generate就会⾃动⽣成Secret token的信息如下所示: 备注需要记住的是GitLab Web Hook的URL地址信息和Secure token的信息切记。
WebHook配置
在Gitlab的saas⼯程中点击Settings中的Itergrations如下所示: 然后填写Web Hook的URL地址和Secure token的信息如下所示: 主要填写正确的Web Hook地址和Secure token信息后其他的都是默认的最后点击
Add webhook添加按钮,添加成功就会显示这些信息: 点击Push events后就会⾃动触发远程的Jenkins项⽬执⾏
⾃动触发实战
下⾯我们到saas下编辑代码后进⾏push就会⾃动触发执⾏如下所示: 持续流⽔线
配置⽅式
在⼀个产品经过技术内部评审和⽅案评审后以及到后⾯的⽅案评审和转测阶段交付给测试后测试这边会进⾏多个不同阶段的验证这个阶段具体为: unitTest--smoke测试--外部API测试阶段--API⾃动化测试--UI⾃动化测试设计到的⼯程具体可以展示为: 安装插件Parameterized Trigger pluginDelivery Pipeline Plugin,Build Pipeline Plugin后依次来设置它的顺序设置步骤为增加构建后操作步骤⾥⾯选择“构建 其他⼯程”选择下⼀个需要执⾏的⼯程具体如下: 下来增加新的试图信息也就是测试流⽔线具体为: 然后出发执⾏初始化的项⽬也就是UnitTest执⾏后它的结果信息为: 开始管道式流⽔式的执⾏当然试图模式也可以使⽤另外⼀种⻛格具体如下: 脚本⽅式
上⾯的⽅式都是通过配置的⽅式我们创建流⽔线式的⼯程然后编写Pipeline的脚本具体如下:
pipeline{agent anystages{stage(unitTest){steps{script{cd /Applications/devOps/CICD/saaspython3 -m pytest -v test_login.py}}}stage(smokeApi){steps{script{cd /Applications/devOps/CICD/saaspython3 -m pytest -v test_login.py }}}stage(thridApi){steps{script{cd /Applications/devOps/CICD/saaspython3 -m pytest -v test_login.py }}}stage(apiTest){steps{script{cd /Applications/devOps/CICD/saaspython3 -m pytest -v test_login.py }}}stage(uiTest){steps{script{cd /Applications/devOps/CICD/saaspython3 -m pytest -v test_login.py }}}}
}
然后执⾏⻅执⾏的过程信息: 报告通知整合
在测试代码执⾏后我们需要得到测试执⾏的结果信息以及执⾏过程中如果出现其他的问题希望能够得到回应。测试报告我们可以把Pytest与Allure整合起来⽽通知可以和钉钉整合起来。下⾯具体说明这部分的配置以及案例应⽤实战。
Allure报告
配置应⽤
⾸先需要在Jenkins中安装Allure Jenkins Plugin的插件安装插件成功后。在“全局⼯具配置”的Allure中选择⾃动 安装Allure具体如下所示: 下来在“系统配置”的Allure Report中配置它的全局变量信息具体如下: 案例实战
下来在CI的⼯程中在构建中需要带上配置的Allure的信息具体执⾏的命令为: cd tests python3 -m pytest -v -s test_login_token_book.py --alluredir ${WORKSPACE}/report 在构建后操作⾥⾯选择Allure Report在Path⾥⾯填写report的关键字切记项⽬的⼯程⽬录⼀定得要有report的⽂件夹信息配置信息具体如下所示: 点击构建后就会在⼯程的详细⾥⾯显示Allure Report的报告信息具体如下所示: 点击Allure Report就会显示具体的测试报告信息。
企业级的CICD 基于Docker的CICD
⾃动化部署验证
下⾯我们可以把⾃动构建镜像以及⾃动启动服务和⾃动化验证测试服务的过程完全结合Jenkins持续集成的流⽔线完全实现⾃动化的部署和过程。
pipeline
在Jenkins持续集成的⼯具⾥⾯创建Pipeline的项⽬设计到的脚本具体如下
pipeline{agent anystages{stage(Code Pull) {steps {git http://47.95.142.233/wuya/app.git}}stage(Code Check) {steps {withSonarQubeEnv(SonarScanner) {sh mvn packagemvn clean install -Dmaven.test.skiptrue
org.sonarsource.scanner.maven:sonar-maven-plugin:3.6.1.1688:sonar}}}stage(container init){steps{sh cd src/main/dockerdocker-compose down sleep 6sdocker rmi app:0.0.1-SNAPSHOTsleep 10s}}stage(build the image){steps{sh mvn clean package -Dmaven.test.skiptrue docker:build}}stage(run the container){steps{sh cd src/main/dockerdocker-compose up -d }}stage(smoke test){steps{sh cd src/main/dockersleep 10spython3 -m pytest -v test_springboot.py}}}
}
下来我们开始构建镜像其实我们构建的过程第⼀步主要就是打包镜像第⼆步就是⾃动化测试的启动镜像第三个步骤就是验证部署的服务这部分这部分也是可以理解为⼀个冒烟测试的过程。具体构建后输出的结果信息如下
