1.学习背景

当公司的服务器架构越来越复杂，需要频繁的发布新配置文件，以及新代码；
但是如果机器部署数量较多，发布的效率必然很低；
并且如果代码没有经过测试环境，预生产环境层层测试，最终才到生产环境，不经过测试的部署，会导致很严重的bug，因此必须要进行一定的代码测试。

因此从devops部署理念来看，任何一家单位都必须实现CICD（持续集成、持续交付）的理念，实现自动化代码集成、自动化代码部署。

目前主流的解决方案，学习的技术就是

• git
• jenkins
• gitlab

2.什么是devops开发流程

DevOps是一种实现Dev(开发)与Ops(运维)工作流有效联合的运维文化理念。

为什么要理解devops？

越是高级的运维，越是要了解开发与运维的有效结合工作，推进运维自动化工作，提升运维效率。

一个软件开发团队，会包括

项目经理，系统架构师、前端开发者，后端开发者，测试工程师，网络工程师，运维工程师等

如何让软件在开发、测试、运维及最终发布之间进行有效的流动，这就是DevOps所要关注的重点。

DevOps是一种文化，一种理念，是一种把开发（Dev）、测试（Test）、运维（Ops）及最终发布（CR）工作流进行联合的思想。

2.1 devops如何实践

- 所有环境和代码使用同一个仓库，将软件包纳入版本管理
- 团队共同决定发布流程
- 保持 DEV、TEST、PRODUCTION 环境的一致性
- 自动化回归测试，回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
- 小步提交，每日部署；而不是一次部署大量变更 
- 更快、更频繁发布

3.版本控制系统

什么是“版本控制”？我为什么要关心它呢？ 

版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。

3.1 你自己本地怎么管理文件？

许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。

这么做唯一的好处就是简单，但是特别容易犯错。

有时候会混淆所在的工作目录，一不小心会写错文件或者覆盖意想外的文件。

如果你在学校写过毕业论文，那你一定遇见过这样的问题

一个论文翻来覆去的改，写一点觉得有问题，写一点还觉得有问题，还不容易写好了，导师还挑刺，说这改的还不如上回，给改回去、、、

• 看着这一堆乱七八糟的文件，你自己也不记得，每一个文件到底写了什么内容，还得一个个看，想删又不敢删。。。
• 当你写完了毕业论文，你还得用U盘拷给导师，或者发个邮件给他，但是你回家可能还得改论文，那你发给导师的论文和你本地最新的论文又不一致了。。

于是这么多令人fuck指的操作，你就希望有没有一个软件

帮你记录文件变动的操作，并且同事还能一起操作，不需要自己传输文件，想知道变动了什么，只需要去软件里看看，这是不是很nb？

3.1.1 例如nginx配置文件的多人修改

如图，会发生什么结果？

3.2 这个软件雏形？

对于文件使用版本号，日期的管理，这种方式比起没有版本管理好得多，但是也很臃肿，且他人不容易看得懂

3.3 新式版本控制

现在的版本控制系统又是如何管理的，且还能实现快速回退功能。

4.什么是集成(CI)

在实际软件开发中，常会有如下两种场景：

1.现在有一个电商平台需要开发，由于电商平台模块众多，此时就需要不同开发人员开发不同的模块，最红把所有人的代码都集中到一个系统中。

集成后对其进行部署上线。

2.随着时间的推移，无论是修复bug还是新功能开发，后续都要对系统进行不断的更新、迭代。

4.1 什么是持续集成（CI）

持续集成（Continuous integration ，CI）

持续集成就是在于”持续“两字，频繁的（一天多次）的将代码集成到主干(master)，重复如上的工作。

说白了就是你公司要部署一套系统，能支持，让所有的开发人员，都可以快速、集中式的提交代码，整合到一个主干线。

程序员本地写代码，通过git管理

↓推代码

git仓库，gitlab，github

↓仓库通知CI服务器，jenkins

jenkins执行脚本，如对代码编译，测试，运行

↓通知集成结果

这里属于第一道流水线的测试完毕。

4.2 使用持续集成好处

