浅谈持续集成

最新推荐文章于 2022-03-16 10:43:39 发布

呆宅呀呆宅

最新推荐文章于 2022-03-16 10:43:39 发布

阅读量342

点赞数 1

分类专栏：项目管理文章标签： jenkins 持续集成系统项目管理

本文链接：https://blog.csdn.net/github_39060174/article/details/114905983

版权

1 篇文章 0 订阅

订阅专栏

持续集成是一种软件开发实践，可以理解为软件开发的过程中的一种方法，并不是我们理解中的具体某种工具（例如Jenkins）
这个实践的内容主要指的是在开发过程中不断地将团队各个成员的成果集中到同一个主干。（例如：实践中的代码集成，每个人push到feature上的成果不断集成到master）
每次集成都通过自动化构建，构建的具体内容可能包括：编译、自动化测试、打包、自动部署

从两方面去理解，一是集成，二是持续：

什么是Jenkins?

开发人员对本地拉取的项目源码进行提交，提交至版本库（Source Control Repository，GitLab，SVN等）
Jenkins的轮询器（SCM）通过轮询版本库的版本变更，当检测到变更出发一新的构建任务，将版本库代码拉取至项目工作空间（Project Work Space）
触发构建任务（build），除了对工作空间的源码进行构建，也可以集成项目配置中心，获取构建目标所需的配置文件。
构建完成后可以继续执行代码检查（图中未画），以及自动化测试（Test）
构建最后一步是对工程进行打包，可以打成war文件，jar文件等
build、test、package三个阶段可以输出构建过程的文件，诸如代码检查报告，单元测试覆盖率报告等，通过Jenkins的页面可以展示相应的报告结果（图形化的界面）
完成构建打包后，可以继续对构建结果进行发布或部署至对应的可发布库，可以是指定的服务器或统一的发布库。

引申：其他持续集成工具

GitLab CI：GitLab的一部分，易于和GitLab集成，可利用部门已经搭建的GitLab
其他CI工具参考：21 个好用的持续集成工具

源代码集成也应该是持续集成的一部分，保证源代码库良好的集成规则是后续集成工作的前提。下面提供了一个实践中的代码集成方式：

源码库基本上遵循生产（master）、测试（develop）、开发（feature）三个分支，分支对不同角色具备不同权限控制。
开发角色（develop）将自己的开发功能集成到feature，经由管理人员（master、owner）集成到develop，再集成到master 。
feature：应由各个开发人员确保模块完成及时集成
develop：应保持每周一次及以上的集成频率，确保不会有大的偏差
master：在develop无问题的情况下集成，根据更新情况进行

我们常见的编译构建工具（Java）有Ant、Maven，我们可以在Jenkins中集成构建工具去实现Jenkins的自动编译工作。Jenkins编译是代码集成的第一步保障，若编译失败Jenkins能够告诉你编译失败了，并且可以通过控制台信息查看编译记录。

我们在IDEA编译通过不代表Jenkins编译通过，比如漏提交部分修改、新增的文件，因此开发人员提交完代码后续还要跟踪Jenkins的构建结果。（做好Check）

我们可以在Jenkins中安装代码检查插件，对项目代码进行代码检查，提升代码质量，常见的代码检查工具又checkstyle、findbugs、PMD

工具	目的	检查项	特点
CheckStyle	检查java源文件主要关注格式，是否与代码规范相符	Javadoc注释命名规范多余的Imports Size度量，如过长的方法缺少必要的空格重复代码等	过于严格，但易修改
FindBugs	检查.class文件，查找Java ByteCode潜在问题	NullPoint空指针检查没有合理关闭资源字符串相同判断错（==，而不是equals）	比较严格
PMD	检查java源文件中潜在的问题	空try/catch/finally/switch语句块未使用的局部变量、参数和private方法空if/while语句过于复杂的表达式不必要的if语句等复杂类	比较严格，不易修改

即进行单元测试、并输出单元测试覆盖率报告，集成结果是否合格的最有力保障，例如：

对完成构建的发布包部署到指定容器下，不用人工手动拿包、放包，启动测试，完成集成的最后一步检查——应用的成功部署启动。
Jenkins中可采用的自动部署方式

延伸：针对不同配置需求的自动部署如何实现？
1 Apollo配置中心
2 考虑构建脚本中对配置文件的替换

关注