Gitlab CI是什么意思

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

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

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

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

簡(jiǎn)介

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

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

開(kāi)發(fā)者完成一項(xiàng)新功能的開(kāi)發(fā)或完成一個(gè) bug 的修復(fù)后（這些動(dòng)作通常包含了多次的提交），就可以發(fā)起一個(gè)合并請(qǐng)求(merge request)，團(tuán)隊(duì)其他成員則可以在這個(gè)合并請(qǐng)求中對(duì)代碼及其實(shí)現(xiàn)進(jìn)行評(píng)論(comment)。

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

管道(pipeline)

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

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

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

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

同一階段的作業(yè)之間不能有依賴(lài)關(guān)系，但它們可以依賴(lài)于前一階段的作業(yè)運(yùn)行結(jié)果。

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

pipeline-overview

pipeline-status

作業(yè)(job)

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

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

作業(yè)也可以建構(gòu)出制品(artifacts)來(lái)以供用戶下載，比如可以構(gòu)建出一個(gè) APK 讓你來(lái)下載，然后在你的設(shè)備中進(jìn)行測(cè)試; 通過(guò)這種方式，設(shè)計(jì)者和測(cè)試人員都可以下載應(yīng)用并進(jìn)行測(cè)試，而無(wú)需開(kāi)發(fā)人員的幫助。

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

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

running-job

制品(Artifacts)

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

那么，假設(shè)你是個(gè)設(shè)計(jì)師，被分配了一個(gè)合并請(qǐng)求：你需要驗(yàn)證新設(shè)計(jì)的實(shí)現(xiàn)！

要該怎么做呢？

你需要打開(kāi)該合并請(qǐng)求，下載這個(gè)制品，如下圖所示。

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

你也可以從沒(méi)有合并請(qǐng)求的管道中下載制品 ????

我之所以關(guān)注合并請(qǐng)求是因?yàn)橥ǔ＿@正是測(cè)試人員、設(shè)計(jì)師和相關(guān)人員開(kāi)始工作的地方。

但是這并不意味著合并請(qǐng)求和管道就是綁死在一起的：雖然它們結(jié)合的很好，但兩者之間并沒(méi)有什么關(guān)系。

download-artifacts

環(huán)境(environment)

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

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

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