1. 背景
在企業(yè)內(nèi)部大家?guī)缀醵际窃谑褂?code>gitlab來保存、自動(dòng)化部署項(xiàng)目，也青睞于將一個(gè)團(tuán)隊(duì)的關(guān)聯(lián)性高的項(xiàng)目都放到一個(gè)倉(cāng)庫(kù)下。與此同時(shí)，也會(huì)將項(xiàng)目的編譯、測(cè)試、構(gòu)建、發(fā)布都分別聚合在一個(gè)job中去做。初期項(xiàng)目只有2、3個(gè)的時(shí)候，還看不出來太大的變化，多等幾十秒對(duì)于大家來說也無所謂。隨著業(yè)務(wù)的發(fā)展項(xiàng)目會(huì)越來越多，在同一個(gè)工程下面我們也會(huì)構(gòu)建出越來越多的子項(xiàng)目來。子項(xiàng)目膨脹到10、20個(gè)時(shí)候，你會(huì)發(fā)現(xiàn)每個(gè)job的執(zhí)行時(shí)間都變的非常的長(zhǎng)，當(dāng)你想要發(fā)布一下項(xiàng)目看下效果的時(shí)候，你需要苦苦等待勁40分鐘，才能完全構(gòu)建完成。引用一句學(xué)習(xí)python時(shí)候，經(jīng)常看到的話，”人生苦短，我用python“。是的，太慢了。
2. 項(xiàng)目太多構(gòu)建速度太慢如何解決？
2.1 項(xiàng)目依然包含多個(gè)子項(xiàng)目
我們依然遵循了將所有的子項(xiàng)目都放到了一個(gè)工程下面。雖然這樣我們?cè)诒镜厝烤幾g的時(shí)候，依然很慢。但是他有一點(diǎn)好處就是，所有的項(xiàng)目都聚合在一起，維護(hù)起來非常方便。畢竟IntelliJ可以幫我們做增加編譯，所以，在平時(shí)開發(fā)上影響并不大。
當(dāng)然了，隨著微服務(wù)架構(gòu)在企業(yè)的推廣率越來越高，項(xiàng)目被切成了巨量的小項(xiàng)目，一個(gè)項(xiàng)目中維護(hù)著少量的子項(xiàng)目，可以讓這個(gè)項(xiàng)目在任何環(huán)節(jié)都非常快。
2.2 gitlab-ci文件的修改
將每個(gè)job都切分成子項(xiàng)目數(shù)量的job，并保證各個(gè)子項(xiàng)目的構(gòu)建過程互不影響，當(dāng)我想要發(fā)布其中某個(gè)項(xiàng)目的時(shí)候，只需要執(zhí)行該項(xiàng)目的pipeline流程就行了，并不需要關(guān)注其他子項(xiàng)目的pipeline流程。
這樣，我們又可以快速的發(fā)布其中某個(gè)項(xiàng)目啦。
我們將這些子項(xiàng)目都聚攏在一個(gè)項(xiàng)目中的好處是，當(dāng)我們需要全量發(fā)布項(xiàng)目的時(shí)候，我們可以輕松的發(fā)布掉他們。當(dāng)然，在微服務(wù)體系下，也沒這個(gè)需求:(
3. 項(xiàng)目需要很多下載很多依賴，但是這些依賴的下載過程過于漫長(zhǎng)，并且有的不在兼容，如何解決？
3.1 例子: python2.7
python2.7已經(jīng)不再維護(hù)，但是依賴鏈中卻有很多在不斷升級(jí)版本，并且不再兼容2.7
3.1.1 解決方案
- 將所有的依賴下載好環(huán)境構(gòu)建好后，將這個(gè)環(huán)境打入一個(gè)
docker image中，并上傳到鏡像倉(cāng)庫(kù)，命名為Base-xxx。 - 項(xiàng)目的本身的
Dockerfile直接依賴Base-xxx
3.1.2 如果需要添加新的依賴怎么辦？
方案一：重新構(gòu)建Base-xxx鏡像，并上傳至鏡像倉(cāng)庫(kù)（過程中，可以要解決依賴鏈上的不兼容問題）
方案二：基于Base-xxx鏡像，構(gòu)建一個(gè)新的鏡像來拉取額外的這個(gè)依賴，并且將額外的依賴打入一個(gè)新的鏡像中名為Base-V2-xxx（這種看起來比較惡心，但是可以避免處理原始依賴鏈上的不兼容問題）
