DevOps平臺之開源技術圖譜
引言：
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接口的版本是否跟第三方工具的版本匹配，總之，集成并不是一個很難的事情，只要思路明確，耐心細心，總會成功。
