[[273733]]

引言：

DevOps平臺在研發(fā)過程中，集成了許多的第三方工具來完善持續(xù)集成的流程，諸如Jira、Gitlab、Jenkins等，集成一個工具其實(shí)是一個繁瑣的工作，需要注意到許多的細(xì)節(jié)，那么我們又是怎么做的呢？本文就是介紹一下我們是如何將這些工具集成到DevOps平臺中去的。

目錄：

1.DevOps平臺第三方服務(wù)集成概覽

2.DevOps平臺第三方服務(wù)集成思路

3.DevOps平臺第三方服務(wù)集成示例

1.DevOps平臺第三方服務(wù)集成概覽

說明：DevOps平臺所有集成的第三方服務(wù)信息都保存在平臺管理的服務(wù)集成頁面，如下圖展示：

1、介質(zhì)服務(wù)器

DevOps平臺采用的介質(zhì)服務(wù)器類型為NEXUS，NEXUS是一個強(qiáng)大的maven倉庫管理器，它極大的簡化了本地內(nèi)部倉庫的維護(hù)和外部倉庫的訪問。

2、構(gòu)建引擎

DevOps平臺采用的構(gòu)建引擎類型為Jenkins，Jenkins是一個開源軟件項(xiàng)目，是基于Java開發(fā)的一種持續(xù)集成工具，用于監(jiān)控持續(xù)重復(fù)的工作，旨在提供一個開放易用的軟件平臺，使軟件的持續(xù)集成變成可能。

Jenkins是DevOps平臺很重要的一個組成部分，CICD就靠Jenkins來實(shí)現(xiàn)，用戶可以在DevOps平臺創(chuàng)建一個構(gòu)建定義、配置好需要的任務(wù)如maven構(gòu)建，還可配置定期執(zhí)行或觸發(fā)執(zhí)行該構(gòu)建任務(wù)，將用戶從繁瑣的構(gòu)建工作中解脫出來。

3、部署引擎

DevOps平臺采用的部署引擎類型與構(gòu)建引擎同為Jenkins。

4、質(zhì)量分析服務(wù)器

DevOps平臺采用的質(zhì)量分析服務(wù)器為SonarQube，SonarQube 是一個用于代碼質(zhì)量管理的開源平臺，用于管理源代碼的質(zhì)量。通過插件形式，可以支持包括java, C#, C/C++, PL/SQL, Cobol, JavaScrip, Groovy等等二十幾種編程語言的代碼質(zhì)量管理與檢測。

5、項(xiàng)目管理服務(wù)器

DevOps平臺的項(xiàng)目管理我們采用的是Jira和Zentao這兩個專業(yè)化的工具，依靠這兩個工具支持起了DevOps平臺的項(xiàng)目管理、概覽和任務(wù)三大模塊，用戶可以很便捷的在DevOps平臺查看編輯項(xiàng)目的基本信息、新建一個迭代和查找指派給自己的需求任務(wù)bug，提高工作效率。

JIRA 是Atlassian公司出品的項(xiàng)目與事務(wù)跟蹤工具，被廣泛應(yīng)用于缺陷跟蹤、客戶服務(wù)、需求收集、流程審批、任務(wù)跟蹤、項(xiàng)目跟蹤和敏捷管理等工作領(lǐng)域。

Zentao 是國產(chǎn)的開源項(xiàng)目管理軟件,專注研發(fā)項(xiàng)目管理,內(nèi)置需求管理、任務(wù)管理、bug管理、缺陷管理、用例管理、計劃發(fā)布等功能,實(shí)現(xiàn)了軟件的完整生命周期管理。

6、容器云服務(wù)器

DevOps平臺集成的容器云服務(wù)器類型為k8s。

容器云以容器為資源分割和調(diào)度的基本單位，封裝整個軟件運(yùn)行時環(huán)境，為開發(fā)者和系統(tǒng)管理員提供用于構(gòu)建，發(fā)布和運(yùn)行分布式應(yīng)用的平臺。

7、鏡像服務(wù)器

DevOps集成的鏡像服務(wù)器類型為Harbor。

