引言：
DevOps平台在研发过程中，集成了许多的第三方工具来完善持续集成的流程，诸如Jira、Gitlab、Jenkins等，集成一个工具其实是一个繁琐的工作，需要注意到许多的细节，那么我们又是怎么做的呢？本文就是介绍一下我们是如何将这些工具集成到DevOps平台中去的。
目录：
1.DevOps平台第三方服务集成概览
2.DevOps平台第三方服务集成思路
3.DevOps平台第三方服务集成示例
1.DevOps平台第三方服务集成概览
说明：DevOps平台所有集成的第三方服务信息都保存在平台管理的服务集成页面，如下图展示：
1、介质服务器
DevOps平台采用的介质服务器类型为NEXUS，NEXUS是一个强大的maven仓库管理器，它极大的简化了本地内部仓库的维护和外部仓库的访问。
2、构建引擎
DevOps平台采用的构建引擎类型为Jenkins，Jenkins是一个开源软件项目，是基于Java开发的一种持续集成工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件的持续集成变成可能。
Jenkins是DevOps平台很重要的一个组成部分，CICD就靠Jenkins来实现，用户可以在DevOps平台创建一个构建定义、配置好需要的任务如maven构建，还可配置定期执行或触发执行该构建任务，将用户从繁琐的构建工作中解脱出来。
3、部署引擎
DevOps平台采用的部署引擎类型与构建引擎同为Jenkins。
4、质量分析服务器
DevOps平台采用的质量分析服务器为SonarQube，SonarQube 是一个用于代码质量管理的开源平台，用于管理源代码的质量。通过插件形式，可以支持包括java, C#, C/C++, PL/SQL, Cobol, JavaScrip, Groovy等等二十几种编程语言的代码质量管理与检测。
5、项目管理服务器
DevOps平台的项目管理我们采用的是Jira和Zentao这两个专业化的工具，依靠这两个工具支持起了DevOps平台的项目管理、概览和任务三大模块，用户可以很便捷的在DevOps平台查看编辑项目的基本信息、新建一个迭代和查找指派给自己的需求任务bug，提高工作效率。
JIRA 是Atlassian公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。
Zentao 是国产的开源项目管理软件,专注研发项目管理,内置需求管理、任务管理、bug管理、缺陷管理、用例管理、计划发布等功能,实现了软件的完整生命周期管理。
6、容器云服务器
DevOps平台集成的容器云服务器类型为k8s。
容器云以容器为资源分割和调度的基本单位，封装整个软件运行时环境，为开发者和系统管理员提供用于构建，发布和运行分布式应用的平台。
7、镜像服务器
DevOps集成的镜像服务器类型为Harbor。
Harbor是一个用于存储和分发Docker镜像的企业级Registry服务器，通过添加一些企业必需的功能特性，例如安全、标识和管理等，扩展了开源Docker Distribution。作为一个企业级私有Registry服务器，Harbor提供了更好的性能和安全。提升用户使用Registry构建和运行环境传输镜像的效率。Harbor支持安装在多个Registry节点的镜像资源复制，镜像全部保存在私有Registry中，确保数据和知识产权在公司内部网络中管控。另外，Harbor也提供了高级的安全特性，诸如用户管理，访问控制和活动审计等。
8、代码服务器
DevOps采用了Gitlab、Github和Svn作为代码的管理工具，支撑起了平台的代码模块，用户的项目相关代码都可以存储在以上三种工具中并关连到DevOps平台的相应项目里，方便用户查看对比代码，也为后续的CICD提供了便利。
GitLab是由GitLabInc.开发，使用MIT许可证的基于网络的Git仓库管理工具，且具有wiki和issue跟踪功能。使用Git作为代码管理工具，并在此基础上搭建起来的web服务。
GitHub是一个面向开源及私有软件项目的托管平台，因为只支持git 作为唯一的版本库格式进行托管，故名GitHub。
SVN是subversion的缩写，是一个开放源代码的版本控制系统，通过采用分支管理系统的高效管理，简而言之就是用于多个人共同开发同一个项目，实现共享资源，实现最终集中式的管理。
9、文档服务器
Confluence服务器的存在使得整个项目生产过程中的文档有了一个集中存储的地方，方便管理。
Confluence为团队提供一个协作环境。在这里，团队成员齐心协力，各擅其能，协同地编写文档和管理项目。从此打破不同团队、不同部门以及个人之间信息孤岛的僵局，Confluence真正实现了组织资源共享。
2.DevOps平台第三方服务集成思路
1、数据实体的对应
DevOps平台有属于自己的模板，比如工作项模板、迭代模板等，这就要求在集成第三方服务的时候要将获得的数据映射到DevOps模板中去再做展示，举例说，DevOps平台在集成Zentao作为项目管理工具的时候，有bug、story、task三张表，而DevOps平台只有Workitem一张表，那么我们就要将3张表的数据想办法转换到1张表中，这个过程肯定会存在概念无法对应的问题，解决思路要么就是用相近的概念替换，或者剔除掉多余的概念，总之，还是要以DevOps平台的模板为主；
2、API接口的调用
有些时候，第三方服务提供出来的api接口难以操作，或者存在接口错误的情况，此时我们就要转换思路，废弃使用api接口改为直接操作数据也许是一个好的解决方案；
拿Gitlab来说，Gitlab至今已经出了12版本，使用的api版本也已经到了v4，若我们还是使用Gitlab8的v3版api调用Gitlab12的接口是会出现问题的。
3.DevOps平台第三方服务集成示例
1、Gitlab集成
DevOps平台集成Gitlab过程大体可以分为以上3个步骤，先要做的是了解Gitlab的api接口，看一下身份认证方式是通过token还是session等，Gitlab的接口有很多我们是不需要的，此时我们就需要看DevOps模板需要哪些，不需要哪些，将需要的接口整理出来，并研究它们的QueryParam和Body的格式，验证接口是否可以正确调通，接口通了，我们得到了需要的数据，但是数据格式跟DevOps的模板不符，我们就要进行最后一步，将所得数据映射到DevOps模板就大功告成了。
1 ）研究GitlabAPI接口
GitlabAPI接口我们可以直接从官网的相关文档查阅，按照官方的说明，自GitLab 9.0起，API V4是首选使用的版本。2017年8月22日发布的GitLab 9.5不支持API V3。在GitLab 11.0中删除了API v3 ，就是说11版本起Gitlab不再支持v3版本的api，所以我们在集成Gitlab的时候就要考虑集成两个版本的API。
2 ）筛选DevOps平台所需的接口
DevOps平台集成Gitlab仅需要应用到Gitlab的部分接口，如代码库的增删改查，分支、标签的增删改查等，过滤去无用的接口，并以查询分支接口举例。
可见，该请求的身份认证方式是通过token实现的，返回的数据格式如图显示：
而DevOps代码分支模板如下图展示，所以要再做一次映射：
3 ）将返回数据填入DevOps模板并展示
此为集成成功后的Gitlab代码库在DevOps平台中的展示界面，用户可以在此查看代码库的文件内容，分支、标签信息，也可以对比不同分支或标签的差异：
2、Zentao集成
因为Zentao的接口设计比较特殊，在使用它的api接口来实现集成时遇到了种种问题，故改用了直接操作Zentao数据库来实现服务集成的方法。大体步骤是先研究Zentao的表结构，然后与DevOps相应表做对照，然后做DevOps服务端多数据源实现，直接从Zentao数据库读取数据，映射到DevOps的模板并展示给用户。
1 ）研究Zentao表结构&将Zentao表数据映射至DevOps模板
以Zentao的zt_story表举例，如图是禅道的需求表结构：
下图是DevOps工作项模板：
要想在DevOps平台中展示Zentao的需求信息，还要做一次数据映射，集成时，需要先设计DevOps平台的服务端多数据源实现，就是定义一个Zentao的Dao实现，同时，Zentao的数据库需要用户来配置，解决方案1：用户可以在配置文件中配置Zentao的数据库地址以及账号密码；解决方案2：用户可以在服务集成处配置Zentao的数据库信息；两种方式的Dao层实现也是有差异的。下面展示方案1的ZentaoDao部分实现：
2 ）数据展示
成功集成后的任务模块展示如图，用户可以在该界面进行任务、需求、bug的增删改查
4.总结
在集成一个第三方工具时，关注点无非就是如何调用API接口以及将得到的返回结果如何展示，除非API接口调用行不通，才会考虑做一个数据库的集成，在做数据库集成的时候还要小心再小心，如果存在关联表情况，可能会导致第三方工具的某些功能无法使用，还有当api接口访问不成功时，首先要确认请求的body是否符合该接口的规范，若body没问题，再考虑一下api接口的版本是否跟第三方工具的版本匹配，总之，集成并不是一个很难的事情，只要思路明确，耐心细心，总会成功。
