持续集成基本概念
Posted yizhangheka
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了持续集成基本概念相关的知识,希望对你有一定的参考价值。
目录
我叫张贺,贪财好色。一名合格的LINUX运维工程师,专注于LINUX的学习和研究,曾负责某中型企业的网站运维工作,爱好佛学和跑步。
个人博客:传送阵
笔者微信:zhanghe15069028807
,非诚勿扰。
集成基本概念
1、什么是集成?
一个软件的开发项目通常由多个程序员全力完成,每个程序员开发若干个模块,最终组合成一个完成的项目,这样的过程就集成。
2、什么是持续集成?
程序员一般不会把整个模块完成写完之后再提交到仓库,一般是半天或是一天提交一次,这样频繁提交的过程就是持续集成。
3、为什么要持续集成?
- 程序员每完成一点更新,就提到到仓库,仓库再提交给调度平台(如jenkins),调度平台拥有自动编译、自动测试、自动反馈的功能,反馈当然是反馈给开发人员,这样形成一个循环,可以快速的发现错误,定位错误也比较容易。
- 软件平台可以对代码自动进行编译和测试,所以在一定程度上节省了人力成本。
4、什么情况下使用持续集成?
项目开发的规模比较小,就范不上用持续集成了。但是如果项目很大,需要不断添加新的功能,或不断升级产品,则需要进行反复集成,这个时候就需要用到持续集成来简化我们的工作。
5、什么是持续交付?
持续交付建立在持续集成的基础上,目的是为了将代码部署到预生产环境当中。持续交付就是将调度平台已经编译、测试、反馈好代码,手动部署到预生产环境当中,这里的预生产环境通常指的是测试环境。
手动部署的含义并不是在命令行当中cp、mv啥的,而是在调度平台上手动点击一下部署按钮。
6、什么是持续部署?
持续部署是持续交付的下一步,指代码在任何时刻都是可部署的,最后部署到生产环境的自动化。
持续部署和持续交付的区别在于,持续交付是测试环境,持续部署是环境,一个是手动的,另一个是自动的。
持续部署是全自动的,其实这种环境并不是特别好,出了错不好排查,其实不如半自动好一些,所谓的半自动就是指的持续交付。
7、持续集成实施流程
根据持续集成的设计、代码从提交到生产,整个过程有以下几个步骤:
- 提交代码
- 代码托管(仓库)
- 调度平台(jenkins)获取仓库的代码
- 调度平台进行编译、测试、部署(手工或自动)
- 回退
版本控制系统
1、什么是版本控制系统
version control system,将每一次文件的变化,集中在一个系统中加以版本的控制,以便后续查阅特定文件版本的历史记录。
2、版本控制解决了什么问题?
- 追溯文件历史变更
- 多人团队协同开发
- 代码集中统一管理
3、常用的版本控制系统
常见的版本控制系统分为两种:svn为集中版本控制系统的代表,git为分布式版本控制系统的代表。
集中式:所有人操作一个版本控制系统,版本控制系统可能有单点故障,一旦发生故障程序员都无法提交合并代码。
分布式:版本控制系统提供本地仓库的功能,程序员可以把版本控制系统上的仓库下载到本地一份,平时在自己的本地提交即可,后续可自行将本地的仓库提交到版本控制系统当中,这样程序员和版本控制系统并不是实时通讯的,不会特别依赖网络,即使版本控制系统挂上半天,也不会影响开发。
总结:集中式依赖网络、分布式不依赖网络(现在趋势)。
git也是linus写的,github、码云都是根据git做的,受到程序员的追捧。
4、git的基本使用
[root@git ~]#yum –y install git
//在使用git之前,先要明确自己的身份
[root@git ~]# git config --global user.name "zhanghe"
[root@git ~]# git config --global user.email "zhanghe@formail.com"
[root@git ~]# git config --global color.ui true #这里加颜色的,可不加,加上好看一些。
//明确自己的身份后,会在当前目录下生成一个隐藏文件
[root@git ~]# cat .gitconfig
[user]
name = zhanghe
email = zhanghe@formail.com
[color]
ui = true
[root@git ~]# ll -h .gitconfig
-rw-r--r-- 1 root root 71 Jan 11 15:06 .gitconfig
//建立一个git版本库,这个目录里面所有文件都可以被git管理起来,每个文件的修改、删除,git都能跟踪,以便任何时刻都可以追踪历史,或者在某个时刻可以还原。
[root@git ~]# mkdir demo
[root@git ~]# cd demo
//初始化仓库
[root@git demo]# git init
Initialized empty Git repository in /root/demo/.git
//生成了一个隐藏目录,不要动这个目录
[root@git demo]# ls .git
branches config description HEAD hooks info objects refs
如何提交目录文件到本地仓库?
[root@git demo]# touch file1 file2 file3
[root@git demo]# ls
file1 file2 file3
//查看仓库的状态,告诉你有三个文件没有提交,可以通过git add进行提交
[root@git demo]# git status
# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed) #警告没有提交在暂存区
#
# file1
# file2
# file3
nothing added to commit but untracked files present (use "git add" to track)
//通过git add提交,然后再看看仓库的状态,告诉你发现了三个新提交的文件,可以通过git rm删除
[root@git demo]# git add file1 file2 file3 #无论有多少,git .都可以进行
[root@git demo]# git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: file1
# new file: file2
# new file: file3
//通过git add只是提交到仓库的暂存区,并没有真正的提交到仓库,通过commit可以提交到真正的仓库
[root@git demo]# git commit -m "新增file1,file2,file3到仓库"
[master (root-commit) c2001e4] 新增file1,file2,file3到仓库
3 files changed, 0 insertions(+), 0 deletions(-) #0个insert,0个deletion
create mode 100644 file1
create mode 100644 file2
create mode 100644 file3
[root@git demo]# git status #再看仓库的状态,发现所有的任务都没有了,都完成了
# On branch master
nothing to commit, working directory clean
修改文件:
[root@git demo]# echo aaa > file1
[root@git demo]# git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: file1 #告诉你一个文件被修改
[root@git demo]# git add . #提交到暂存区
[root@git demo]# git commit -m "修改了file1" #提交到仓库
[master bdcc886] 修改了file1
1 file changed, 1 insertion(+) #提示一个文件被改变,提示一个文件被改变
两次版本的文件都是有的,后面会演示如何查看两个版本的内容。
重命名文件:
//将file1 重命名为file
git mv file1 file 就可以实现改名
//然后再提交
git commit –m “修改file1为file”
# renamed: file1 -> file1.1 #提交一个文件被重命名
//再查看仓库状态,为空
git status
以上是关于持续集成基本概念的主要内容,如果未能解决你的问题,请参考以下文章