Harbor是一個用于存儲和分發(fā)Docker鏡像的企業(yè)級Registry服務(wù)器，通過添加一些企業(yè)必需的功能特性，例如安全、標(biāo)識和管理等，擴(kuò)展了開源Docker Distribution。作為一個企業(yè)級私有Registry服務(wù)器，Harbor提供了更好的性能和安全。提升用戶使用Registry構(gòu)建和運(yùn)行環(huán)境傳輸鏡像的效率。Harbor支持安裝在多個Registry節(jié)點(diǎn)的鏡像資源復(fù)制，鏡像全部保存在私有Registry中，確保數(shù)據(jù)和知識產(chǎn)權(quán)在公司內(nèi)部網(wǎng)絡(luò)中管控。另外，Harbor也提供了高級的安全特性，諸如用戶管理，訪問控制和活動審計等。

8、代碼服務(wù)器

DevOps采用了Gitlab、Github和Svn作為代碼的管理工具，支撐起了平臺的代碼模塊，用戶的項(xiàng)目相關(guān)代碼都可以存儲在以上三種工具中并關(guān)連到DevOps平臺的相應(yīng)項(xiàng)目里，方便用戶查看對比代碼，也為后續(xù)的CICD提供了便利。

GitLab是由GitLabInc.開發(fā)，使用MIT許可證的基于網(wǎng)絡(luò)的Git倉庫管理工具，且具有wiki和issue跟蹤功能。使用Git作為代碼管理工具，并在此基礎(chǔ)上搭建起來的web服務(wù)。

GitHub是一個面向開源及私有軟件項(xiàng)目的托管平臺，因?yàn)橹恢С謌it 作為唯一的版本庫格式進(jìn)行托管，故名GitHub。

SVN是subversion的縮寫，是一個開放源代碼的版本控制系統(tǒng)，通過采用分支管理系統(tǒng)的高效管理，簡而言之就是用于多個人共同開發(fā)同一個項(xiàng)目，實(shí)現(xiàn)共享資源，實(shí)現(xiàn)最終集中式的管理。

9、文檔服務(wù)器

Confluence服務(wù)器的存在使得整個項(xiàng)目生產(chǎn)過程中的文檔有了一個集中存儲的地方，方便管理。

Confluence為團(tuán)隊提供一個協(xié)作環(huán)境。在這里，團(tuán)隊成員齊心協(xié)力，各擅其能，協(xié)同地編寫文檔和管理項(xiàng)目。從此打破不同團(tuán)隊、不同部門以及個人之間信息孤島的僵局，Confluence真正實(shí)現(xiàn)了組織資源共享。

2.DevOps平臺第三方服務(wù)集成思路

1、數(shù)據(jù)實(shí)體的對應(yīng)

DevOps平臺有屬于自己的模板，比如工作項(xiàng)模板、迭代模板等，這就要求在集成第三方服務(wù)的時候要將獲得的數(shù)據(jù)映射到DevOps模板中去再做展示，舉例說，DevOps平臺在集成Zentao作為項(xiàng)目管理工具的時候，有bug、story、task三張表，而DevOps平臺只有Workitem一張表，那么我們就要將3張表的數(shù)據(jù)想辦法轉(zhuǎn)換到1張表中，這個過程肯定會存在概念無法對應(yīng)的問題，解決思路要么就是用相近的概念替換，或者剔除掉多余的概念，總之，還是要以DevOps平臺的模板為主；

2、API接口的調(diào)用

有些時候，第三方服務(wù)提供出來的api接口難以操作，或者存在接口錯誤的情況，此時我們就要轉(zhuǎn)換思路，廢棄使用api接口改為直接操作數(shù)據(jù)也許是一個好的解決方案；

拿Gitlab來說，Gitlab至今已經(jīng)出了12版本，使用的api版本也已經(jīng)到了v4，若我們還是使用Gitlab8的v3版api調(diào)用Gitlab12的接口是會出現(xiàn)問題的。

3.DevOps平臺第三方服務(wù)集成示例

1、Gitlab集成

DevOps平臺集成Gitlab過程大體可以分為以上3個步驟，先要做的是了解Gitlab的api接口，看一下身份認(rèn)證方式是通過token還是session等，Gitlab的接口有很多我們是不需要的，此時我們就需要看DevOps模板需要哪些，不需要哪些，將需要的接口整理出來，并研究它們的QueryParam和Body的格式，驗(yàn)證接口是否可以正確調(diào)通，接口通了，我們得到了需要的數(shù)據(jù)，但是數(shù)據(jù)格式跟DevOps的模板不符，我們就要進(jìn)行最后一步，將所得數(shù)據(jù)映射到DevOps模板就大功告成了。

