DevOps落地實踐 BAT系列 CICD iPipe vs CCI
阿新 • • 發佈：2018-12-23
百度效率雲，將自身定位為研發工具的SaaS解決方面，三大看點程式碼託管/CICD/敏捷看板非常清晰，對應icode/ipipe/icafe三大自研工具。而騰訊的DevOps解決方案聚焦於程式碼託管/CICD/測試管理/運維監控/專案管理五大領域，具體則依託於騰雲TGit/CCI/COC/TAPD四大開發者工具。因為功能和做法較為相近，這篇文章中我們將會通過其官方的介紹來看一下CICD的具體做法和各自的亮點。
CCI持續整合
為開發者提供支援多種程式語言的編譯構建服務，包含定時/手動啟動構建、檢視構建結果及日誌、支援快速分發交付、可擴充套件的自動化測試等功能，為專案的持續整合體系提供上游基礎服務，提升專案研發效率。
Why CCI
| 優勢 | 詳細說明 |
|---|---|
| 接入門檻低 | 通過認證的騰訊雲帳號，CCI 可直接同步 TGit 的程式碼庫進行構建任務的建立；並提供了多臺標準編譯機，基礎構建任務無需進行編譯機購買及環境搭建工作。 |
| 配置靈活 | CCI 提供豐富的自定義編譯引數，滿足各種複雜編譯任務需求；支援接入私有編譯機，滿足使用者特殊編譯環境的任務需求；支援接入第三方程式碼源，可從 Github 或其他 SVN 程式碼源拉取程式碼完成構建。 |
| 流水線對接 | 在同步 TGit 程式碼的同時，CCI也能獲取到 TGit 的提交日誌，關聯變更與構建結果；可自動或手工將構建結果同步至織雲檔案管理模組，對構建結果進行版本管理，進而完成批量機器自動化部署工作。 |
| 可擴充套件性強 | 可配置定時觸發構建或程式碼提交觸發構建，快速迭代更新；構建下游提供開放介面，可接入各類自動化檢測工具（如程式碼靜態掃描、安裝包檢測），快速診斷程式碼問題，提升測試質量。 |
產品功能
| 功能 | 詳細說明 |
|---|---|
| 構建任務管理 | 靈活的構建任務配置，可針對不同專案配置一到多個構建任務，獨立產出構建結果。 |
| 編譯引數場景 | 系統支援預設構建引數，允許自定義配置構建引數及構建指令碼，滿足個性化構建需求。 |
| 編譯機管理 | 提供了多臺標準編譯機，支援接入私有編譯機，支援使用者特殊編譯環境的任務。 |
| 自動觸發機制 | 使用者可手動觸發構建以外，可定時或程式碼提交時觸發構建，滿足每日基線及實時基線結果訴求。 |
| 關聯提交行為 | CI可拉取tGit或其他程式碼源的提交日誌，為每次構建結果關聯上程式碼提交日誌，方便跟蹤程式碼提交產出。 |
| 無需人工介入 | 通過後臺的構建叢集，CI可保證編譯的安全及穩定；構建完成後通過各類通知方式進行結果同步，無需值守或干預。 |
| 程式碼託管 | 通過認證的騰訊雲帳號，CCI 可直接拉取同一個開發者（或企業）的 TGit 專案，降低專案接入開銷。 |
| 釋出部署 | CCI 結果可一鍵或自動將構建結果同步至織雲檔案管理模組，對構建結果進行版本管理，協助完成批量機器自動化部署工作。 |
iPipe:持續交付工具
Why iPipe
| 優勢 | 詳細說明 |
|---|---|
| 高效 | 分散式構建，併發不排隊;序列、並行、定時多種模式支援;自動日誌分析，快速定位異常 |
| 強大 | 整合多種應用測試服務，開箱即用;一鍵部署主流雲商;灰度釋出、A/B驗證多種部署支援;監控、反饋，實時瞭解系統執行情況 |
產品功能
- Check-in編譯
- 持續整合
- 產品倉庫
- 一鍵部署到雲端
- 移動應用測試
使用方式
以下一iPipe為例，簡單瞭解一下平臺如何使用。
iPipe + Jenkins
與Jenkins的整合方式，提供iPipe的Jenkins外掛：iPipe-Agent
在iPipe上建立job
自動化構建
程式碼評審
整體設定的yaml檔案
Image:
type : default
BeforeBuild:
script : ./before_build.sh
Build:
script : ./build.sh
AfterBuild:
script : ./after_build.sh
Package:
script : ./check_artifact.sh
artifacts:
name : waimai_fe
version : $COMMIT_ID-$BUILD_ID
files : [./ci.yml, ./build.sh]
格式說明
Image:
type : 指定編譯環境標籤, 必填欄位。預設標籤是default, 任何企業均可指定使用。企業還可以擁有專有的編譯環境標籤，專有標籤為企業專屬所有。
BeforeBuild: // 編譯前
script : 指定編譯前要執行指令碼, 可選欄位。該指令碼的路徑以程式碼根目錄為起始的相對路徑
Build: // 編譯中
script : 指定編譯階段要執行指令碼, 可選欄位。該指令碼的路徑以程式碼根目錄為起始的相對路徑
AfterBuild: // 編譯後
script : 指定編譯完成後要執行指令碼, 可選欄位。該指令碼的路徑以程式碼根目錄為起始的相對路徑
Package:
script : 指定將編譯結果打包時要執行指令碼, 可選欄位。該指令碼的路徑以程式碼根目錄為起始的相對路徑. 具體的打包動作由編譯系統自動完成，該指令碼不負責具體的打包工作。
artifacts:
name : 指定編譯結果壓縮包的名稱
version : 指定編譯結果壓縮包的版本，支援$COMMIT_ID, $BUILD_ID兩者的任意組合, 並用'-'連線. COMMMIT_ID 表示git 倉庫commit id, $BUILD_ID 表示構建ID.
支援格式: $BUILD_ID, $COMMIT_ID, $BUILD_ID-$COMMIT_ID, $COMMIT_ID-$BUILD_ID
files : 指定具體的產出檔案路徑，多個檔案逗號分割。每個路徑均以程式碼根路徑起始的相對路徑
情況說明:
name 和version 全部為空時，表示只編譯，不打包。
name 和version 只要有一個不為空，則進行打包操作。
version 欄位只支援$BUILD_ID, $COMMIT_ID兩個內建變數，必須以$開頭, 兩個都存在時必須以'-'連線，不支援其他符號進行連線
files 中多個檔案路徑必須以逗號分割, 不分割預設是一個檔案路徑- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
持續交付
總結
無論是百度還是騰訊，都很好的利用了自身的體量和平臺的優勢，使得雲平臺的使用者使用起來更加順暢，更能夠集中精力與業務開發。除了一鍵部署，而iPipe也明確的提出了持續部署中的灰度釋出和A/B驗證部署方式的支援。但是CI/CD可能遇到的情況非常複雜，比如雲和非雲，公有云和私有云的混合構成，然後多種程式語言，多種作業系統，不同的中介軟體，是否依然能夠支援，或者能夠支援到什麼程度，沒有得到詳細的驗證，如果自動編譯以Maven為中心的構成，則很有可能集中於java系的應用程式開發，具體在使用的時候這些都需要進一步的進行考察。
再分享一下我老師大神的人工智慧教程吧。零基礎！通俗易懂！風趣幽默！還帶黃段子！希望你也加入到我們人工智慧的隊伍中來！https://www.cnblogs.com/captainbed