持续集成交互部署入门学习笔记1
[TOC]
Title: 持续集成交互部署入门学习笔记 2020年12月17日
[TOC]
0x00 基础概念
Q: 为啥要学习CI、CD?
实际就是为了偷懒与提升工作效率，开发过程中最怕集成时遇到问题导致返工，而持续集成、持续交付、持续部署恰恰可以早发现早解决，从而可以避免这个问题。
1.定义
集成
Q: 什么是集成?
A: 在一个项目之中将不同开发人员开发的不同模块进行组合装载形成一个系统（封装打包的产物，比如Jar包），随着项目的进度该系统无论是Bug修复、新功能的开发，后续都需要对系统进行不断的迭代更新；
Q: 什么是持续集成?
A: 持续集成（Continuous Integration）简称CI指的是频繁(一天)多次将代码集成到主干; 持续集成强调开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。
CI 流程: 编译 -> 测试 -> 通知 & 反馈结果
WeiyiGeek.CI
好处(Advantages);
- 1.快速发现错误
- 2.节省人力成本
- 3.加快软件开发进度
- 4.实时交付
- 5.防止分支大幅度偏离主干; 如果不经常集成而主干又不断更新，会导致以后集成难度变大或者难以集成;
目的(Target): 让产品可以快速迭代，同时保持高质量(容易发现和改正Bug), 简化集成工作流程;
Q: 什么情况下需要使用持续集成?
A: 当项目开发规模较小的时候手动软件集成是没有问题的, 但是如果是大项目的情况下需要不断添加新功能或者升级新产品，则需要进行反复集成所以这时采用持续集成的方式来简化我们的工作;
交付
Q: 什么是交付?
A: 在持续集成的环境基础之上，将代码部署到预生产环境中;
Q: 什么是持续交互?
A: 持续交付（
Continuous Delivery）在持续集成的基础上，将集成后的代码自动Auto部署到更贴近真实运行环境的「类生产环境」（production-like environments）中; 比如: 我们完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境中。
CD 流程 ：代码开发 -> 单元测试 -> 合并代码 -> 测试 -> Manual(手动)/Auto(自动) -> 部署到预生产服务器;
WeiyiGeek.CD
部署
Q: 什么是部署?
A: 部署则是在持续交付的基础上，手动部署到生产环境的过程；
Q: 什么是持续部署?
A: 在持续部署（
Continuous Deployment）和持续交互的区别就是最终部署到生产环境是自动化的。
WeiyiGeek.CD
持续集成实施流程
描述: 从持续集成的设计，代码从提交到生产，整个过程有以下几步：
开发者 -> 提交代码 (Java/php/nodejs) -> 代码托管(gitlab) -> 获取代码 -> 代码测试 -> 构建(jenkins) -> 黑盒测试(SonarQube) -> 部署 -> 回退
总结 Q: 如何理解持续集成、持续交付、持续部署？
- 集成：是指软件个人研发的部分向软件整体部分交付，以便尽早发现个人开发部分的问题；
- 交付：是指研发尽快向客户交付，一般运行在以便尽早发现生产环境中存在的问题。
- 部署：是代码尽快向可运行的开发/测试环境交付，以便尽早测试；
2.版本控制系统
概述
Q: 什么是版本控制系统(Version Control System)?
A: 将每一次文件的变化，都集中在一个系统中加以版本记录，以便后续查阅特定的文件版本历史记录的系统；
Q: 版本控制系统解决那些问题?
- 1.追溯文件历史变更
- 2.多人团队协同开发
- 3.代码集中统一管理
Q: 常见的版本控制系统工具
- 1.集中式 SVN (需要远程访问一个中央数据仓库进行通信)
- 2.分布式 GIT (可以远程拉取代码到本地，在没有网络的情况之下也能进行版本控制，每一次提交不依赖远程服务器，等待有网卡的时候在与远程仓库进行版本同步)
Git 功能
Git 工具提交流程 : init 初始化 -> 本地目录(代码修改) -> 工作区 -> [git add] 暂存区 -> [git commit] git本地仓库 -> [git push] git远程仓库；
主要功能:
代码提交
文件比对
版本回退
# (1) 修改后未提交到缓冲区时，使用以前提交的至缓冲区的内容覆盖本地目录
git checkout -- file-test.txt
# (2) 修改后已提交到缓冲区时，则回退到提交之前然后在用上面的命令进行依次回退
git reset HEAD file-test.txt
# (3) 多次提交内容到git仓库，则利用 commit ID进行跳回到指定ID时的版本(文件内容以及其状态)
git log --oneline
git reset --hard commitID # 如 回退 后想回到中间版本 则利用 git reflog 查看历史commit ID 然后安装指定ID版本进行回退版本分支(简单理解平行分支): 注意一般是由分支进行拉取并合并Master提交的代码，最后提交到master分支上;
# 查看分支
git branch
# 创建分钟
git branch dev-branch
# 切换分钟
git checkout dev-branch
# 创建并切换分支
git checkout -b
# 在dev-branch分支上合并 master 分支，此时产生新的commit-ID
git merge master
# 测试无误后 回到master 分支上合并 dev-branch 分支内容
git checkout master
git merge dev-branch
# 删除分支
git branch -d dev-branch标签 (可以看做是COMMIT-ID的别名)
# 添加标签
git tag -a "v1.0" -m "项目初始化开发后第一个版本"
# 为指定的commitID（a3cc55s）打标签
git tag -a "v1.0" a3cc55s -m "项目初始化开发后第一个版本"
# 查看标签
git tag -l
# 查看标签内容
git show v1.0
# 删除标签
git tag -d v1.0企业自建
描述: 在大多数企业都会选用免费开源的版本控制系统进行为企业自建版本控制系统，而Gitlab就是一个不二选择;
Q: 什么是Gitlab?
Gitlab 是一个开源分布式的版本控制系统，它是由Ruby语言开发完成。
Gitlab 主要实现的功能:管理项目源代码，以及对源代码进行版本控制、以及代码复用与查找;
Q: Gitlab VS Github?
1.相同点：两者都是提供代码托管服务,在很大程度上Gitlab是仿照GitHub来做的; 2.不同点: 最大的不同在于Github对企业创建私有仓库是收费(现在已经可以对个人用户进行免费)，而gitlab是创建的私有仓库是免费的；
Gitlab 版本:
- gitlab-ee 商业版本 (收费)
- gitlab-ce 社区版本（Free）
PS : 从代码的私有性方面考虑Gitlab无疑是最佳选择，而对于开源项目而言Github依然是代码托管的首选平台;
Q: Gitlab 优势及应用场景?
- 1.开源免费，搭建简单，维护成本低，适合中小型公司;
- 2.权限管理，能实现代码对部分人可见，确保项目的安全性；
- 3.离线同步，保证我们不在实时依赖网络环境进行代码提交；
如何搭建使用请参照本博客中的GitLab安装与基础使用文章;