1.持续集成
2.持续交付
3.持续部署
4.持续集成实现的思路（git、jenkins、shell）
5.版本控制系统
在实际软件开发中，常会有如下两种场景：
1.现在有一个电商平台需要开发，由于电商平台模块众多，此时就需要不同开发人员开发不同的模块，最红把所有人的代码都集中到一个系统中。集成后对其进行部署上线。
2.随着时间的推移，无论是修复bug还是新功能开发，后续都要对系统进行不断的更新、迭代。
持续集成（Continuous integration ，CI）
持续集成就是在于”持续“两字，频繁的（一天多次）的将代码集成到主干(master)，重复如上的工作。
程序员
↓推代码
git仓库，gitlab
↓仓库通知CI服务器，jenkins
jenkins执行脚本，如对代码编译，测试，运行
↓通知集成结果
程序员对结果处理
1.快速发现错误，每完成一点更新，就集成到主干，可以快速发现bug，也容易定位错误。
2.节省人力成本，省去手动反复部署操作
3.加快软件开发进程
4.实时交付
5.防止大幅度偏离主干，如果不经常集成，主干也在更新，会导致后续集成难度增大，或是难以集成。
让产品可以快速迭代，同时还能保持高质量。（程序员写了新功能，很可能有bug，快速进行jenkins集成测试，能够快速发现bug，定位、解决bug，再次集成操作，整个过程自动化，非常高效且省时省力）
持续集成核心目的：代码集成到主干之前，对代码进行自动化测试。只要有一个测试用例失败，就不能集成，当然持续集成并不能完全的消除bug，主要目的是让bug更容易发现和改正。
如果项目开发的规模较小，软件集成不是问题。
如果项目很大，需要不断添加新功能，或不断的升级产品，则需要进行反复集成，因此必须使用持续集成来简化工作。
Continuous Delivery
交付，产品从开始到结束诞生的产物，在服务器上健康运行。
持续交付指的是在持续集成的环境基础之上，将代码部署到预生产环境。
Continuous Deployment
持续部署是持续交付的下一步，指代码在任何时刻都是可部署的，最后将部署到生产环境的过程自动化。
持续部署和持续交付的区别就在于最终部署到生产环境是自动化的。
当有人提交了代码，就自动的通知jenkins对代码进行构建 > 测试 > 确认代码可运行 > 构建到生产服务器 整个过程全自动化，但是有可能出现难以预料的问题 最好的是半自动化，使用持续交付
根据持续集成的设计，代码从提交到进入生产环境，整个过程如下：
jenkins本身没有太多功能，但是支持丰富的插件，进行调度，完成工作。
什么是“版本控制”？我为什么要关心它呢？ 版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。
许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。 这么做唯一的好处就是简单，但是特别容易犯错。 有时候会混淆所在的工作目录，一不小心会写错文件或者覆盖意想外的文件。
如果你在学校写过毕业论文，那你一定遇见过这样的问题
一个论文翻来覆去的改，写一点觉得有问题，写一点还觉得有问题，还不容易写好了，导师还挑刺，说这改的还不如上回，给改回去、、、
于是这么多令人fuck指的操作，你就希望有没有一个软件，帮你记录文件变动的操作，并且同事还能一起操作，不需要自己传输文件，想知道变动了什么，只需要去软件里看看，这是不是很nb？
对于文件使用版本号，日期的管理，这种方式比起没有版本管理好得多，但是也很臃肿，且他人不容易看得懂
| 版本 | 文件名 | 用户 | 说明 | 日期 |
|---|---|---|---|---|
| 1 | 美国皇家大学毕业论文v1.doc | yuchao | 论文初稿 | 7/12 10:38 |
| 2 | 美国皇家大学毕业论文v2.doc | yuchao | 论文修改版 | 7/12 18:09 |
| 3 | 美国皇家大学毕业论文v3.doc | Onlyu | 小于帮我修改论文 | 7/13 9:51 |
| 4 | 美国皇家大学毕业论文v4.doc | Wupeiqi | 武沛奇帮我修改论文 | 7/14 15:17 |
现在的版本控制系统又是如何管理的，且还能实现快速回退功能。
1.追溯文件历史变更记录
2.多人团队协同开发
3.代码集中统一管理
Linus一直痛恨的CVS及SVN都是集中式的版本控制系统，而Git是分布式版本控制系统，集中式和分布式版本控制系统有什么区别呢？
先说集中式版本控制系统，版本库是集中存放在中央服务器的，而干活的时候，用的都是自己的电脑，所以要先从中央服务器取得最新的版本，然后开始干活，干完活了，再把自己的活推送给中央服务器。中央服务器就好比是一个图书馆，你要改一本书，必须先从图书馆借出来，然后回到家自己改，改完了，再放回图书馆。
集中式版本控制，典型代表SVN
集中式版本控制系统最大的毛病就是必须联网才能工作，如果在局域网内还好，带宽够大，速度够快，可如果在互联网上，遇到网速慢的话，可能提交一个10M的文件就需要5分钟，这还不得把人给憋死啊。
而且如果集中式版本服务器宕机了，所有人都没法工作。
分布式版本控制，没有中央服务器的概念，每个人都有自己的版本库，因此每个人在工作时候，不需要联网，版本库本地即可管理。
既然每个人都是一个完整的版本库，同事之间如果需要协作开发，就需要找一个用于“交换文件”的中央服务器，这个服务器不存在也不影响大家干活，只是用于交换文件内容。
GIT最强大的功能还有分支管理，远甩SVN等软件。
原文：https://www.cnblogs.com/abc1234567/p/14351524.html