DevOps平台之开源技术图谱( 二 ) _DevOps

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平台之开源技术图谱】
而DevOps代码分支模板如下图展示，所以要再做一次映射：

文章插图

3 ）将返回数据填入DevOps模板并展示
此为集成成功后的Gitlab代码库在DevOps平台中的展示界面，用户可以在此查看代码库的文件内容，分支、标签信息，也可以对比不同分支或标签的差异：
2、Zentao集成
因为Zentao的接口设计比较特殊，在使用它的api接口来实现集成时遇到了种种问题，故改用了直接操作Zentao数据库来实现服务集成的方法。大体步骤是先研究Zentao的表结构，然后与DevOps相应表做对照，然后做DevOps服务端多数据源实现，直接从Zentao数据库读取数据，映射到DevOps的模板并展示给用户。
1 ）研究Zentao表结构&将Zentao表数据映射至DevOps模板