目录
一、持续集成
1.1 持续集成基本概念
1.1.1 持续集成的含义
1.1.1.1 持续集成流程是依赖产品版本迭代和版本分支而产生的
1.1.1.2 持续集成流程中包含的内容
1.1.2 传统打包模式说明
1.1.2.1 传统打包模式概述
1.1.2.2 传统打包模式问题
1.1.3 持续集成模式
1.1.3.1 持续集成模式概述
1.1.3.2 持续集成模式流程说明
二、版本控制
2.1 版本控制的基本概念
2.1.1 版本控制的含义
2.1.2 版本控制的好处
2.1.3 版本控制软件的基本功能
2.1.3.1 检入检出控制
2.1.3.2 分支和合并
2.1.3.3 版本历史记录
三、其它基本概念
3.1 概述
3.2 代码仓库
3.3 开发环境
3.4 代码编译
3.5 编程语言
一、持续集成
1.1 持续集成基本概念
在前面文章介绍DevOps模型时曾提及持续集成的概念，是指通过持续地将需求转化为开发的代码，合并到源码仓库主干分支上，并确保代码合并后的集成测试通过的这一段流程。
1.1.1 持续集成的含义
1.1.1.1 持续集成流程是依赖产品版本迭代和版本分支而产生的
持续集成流程是依赖产品版本迭代和版本分支而产生的，每一个不同的版本迭代，每一个不同的开发者，将其合并到主分支的过程。
1.1.1.2 持续集成流程中包含的内容
持续集成流程中，除了代码分支合并之外，还包含单元测试、功能测试、集成测试等内容。代码分支合并直至完成集成测试，这些结合在一起才是持续集成流程所包含的内容。
明白了上述两层含义之后，再回到软件研发的过程中，来讨论持续集成的概念，这样方便大家能更深刻地理解持续集成的概念和意义。
1.1.2 传统打包模式说明
1.1.2.1 传统打包模式概述
前文介绍DevSecOps发展时，曾提及开发人员的开发环境和工作模式的变化。在互联网行业早期，没有使用持续集成工具之前，开发人员通常在本地计算机开发代码，然后提交到SVN、Git之类的版本控制服务器上。当多人的团队合作开发时，提交时会涉及代码合并，合并后的代码通过编译后，再部署到测试环境进行测试验证。
大概如下图所示的流程：
1.1.2.2 传统打包模式问题
- 开发人员在本地计算机开发代码后，完成了单元测试，但版本发布时，却要面临不同人员开发的代码进行合并后的重新测试。
- 开发人员在本地计算机开发并完成验证的应用程序，因本地环境和测试环境的不一致导致应用程序无法启动。
- 每次打包应用程序时，都需要重新编译、构建，重复的工作虽简单但又无法省略，增加无效的工作量。
- 准备发布的版本正在测试中，新的功能迭代已开始，开发的代码提交后需要针对不同的版本进行代码管理，防止代码版本与功能混淆。
1.1.3 持续集成模式
1.1.3.1 持续集成模式概述
诸如上述这些问题，在软件开发过程中时常出现。为了解决这些问题，业界逐步推出了持续集成的概念，意图通过持续集成工具的使用，减少开发过程中重复的人工任务，降低人工操作带来的出错率，释放开发人员的精力，更多地专注于业务功能开发本身。
大概流程如下图所示：
1.1.3.2 持续集成模式流程说明
从上图中可以看出，通过持续集成工具的使用，将开发人员代码编写、代码提交、编译构建、测试验证等环节组合在一起，形成了一个流水线管道或标准化流程。基于这个流程，开发人员可以把编译、构建的重复工作交于持续集成工具去做，代码的质量、代码的安全可以通过持续集成工具与代码检测工具、安全工具的集成来自动化去做。在流程中，也可以设置门禁或卡点，如严重缺陷达到2%时，流程自动中断；发现严重代码安全漏洞时，流程中断；依赖组件不合规时，流程中断等。开发人员只需要关注流程的输出，保证结果符合流程定义的要求即可。
二、版本控制
2.1 版本控制的基本概念
在软件工程中，为了保障软件版本的发布或持续集成流程的落地，需要做软件开发过程输出产物的版本管理，这是版本控制的最初由来。下面，首先来介绍版本控制的基本概念。
2.1.1 版本控制的含义
版本控制是指在软件工程中，针对目录、代码、资源等进行管理，记录一个或多个文件的变化，以便查阅特定版本的修改历史，了解版本的快照信息
2.1.2 版本控制的好处
- 通过版本控制管理，能对每一个不同的版本迭代所包含的代码、资源、数据等进行快照、备份、还原，帮助项目组人员快速找到原始文件。
- 当项目组中有多人参与协同开发时，采用版本控制管理中的分支和合并，可以高效地解决不同开发人员、不同版本之间的协同冲突问题，提升协同效率。
2.1.3 版本控制软件的基本功能
在大多数项目管理中，版本控制是使用版本控制软件或系统来实现的。一个标准的版本控制系统至少包含以下几个部分的功能。
2.1.3.1 检入检出控制
检入检出是软件开发人员在编码过程中对源文件进行修改的最基本操作，当项目管理使用版本控制系统进行源代码管理时，所有的源代码都托管在代码仓库里。为了保障版本的可控性，所有人员在修改源代码之前，需要从代码仓库中对代码进行检出操作，表示当前的源代码文件被检出的人所独占，检出后开发人员可以在自己的工作空间下进行文件编辑。当开发人员编辑完成后，再执行检入操作，提交到代码仓库，释放对代码源文件的占用，便于其他项目人员对文件进行修改，如下图所示。
如果没有检入检出的控制机制，则项目的源代码管理就会产生混乱，如几个人同时修改文件，提交代码时导致其他人修改的代码被丢失。通过检入检出控制过程，同步控制代码仓库中源代码版本的正确性，从而保证不同的人协同开发时，并发提交和修改的源代码文件不会产生版本混乱的情况。
2.1.3.2 分支和合并
分支和合并是版本控制系统中很重要的两个基本功能。下面通过版本的几个概念来了解它们的含义。首先，来看看主版本或基线版本。
在版本管理中，一般把第一个关键里程碑的产物作为基线版本，或主版本。在此版本基础上，加上标签，实施版本控制管理。之后的所有版本都以此版本为基础。如果在此版本上复制一份，单独建立一个分支，则为分支版本。
分支版本独立于主版本开发一段时间后，完成了分支所需要的功能，再将分支版本合并到主版本中，则产生合并版本，如下图所示。
无论是主版本、分支版本还是最终的合并版本，都是版本控制过程中不断进行迭代的结果。分支和合并成为版本控制过程中最为常见的基本操作。
2.1.3.3 版本历史记录
每一个版本的迭代和修改都会产生版本的历史记录。记录历史版本的版本号、版本修改时间、版本修改者、版本修改描述等信息是版本控制系统中常见的功能。通过版本历史记录，项目管理人员、代码开发人员可以方便地找到某个版本对应的代码文件、代码片段、修改信息，可以通过此信息，还原历史，查找问题，追溯修改内容等。
三、其它基本概念
3.1 概述
在黄金管到持续集成阶段中，除了持续集成、版本控制的基本概览外，还有一些其他的概念也是非常重要的，了解它们可以帮助读者更清晰、全面地掌握持续集成流程中涉及的技术组件和流程流转。
3.2 代码仓库
代码仓库又称储存库、资源库、代码库，是版本控制系统底层存储的数据结构的总称，通常是指版本控制系统中文件存储模块，它主要包含存储的源代码文件、目录结构、元数据等。用户通过版本控制系统对这些存储的文件进行管理（如文件的修改、删除、历史跟踪、还原等）。例如，GitHub、GitLab、码云等。
3.3 开发环境
开发环境是指开发人员进行编码开发的工作环境，通常包含开发语言及其运行环境、开发工具。在DevSecOps中，不同的开发工具涉及不同的IDE安全插件，以帮助开发人员在本地计算机中检测代码的安全性。常见的IDE有Visual Studio、Eclipse、Android Studio、IntelliJ IDEA等。
3.4 代码编译
代码编译是指使用编译工具、编译器将开发人员开发的源代码转为目标代码的过程的。开发人员生产出来的源代码是否具备可执行性，需要转为目标机器的可执行程序才可以在目标机器上运行。如果目标机器是操作系统，则编译后的是汇编类代码，形成可执行文件，通过加载器加载后被操作系统调用；如果目标机器是虚拟机，如JVM虚拟机，则编译后为字节码，即JVM虚拟机可执行的解释型语言。代码编译的过程，一般使用编译器，编译器读取源代码，对源代码进行语法分析，通过结构化语法树、代码优化、流程控制等操作，最终生成目标机器可执行的程序或字节码。
3.5 编程语言
编程语言是指软件开发所使用的开发语言，程序员使用编程语言编写应用程序代码，通过代码和算法实现，向计算机发生指令，以完成业务操作所需要的功能。按照编程语言的发展阶段，大体可以分成机器语言、汇编语言、高级语言三类。本书重点是指高级语言，如Java、C++、C语言、net、C#、Python、PHP、Ruby等。
好了，本次内容就分享到这，欢迎大家关注《DevSecOps》专栏，后续会继续输出相关内容文章。如果有帮助到大家，欢迎大家点赞+关注+收藏，有疑问也欢迎大家评论留言！