1.快速发现错误，每完成一点更新，就集成到主干，可以快速发现bug，也容易定位错误。

2.节省人力成本，省去手动反复部署操作

3.加快软件开发进程

4.实时交付

5.防止大幅度偏离主干，如果不经常集成，主干也在更新，会导致后续集成难度增大，或是难以集成。

4.3 不做CI行不行

行，如果你的规模太小，也就没必要部署这套系统了，写点部署脚本就完事了。

但是如果项目较大，且较复杂，需要不断的加新功能，或者升级产品，因此必须引入CI系统。

5.什么是持部署（CD）

Continuous Deployment，持续部署，产品从开始到结束诞生的产物，在服务器上健康运行。

持续交付指的是在持续集成(CI)的环境基础之上，将代码自动化部署到预生产环境。

• 持续集成，对代码进行集成测试
• 持续部署，对代码进行自动化部署

当你部署了一套基于 git + gitlab + jenkins + shell  的持续集成、持续部署系统之后

就可以实现快速的代码快速更新，快速发布，且因为经过了测试，保证了代码质量。
因为如果开发李四，写的新功能代码有bug，当你基于jenkins对代码测试之后，定位bug、通知程序修复bug，最终再整合最新的代码到master主线上。

这个自动化流程能极大提高生产级别的开发、测试、运维效率了。

1. 程序员张三开发代码，git push 推送到 代码仓库
2. 开发老大，合并张三写的代码到master主线
3. 测试人员介入，进行代码的功能测试、白盒测试等
4. 代码测试验收完毕，运维基于jenkins实现代码部署到生产环境。

5.1 如何实现CD

当有人提交了代码，就自动的通知jenkins对代码进行构建 > 测试 > 确认代码可运行  > 构建到生产服务器 

整个过程全自动化，但是有可能出现难以预料的问题

最好的是半自动化，使用持续交付（人工介入+jenkins发布），也不能过于自动化，容易翻车。

6.版本控制系统介绍

6.1 SVN

集中式版本控制系统，很老旧的技术公司会用。

Linus一直痛恨的CVS及SVN都是集中式的版本控制系统，而Git是分布式版本控制系统，集中式和分布式版本控制系统有什么区别呢？

先说集中式版本控制系统，版本库是集中存放在中央服务器的，而干活的时候，用的都是自己的电脑，所以要先从中央服务器取得最新的版本，然后开始干活，干完活了，再把自己的活推送给中央服务器。

中央服务器就好比是一个图书馆，你要改一本书，必须先从图书馆借出来，然后回到家自己改，改完了，再放回图书馆。

SubVersioN(SVN)

工作模式就是

1. 每一个人复制一份源码到本机修改
2. 各自修改完毕后，再一一合并为统一的源码

复制 > 修改 > 合并

集中式版本控制，典型代表SVN

集中式版本控制系统最大的毛病就是必须联网才能工作，如果在局域网内还好，带宽够大，速度够快，可如果在互联网上，遇到网速慢的话，可能提交一个10M的文件就需要5分钟，这还不得把人给憋死啊。

而且如果SVN集中式仓库服务器挂了，所有人都再无法使用、提交、下载数据。

6.2 GIT 分布式版本控制系统

分布式版本控制，没有中央服务器的概念，每个人都有自己的版本库，因此每个人在工作时候，不需要联网，版本库本地即可管理。

既然每个人都是一个完整的版本库，同事之间如果需要协作开发，就需要找一个用于“交换文件”的中央服务器，这个服务器不存在也不影响大家干活，只是用于交换文件内容。

GIT最强大的功能还有分支管理，远甩SVN等软件。

6.3 git特点

1. git是分布式的，特点是保存本地文件的元数据（meta data，文件属性等），将本地文件所有的的元信息，记录在git repo里的.git隐藏文件夹中。

2. git的使用可以不用网络，因为本地版本控制仓库就在你自己机器上，每一个人就是一个完成的版本库。
只不过是最终将你的本地仓库，作为一个分支，推送、合并到一个统一的线上代码仓库主干线即可，实现代码集成。