Gitlab CI 常規介紹 | Linux 中國

在 fleetster[1]， 我們搭建了自己的 Gitlab[2] 實體，而且我們大量使用了 Gitlab CI[3]。我們的設計師和測試人員也都在用它，也很喜歡用它，它的那些高階功能特別棒。

Gitlab CI 是一個功能非常強大的持續整合系統，有很多不同的功能，而且每次釋出都會增加新的功能。它的技術檔案也很豐富，但是對那些要在已經配置好的 Gitlab 上使用它的使用者來說，它缺乏一個一般性介紹。設計師或者測試人員是無需知道如何透過 Kubernetes 來實現自動伸縮，也無需知道“映象”和“服務”之間的不同的。

但是，他仍然需要知道什麼是“管道”，知道如何檢視部署到一個“環境”中的分支。因此，在本文中，我會盡可能改寫更多的功能，重點放在終端使用者應該如何使用它們上；在過去的幾個月裡，我向我們團隊中的某些人包括開發者講解了這些功能：不是所有人都知道持續整合Continuous Integration（CI）是個什麼東西，也不是所有人都用過 Gitlab CI。

如果你想瞭解為什麼持續整合那麼重要，我建議閱讀一下 這篇文章[4]，至於為什麼要選擇 Gitlab CI 呢，你可以去看看 Gitlab.com[3] 上的說明。

簡介

開發者儲存更改程式碼的動作叫做一次提交commit。然後他可以將這次提交推送push到 Gitlab 上，這樣可以其他開發者就可以複查review這些程式碼了。

Gitlab CI 配置好後，Gitlab 也能對這個提交做出一些處理。該處理的工作由一個執行器runner來執行的。所謂執行器基本上就是一臺伺服器（也可以是其他的東西，比如你的 PC 機，但我們可以簡單稱其為伺服器）。這臺伺服器執行 .gitlab-ci.yml 檔案中指令，並將執行結果傳回給 Gitlab 本身，然後在 Gitlab 的圖形化介面上顯示出來。

開發者完成一項新功能的開發或完成一個 bug 的修複後（這些動作通常包含了多次的提交），就可以發起一個合併請求merge request，團隊其他成員則可以在這個合併請求中對程式碼及其實現進行評論comment。

我們隨後會看到，由於 Gitlab CI 提供的兩大特性，環境environment 與 製品artifact，使得設計者和測試人員也能（而且真的需要）參與到這個過程中來，提供反饋以及改進意見。

管道pipeline

每個推送到 Gitlab 的提交都會產生一個與該提交關聯的管道pipeline。若一次推送包含了多個提交，則管道與最後那個提交相關聯。管道就是一個分成不同階段stage的作業job的集合。

同一階段的所有作業會併發執行（在有足夠執行器的前提下），而下一階段則只會在上一階段所有作業都執行並傳回成功後才會開始。

只要有一個作業失敗了，整個管道就失敗了。不過我們後面會看到，這其中有一個例外：若某個作業被標註成了手工執行，那麼即使失敗了也不會讓整個管道失敗。

階段則只是對批次的作業的一個邏輯上的劃分，若前一個階段執行失敗了，則後一個執行也沒什麼意義了。比如我們可能有一個構建build階段和一個部署deploy階段，在構建階段執行所有用於構建應用的作業，而在部署階段，會部署構建出來的應用程式。而部署一個構建失敗的東西是沒有什麼意義的，不是嗎？

同一階段的作業之間不能有依賴關係，但它們可以依賴於前一階段的作業執行結果。

讓我們來看一下 Gitlab 是如何展示階段與階段狀態的相關資訊的。

pipeline-overview

pipeline-status

作業job

作業就是執行器要執行的指令集合。你可以實時地看到作業的輸出結果，這樣開發者就能知道作業為什麼失敗了。

作業可以是自動執行的，也就是當推送提交後自動開始執行，也可以手工執行。手工作業必須由某個人手工觸發。手工作業也有其獨特的作用，比如，實現自動化部署，但只有在有人手工授權的情況下才能開始部署。這是限制哪些人可以執行作業的一種方式，這樣只有信賴的人才能進行部署，以繼續前面的實體。

作業也可以建構出製品artifacts來以供使用者下載，比如可以構建出一個 APK 讓你來下載，然後在你的裝置中進行測試; 透過這種方式，設計者和測試人員都可以下載應用併進行測試，而無需開發人員的幫助。

除了生成製品外，作業也可以部署環境，通常這個環境可以透過 URL 訪問，讓使用者來測試對應的提交。

做作業狀態與階段狀態是一樣的：實際上，階段的狀態就是繼承自作業的。

running-job

製品Artifacts

如前所述，作業能夠生成製品供使用者下載來測試。這個製品可以是任何東西，比如 Windows 上的應用程式，PC 生成的圖片，甚至 Android 上的 APK。

那麼，假設你是個設計師，被分配了一個合併請求：你需要驗證新設計的實現！

要該怎麼做呢？

你需要開啟該合併請求，下載這個製品，如下圖所示。

每個管道從所有作業中搜集所有的製品，而且一個作業中可以有多個製品。當你點選下載按鈕時，會有一個下拉框讓你選擇下載哪個製品。檢查之後你就可以評論這個合併請求了。

你也可以從沒有合併請求的管道中下載製品 😉

我之所以關註合併請求是因為通常這正是測試人員、設計師和相關人員開始工作的地方。

但是這並不意味著合併請求和管道就是綁死在一起的：雖然它們結合的很好，但兩者之間並沒有什麼關係。

download-artifacts

環境environment

類似的，作業可以將某些東西部署到外部伺服器上去，以便你可以透過合併請求本身訪問這些內容。

如你所見，環境environment有一個名字和一個連結。只需點選連結你就能夠轉至你的應用的部署版本上去了（當前，前提是配置是正確的）。

Gitlab 還有其他一些很酷的環境相關的特性，比如 監控monitoring[5]，你可以透過點選環境的名字來檢視。

environment

總結

這是對 Gitlab CI 中某些功能的一個簡單介紹：它非常強大，使用得當的話，可以讓整個團隊使用一個工具完成從計劃到部署的工具。由於每個月都會推出很多新功能，因此請時刻關註 Gitlab 部落格[6]。

若想知道如何對它進行設定或想瞭解它的高階功能，請參閱它的檔案[7]。

在 fleetster，我們不僅用它來跑測試，而且用它來自動生成各種版本的軟體，並自動釋出到測試環境中去。我們也自動化了其他工作（構建應用並將之釋出到 Play Store 中等其它工作）。

說起來，你是否想和我以及其他很多超棒的人一起在一個年輕而又富有活力的辦公室中工作呢？看看 fleetster 的這些招聘職位[8] 吧！

贊美 Gitlab 團隊 (和其他在空閑時間提供幫助的人)，他們的工作太棒了！

若對本文有任何問題或回饋，請給我發郵件：riccardo@rpadovani.com[9] 或者發推給我[10]：-) 你可以建議我增加內容，或者以更清晰的方式重寫內容(英文不是我的母語)。

那麼，再見吧，

R.

P.S：如果你覺得本文有用，而且希望我們寫出其他文章的話，請問您是否願意幫我買杯啤酒給我[11] 讓我進入 鮑爾默峰值[12]？

via: https://rpadovani.com/introduction-gitlab-ci

作者：Riccardo[14] 譯者：lujun9972 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出