1 ）研究GitlabAPI接口

GitlabAPI接口我們可以直接從官網(wǎng)的相關(guān)文檔查閱，按照官方的說明，自GitLab 9.0起，API V4是首選使用的版本。2017年8月22日發(fā)布的GitLab 9.5不支持API V3。在GitLab 11.0中刪除了API v3 ，就是說11版本起Gitlab不再支持v3版本的api，所以我們在集成Gitlab的時候就要考慮集成兩個版本的API。

2 ）篩選DevOps平臺所需的接口

DevOps平臺集成Gitlab僅需要應(yīng)用到Gitlab的部分接口，如代碼庫的增刪改查，分支、標(biāo)簽的增刪改查等，過濾去無用的接口，并以查詢分支接口舉例。

可見，該請求的身份認(rèn)證方式是通過token實(shí)現(xiàn)的，返回的數(shù)據(jù)格式如圖顯示：

而DevOps代碼分支模板如下圖展示，所以要再做一次映射：

3 ）將返回數(shù)據(jù)填入DevOps模板并展示

此為集成成功后的Gitlab代碼庫在DevOps平臺中的展示界面，用戶可以在此查看代碼庫的文件內(nèi)容，分支、標(biāo)簽信息，也可以對比不同分支或標(biāo)簽的差異：

2、Zentao集成

因?yàn)閆entao的接口設(shè)計比較特殊，在使用它的api接口來實(shí)現(xiàn)集成時遇到了種種問題，故改用了直接操作Zentao數(shù)據(jù)庫來實(shí)現(xiàn)服務(wù)集成的方法。大體步驟是先研究Zentao的表結(jié)構(gòu)，然后與DevOps相應(yīng)表做對照，然后做DevOps服務(wù)端多數(shù)據(jù)源實(shí)現(xiàn)，直接從Zentao數(shù)據(jù)庫讀取數(shù)據(jù)，映射到DevOps的模板并展示給用戶。

1 ）研究Zentao表結(jié)構(gòu)&將Zentao表數(shù)據(jù)映射至DevOps模板

以Zentao的zt_story表舉例，如圖是禪道的需求表結(jié)構(gòu)：

下圖是DevOps工作項(xiàng)模板：

要想在DevOps平臺中展示Zentao的需求信息，還要做一次數(shù)據(jù)映射，集成時，需要先設(shè)計DevOps平臺的服務(wù)端多數(shù)據(jù)源實(shí)現(xiàn)，就是定義一個Zentao的Dao實(shí)現(xiàn)，同時，Zentao的數(shù)據(jù)庫需要用戶來配置，解決方案1：用戶可以在配置文件中配置Zentao的數(shù)據(jù)庫地址以及賬號密碼；解決方案2：用戶可以在服務(wù)集成處配置Zentao的數(shù)據(jù)庫信息；兩種方式的Dao層實(shí)現(xiàn)也是有差異的。下面展示方案1的ZentaoDao部分實(shí)現(xiàn)：

2 ）數(shù)據(jù)展示

成功集成后的任務(wù)模塊展示如圖，用戶可以在該界面進(jìn)行任務(wù)、需求、bug的增刪改查

4.總結(jié)

在集成一個第三方工具時，關(guān)注點(diǎn)無非就是如何調(diào)用API接口以及將得到的返回結(jié)果如何展示，除非API接口調(diào)用行不通，才會考慮做一個數(shù)據(jù)庫的集成，在做數(shù)據(jù)庫集成的時候還要小心再小心，如果存在關(guān)聯(lián)表情況，可能會導(dǎo)致第三方工具的某些功能無法使用，還有當(dāng)api接口訪問不成功時，首先要確認(rèn)請求的body是否符合該接口的規(guī)范，若body沒問題，再考慮一下api接口的版本是否跟第三方工具的版本匹配，總之，集成并不是一個很難的事情，只要思路明確，耐心細(xì)心，總會成功。