Gitlab CI 是一個功能非常強大的持續(xù)集成系統(tǒng)，有很多不同的功能，而且每次發(fā)布都會增加新的功能。它的技術文檔也很豐富，但是對那些要在已經(jīng)配置好的 Gitlab 上使用它的用戶來說，它缺乏一個一般性介紹。設計師或者測試人員是無需知道如何通過 Kubernetes 來實現(xiàn)自動伸縮，也無需知道“鏡像”和“服務”之間的不同的。

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

但是，他仍然需要知道什么是“管道”，知道如何查看部署到一個“環(huán)境”中的分支。因此，在本文中，我會盡可能覆蓋更多的功能，重點放在最終用戶應該如何使用它們上；在過去的幾個月里，我向我們團隊中的某些人包括開發(fā)者講解了這些功能：不是所有人都知道持續(xù)集成(Continuous Integration)（CI）是個什么東西，也不是所有人都用過 Gitlab CI。

如果你想了解為什么持續(xù)集成那么重要，我建議閱讀一下 這篇文章，至于為什么要選擇 Gitlab CI 呢，你可以去看看 Gitlab.com 上的說明。

簡介

開發(fā)者保存更改代碼的動作叫做一次提交(commit)。然后他可以將這次提交推送(push)到 Gitlab 上，這樣可以其他開發(fā)者就可以復查(review)這些代碼了。

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

開發(fā)者完成一項新功能的開發(fā)或完成一個 bug 的修復后（這些動作通常包含了多次的提交），就可以發(fā)起一個合并請求(merge request)，團隊其他成員則可以在這個合并請求中對代碼及其實現(xiàn)進行評論(comment)。

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

管道(pipeline)

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

同一階段的所有作業(yè)會并發(fā)執(zhí)行（在有足夠運行器的前提下），而下一階段則只會在上一階段所有作業(yè)都運行并返回成功后才會開始。

只要有一個作業(yè)失敗了，整個管道就失敗了。不過我們后面會看到，這其中有一個例外：若某個作業(yè)被標注成了手工運行，那么即使失敗了也不會讓整個管道失敗。

階段則只是對批量的作業(yè)的一個邏輯上的劃分，若前一個階段執(zhí)行失敗了，則后一個執(zhí)行也沒什么意義了。比如我們可能有一個構建(build)階段和一個部署(deploy)階段，在構建階段運行所有用于構建應用的作業(yè)，而在部署階段，會部署構建出來的應用程序。而部署一個構建失敗的東西是沒有什么意義的，不是嗎？

同一階段的作業(yè)之間不能有依賴關系，但它們可以依賴于前一階段的作業(yè)運行結果。

讓我們來看一下 Gitlab 是如何展示階段與階段狀態(tài)的相關信息的。

Gitlab CI 基礎知識Gitlab CI 基礎知識

pipeline-overview

pipeline-status

作業(yè)(job)

作業(yè)就是運行器要執(zhí)行的指令集合。你可以實時地看到作業(yè)的輸出結果，這樣開發(fā)者就能知道作業(yè)為什么失敗了。

作業(yè)可以是自動執(zhí)行的，也就是當推送提交后自動開始執(zhí)行，也可以手工執(zhí)行。手工作業(yè)必須由某個人手工觸發(fā)。手工作業(yè)也有其獨特的作用，比如，實現(xiàn)自動化部署，但只有在有人手工授權的情況下才能開始部署。這是限制哪些人可以運行作業(yè)的一種方式，這樣只有信賴的人才能進行部署，以繼續(xù)前面的實例。

作業(yè)也可以建構出制品(artifacts)來以供用戶下載，比如可以構建出一個 APK 讓你來下載，然后在你的設備中進行測試; 通過這種方式，設計者和測試人員都可以下載應用并進行測試，而無需開發(fā)人員的幫助。

除了生成制品外，作業(yè)也可以部署環(huán)境，通常這個環(huán)境可以通過 URL 訪問，讓用戶來測試對應的提交。

做作業(yè)狀態(tài)與階段狀態(tài)是一樣的：實際上，階段的狀態(tài)就是繼承自作業(yè)的。

running-job

制品(Artifacts)

如前所述，作業(yè)能夠生成制品供用戶下載來測試。這個制品可以是任何東西，比如 Windows 上的應用程序，PC 生成的圖片，甚至 Android 上的 APK。

那么，假設你是個設計師，被分配了一個合并請求：你需要驗證新設計的實現(xiàn)！

要該怎么做呢？

你需要打開該合并請求，下載這個制品，如下圖所示。

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

你也可以從沒有合并請求的管道中下載制品

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

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

download-artifacts

環(huán)境(environment)

類似的，作業(yè)可以將某些東西部署到外部服務器上去，以便你可以通過合并請求本身訪問這些內容。

如你所見，環(huán)境(environment)有一個名字和一個鏈接。只需點擊鏈接你就能夠轉至你的應用的部署版本上去了（當前，前提是配置是正確的）。

Gitlab 還有其他一些很酷的環(huán)境相關的特性，比如 監(jiān)控(monitoring)，你可以通過點擊環(huán)境的名字來查看。

本文標題：簡單介紹一下GitlabCI
鏈接URL：http://uogjgqi.cn/article/djgjcii.html