本周，按照慣例Gitlab發布了新的月度版本12.5新版本。為了儘可能高效地交付高質量的軟體，企業需要跨多個雲支持廣泛的基礎架構，新版中對帶來了EKS集群和環境面板讓跨各種配置的項目配置，監視和管理變得更加容易。更多功能請隨蟲蟲一起學習。
主要功能
EKS集成
Kubernetes是絕對複雜的，從頭開始構建集群不是一件容易的事。儘管可以通過一些商業的雲廠商產品來降低這種門檻，比如可以使用AWS的Elastic Kubernetes服務（EKS）之類的託管服務來抽象一些複雜性，也要遵循許多步驟才能開始使用。繁瑣的手動步驟會分散我們的主要目標，使代碼無法實時運行。在GitLab 12.5中，新添加了對EKS集成。可以在GitLab集群頁面中選擇EKS作為選項，然後將提示進行身份驗證以使用AWS帳戶。一旦通過身份驗證，只需為集群指定所需的參數，GitLab將負責完成其餘的工作。
EKS集成不僅對讓用戶輕鬆地在AWS上部署到Kubernetes至關重要，也是多雲策略的一部分。GitLab的GKE集成旨在使Kubernetes的安裝更加容易，而且使多雲更加容易。GKE集成只是一個開始。更大願景是可以從各種雲廠商中可自由選擇，我們可以利用每個提供程序提供的獨特優勢並獲得可移植性，以將應用程式和工作負載移動到所選擇的雲中，並同GitLab保持相同的一致工作流。
該功能位於功能標記的後面，要在自建實例中手動啟用，啟動方法：
使用gitlab-rails console啟動Rails控制臺，並運行：
Feature.enable(:create_eks_clusters)
使用Crossplane設置多雲託管服務
Kubernetes應用程式現在可以與GitLab在一起部署，但是必須單獨配置，連接和保護雲服務依賴項。在GitLab 12.5中，可以使用開源的Crossplane項目以聲明方式提供雲服務，該項目擴展了Kubernetes API以提供託管服務，包括PostgreSQL，MySQL，Redis和對象存儲。
Crossplane現在可以作為GitLab託管應用程式使用，可以安裝到由GitLab管理的Kubernetes集群中。可以在標準的GitLab管道中或通過Auto DevOps使用kubectl聲明性地設置和使用GCP，AWS和Azure的託管服務。
通過配置Auto DevOps以使用Crossplane，用戶可以在集群外配置資料庫，從而提供可用於生產的設置。
環境面板（PREMIUM及以上）
面臨頻繁的生產環境應用程式更改，在變更流程中各種開發，暫存和生產環境時，對環境變化跟蹤是個問題。GitLab為此新增加了環境儀錶板可顯示該信息，從而提供對所有組和項目中環境狀態的單點訪問。這樣我們可以快速，直觀地識別並分類問題。
GitLab環境是一種邏輯結構，對代碼所處的物理環境的狀態和運行狀況的管理使GitLab成為真正的CD解決方案的功能之一，而不僅僅是協調部署的CI工具。
新的環境面板提供了一個基於跨項目的基於環境的視圖，可以用來大致了解每個環境中發生的事情。可以從一個面板跟蹤從開發到臨時驗證，再到生產（或通過設置的任何一系列自定義環境流）全程變更進度。在一個視圖了解多個項目，可以立即查看哪些管道是綠色的，哪些管道是紅色的，從而可以一眼確定在哪些步驟存在問題，或者用來研究更多系統性問題。通過環境儀錶板，可以使用這些附加工作流程來提高效率。
通過Sourcegraph支持代碼智能
在開發時，開發人員依靠定位定義和查找，但是這在審查代碼時並不可用。為此gitlab新版本對此做了增強，可以在瀏覽代碼或查看合併請求時使用Sourcegraph的強大代碼導航。
在GitLab 12.5中，當管理員配置了Sourcegraph集成後，便可以在用戶首選項中選擇使用。
將裡程碑與發布關聯
許多團隊使用GitLab的方式是要為所有內容所跟蹤的發行建立一個裡程碑。有些團隊可能還有一個以上的衝刺構成一個發布。新版本中可以將一個或者多個裡程碑與發行版相關聯。這樣可以在發布頁面中完成問題並合併版本發布所包含的請求。
更多功能介紹
組的審計事件API
審計事件API提供對GitLab環境的關鍵見解。之前該API僅管理員可用。先版本中已通過GitLab API訪問了組活動數據，判斷並並管理組的合規性。審計事件今後將會增強，使其更加全面，從而為提供更多見識和價值。
組、子組和項目概述的上下文導航
當開始通過其他組，子組和項目來組織組織時，很難確定所在層次結構中的位置。新版本中改進了左側導航窗格中的上下文概述項，因此可以快速確定查看的項目，組還是子組。
設計注釋添加到問題活動（PREMIUM及以上）
截止為止，當添加新的設計注釋/注釋時，注釋僅在設計中列出。在新版本中當添加新的注釋時，GitLab還將在討論選項卡上的問題活動中添加注釋，以便所有參與該問題的人都知道。這使得在設計討論中進行協作變得更加容易，因此每個人都可以為設計過程做出貢獻。
緩存Git信息/參考（Bata）
當獲取對Git存儲庫的更改時，Git伺服器會發布存儲庫中所有分支和標籤的列表。在某些情況下，觀察到對GitLab Web伺服器的所有請求中，多達75%是對引用的請求。在最好的情況下，當所有參考文件都打包時，這是一個相對便宜的操作。但是，當有解壓縮的引用時，Git必須遍歷解壓縮的引用。這會導致額外的磁碟IO，並且可能很昂貴，尤其是在使用諸如NFS的高延遲存儲時。
在GitLab 12.5中，實例管理員可以手動啟用信息/引用緩存以提高引用的性能，並減少引用非常頻繁獲取的情況下對Gitaly的壓力。
根據GitLab線上託管平臺的功能測試表明，當讀取操作數量多於進行10到1的寫操作，中值等待時間減少了70%。對於使用NFS進行Git存儲的GitLab實例，期望會有更大的改進。
默認情況下不啟用緩存，因為這會導致緩存上的寫入壓力高於預期，這可能是由於並行緩存未命中造成的。
合併請求API中添加了可合併性狀態
合併請求API現在包含有關合併請求為何無法合併的更多詳細信息。 has_conflicts屬性表示是否存在合併衝突，blocking_discussions_resolved屬性表示是否存在未解決的討論。這些新屬性對於自動化（確定合併請求可合併所需的操作）特別有用。
將查詢字符串中的值傳遞到"pipelines/new"頁面
要通過Web創建新管道，請轉到/pipelines/new，然後可以在其中為要啟動的管道填寫不同的值。已經可以添加ref參數來選擇分支或標記（例如/ pipelines / new?ref=master），新版本中還添加了類似功能，可以在查詢字符串中預設置其他變量。
gitlab-ci.yml中的可組合腳本別名
創建可重用的元構建基塊是管道設計的強大範例。可以讓項目保持DRY狀態，將功能劃分為可以理解的塊，並創建依賴鏈，以便一次更新代碼塊可以同時為許多依賴塊更新。
GitLab有幾種機制可以啟用此設計模式，包括默認的YAML語法，例如錨和別名。但是，但是當別名為script，before_script或after_script關鍵字時候，則在嘗試合併它們時會導致數組嵌套導致異常。
在GitLab 12.5中，通過對script錨點引用時會解包。如果想通過包含和擴展使用此模式，則無法使用，但是可以在單個文件中使用錨來解鎖一系列強大的新管道設計模式。
在合併請求中顯示JUnit錯誤詳細信息
在此版本之前，用戶可以看到測試何時失敗，但無法獲得解決失敗所需的數據。在新版本中，GitLab現在在管道視圖中顯示有關JUnit測試結果的數據。包括通過，跳過和失敗的測試結果以及時間安排，以及單個測試的詳細視圖，包括失敗測試的信息，以便更快地識別問題和解決問題。
幫助用戶下載NPM軟體包（PREMIUM及以上）
根據用戶調查用戶導航到Package Registry UI的主要原因是確保他們使用的是正確版本的軟體包。
在GitLab 12.5中，改進了GitLab Package Registry的導航和工作流程，用戶可以輕鬆複製npm install和npm setup片段，以輕鬆安裝所需的軟體包。
功能標記的公共API（PREMIUM及以上）
新版本中添加了API功能，該功能將允許配置和管理功能標誌。以前只能通過UI進行此操作。
基於CI的集群應用程式管理
一鍵安裝Kubernetes應用程式對於快速啟動和運行非常有用。但是，有時需要在安裝之前自定義Helm chart。新的基於CI的群集應用程式管理方法將允許用戶指定"群集管理項目"，該項目將獲得對群集的群集管理特權，並能夠通過CI與群集進行交互。這不僅將允許安裝模板化的應用程式，而且還允許用戶在安裝之前自定義圖表。此外，在管理Kubernetes應用程式時，用戶將能夠使用圍繞安全性，身份驗證，版本控制和CI的所有現有GitLab功能。
GitLab Serverless中的OpenFaas運行時支持
GitLab Serverless現在支持Open FaaS經典運行時。使用OpenFaas運行時，開發人員可以使用6種支持的語言中的任何一種為Knative編寫無伺服器功能。
使用Prometheus的恢復警報自動關閉問題（ULTIMATE）
解決之後，出於跟蹤目的，需要關閉事件問題，以便不會混淆哪些事件正在發生以及哪些事件仍需要修復。當由於某人已解決問題而解決警報時，Prometheus將發出恢復警報，使GitLab能夠自動關閉與事件相關的問題。這消除了事件響應者不必要的手動工作，並確保每個未解決的事件都是一個積極的問題，需要引起注意。
按標題過濾Sentry錯誤列表
分類錯誤需要能夠根據自定義和特定於您的用例的條件對列表進行過濾和排序。新版本中可以在與Sentry集成的GitLab項目中搜索Sentry錯誤列表。只需使用左側的欄導航至操作>錯誤跟蹤，即可在GitLab中查看Sentry錯誤並進行搜索。
Slack Slash命令添加要發布的注釋
ChatOps就是通過直觀的命令和操作來啟用操作，這些命令和操作可以鍵入併集成到聊天工具中。新版本中擴展了現有的Slack斜槓命令套件，該命令允許在不退出Slack的情況下為GitLab問題添加評論。這減少了上下文切換，並消除了僅導航多個UI來更新問題的隊友或利益相關者的麻煩。
編輯指標面板
此前，為了定義自定義儀錶板，用戶必須在存儲庫的根目錄下創建一個YAML文件，並從頭開始填寫其內容。這有點難以實現，需要手動操作。
在GitLab 12.5中，可通過單擊"編輯儀錶板"按鈕，將被重定向到Web IDE，在此可以更新修改預設的YAML文件。
適用於React框架的SAST（ULTIMATE）
新版本擴展了SAST Javascript掃描，以支持特定於React的文件和項目。
這可以幫助識別和修復React應用程式中的潛在漏洞。
Web應用程式防火牆的阻止模式（ULTIMATE）
新版本中將Web應用程式防火牆（WAF）置於阻止模式。只要WAF識別出潛在的惡意流量，就會將其丟棄，從而保護其免受各種不同的攻擊。
可以通過在項目中設置AUTO_DEVOPS_MODSECURITY_SEC_RULE_ENGINE環境變量來啟用此行為。如果未設置此變量，則WAF將在僅日誌記錄模式下運行。
脫機容器掃描（ULTIMATE）
對於自建GitLab實例，新版本中可以在脫機（空白）安裝中啟用容器掃描。這樣就可以進行容器掃描，而無需訪問Web。
Docker-in-Docker依賴性不再是依賴性掃描的要求（ULTIMATE）
以前，依賴關係掃描利用了Docker-in-Docker配置。通過刪除Docker-In-Docker要求，新版中不需要使用特權運行器，並且運行器現在可以緩存映像。消除對特權運行者的需求，可以更輕鬆地更安全地使用依賴關係掃描。
增強了Geo更新的彈性（PREMIUM及以上）
為了簡化Geo升級過程，新版本修復了Geo更新過程中更新外部數據包裝器（FDW）表時的一些小問題，並更新了相應的文檔。這樣系統管理員所需的人工幹預更少，這將增加Geo更新的整體健壯性。
有關使用Geo升級多節點/ HA部署的說明（PREMIUM及以上）
作為簡化Geo升級過程的一部分，新增加了Geo多節點/高可用性部署的零停機升級說明。
這些說明對於維護許多用戶的大型GitLab安裝的GitLab客戶特別有價值，因為它們消除了額外的停機時間。
檢查Geo節點僅顯示特定於節點的輸出（PREMIUM及以上）
在Geo主節點上運行gitlab-rake gitlab:geo:check時，展示了許多僅與輔助節點相關的信息。
在GitLab 12.5中清理了gitlab:geo:check輸出，僅運行與運行命令的節點類型（主要或次要）相關的檢查。
在雲原生安裝中支持Geo（PREMIUM及以上）
將代碼託管在的開發人員物理鄰近的位置，可以減小大型倉庫上的git clone的停頓時間。GitLab Geo提供了git倉庫的地理複製，因此可以讓開發人員在整個城市或全球範圍內進行協作。以前，Geo僅適用於Omnibus GitLab，而使用Kubernetes的人們則只能喝很多咖啡等待。因此，對GitLab chart的地理支持已成為人們高度要求的功能。
從12.5開始，GitLab Helm chart支持配置主要和輔助Geo實例。
更新以警告橫幅樣式
根據設計系統中的新規範，新版本中應用程式中更新了Alert組件。這些新樣式使警報banner文本易於閱讀，特別是在banner中包含連結的情況下。
使用ping中的額外項目服務計數
為了更好地了解用戶最常使用哪些集成，已將使用"自定義問題跟蹤器"，Jira，Jenkins，Slack和Mattermost項目服務的項目數量添加到使用ping有效負載中。隨著有效負載添加其他項目服務，該工作將在接下來的幾個版本中繼續進行。
關於GitLab Ping服務可以參考相關的官方語法。
GitLab Chart改進
GitLab 12.5中，添加了對在GitLab Helm圖表中配置外部Redis Sentinel伺服器的支持。現在，可以提供Redis HA集群中Sentinel伺服器的主機名，埠和密碼的列表，作為全局設置。請注意，僅與GitLabChart分開部署的Sentinel伺服器才支持此配置。
組裡程碑改善
在GitLab 12.5之前，如果將一個項目裡程碑提升為組，則會丟失許多項目裡程碑提供的有意義的元數據。現在，組裡程碑與項目裡程碑是同等的，並且包括問題概述，合併請求，參與者以及與該裡程碑相關的標籤。
AsciiDoc的顏色塊
AsciiDoc文件現在支持彩色塊。在支持AsciiDoc地方，比如Wiki，摘要和存儲庫文件預覽中，輸入的顏色代碼都將在其旁邊呈現一個有用的顏色塊。當設計師和工程師在GitLab中就顏色細節進行協作時，這特別有用。
合併後刪除源分支
很容易忘記從已合併的合併請求中刪除分支，從而導致分支數量迅速增加。在GitLab 12.5中，默認情況下會刪除功能分支以保持的項目整潔。
可以手動設置關閉該功能。在項目設置中添加了一個新的切換開關，以禁用"刪除源"分支選項。
使用稀疏籤出快速rebase
快進和半線性合併方法要求目標分支中沒有源分支中沒有的更改。當目標分支中的更改不在源分支中時，將顯示"Rebase"按鈕以使合併請求保持最新狀態。
當Git執行rebase時，將使用工作樹來完成操作。在GitLab 12.5中，在創建工作樹時會使用稀疏籤出，這樣用於執行變基的工作樹不包括存儲庫的完整工作副本，而僅包含幾個文件。
作業日誌默認擴展
默認情況下，將擴展作業日誌部分，以使日誌視圖更易於瀏覽，從而使您可以更快地找到失敗的作業所需的內容。
在合併請求視圖中顯示自定義構建結果
構建過程可能會生成工件，例如測試結果，代碼指標和統計信息，用戶希望以視覺表示的方式看到這些工件，但是這些項目在MR中尚不可用。以前，要訪問構建工件，需要導航到工件瀏覽器並離開MR的上下文。
在GitLab 12.5中已將自定義工件引入MR小部件的管道部分。使用gitlab-ci.yml中的Exposure_as關鍵字，現在可以在MR小部件中直接顯示工件。
提交SHA現在可以用作緩存鍵
GitLab CI/CD允許指定應在作業之間緩存的文件和目錄的列表。從緩存中拉出文件而不是從sratch構建文件是加快管道速度的好方法。但是，如果文件有新版本且緩存未更新，則緩存會很糟糕。在GitLab 12.5中，通過使用提交的SHA作為緩存鍵的新功能，緩存管理變得更加容易。由於這與生成文件的基礎來源相對應，因此這是一種確保緩存過期隨實際更改而變的自然方法。這將使管道中的緩存更易於設置並且效率更高。
使用CI/CD更新GitLab NPM註冊表（PREMIUM及以上）
在GitLab 12.5中，用戶可以利用GitLab CI/CD來構建軟體包並將其推送到項目或小組的NPM註冊中心。未來，用戶現在可以利用從.gitlab-ci.yml調用的作業令牌CI_JOB_TOKEN進行身份驗證並更新其NPM註冊表。
改進了GitLab容器註冊表的可用性
在GitLab 12.5中，發布了GitLab容器註冊表的更新版本修復了不支持MD5校驗的問題版本顯著提高了功能的可用性。
單獨部署GitLab Pages指南
可能需要在單獨的伺服器上運行GitLab Pages守護程序，以減少主應用程式伺服器上的負載。新版增加了該部署的指南來幫助完成此任務。
在本地構建無伺服器功能測試
了在本地運行測試，開發人員現在可以使用gitlabktl命令行工具構建其無伺服器功能。命令行工具gitlabktl已擴展為支持使用Kaniko或Docker Engine的本地構建。
JavaScript開發人員的新項目模板
藉助新的面向JavaScript的項目模板，可以開始使用GitLab Pages和AWS Lambda快速構建和發布項目。開始使用喜歡的框架對前端進行編碼，讓Serverless和AWS Lambda滿足後端需求，並使用GitLab頁面以1分鐘的設置來託管您的解決方案。
使用Grafana URL在GitLab問題中渲染圖表
當團隊對問題進行分類和解決時，指標圖表可讓我們了解服務/系統的哪些部分受到影響以及影響了那些用戶，並將此信息發送給有關人員。但是，使用複製和粘貼將屏幕快照從Grafana手動移至GitLab問題時很容易出錯，還影響速度。
在GitLab 12.5中，增加了通過GitLab圖表在問題中呈現Grafana指標的功能，只需在問題描述中包括Grafana圖表的URL。可以手動添加，也可以通過將URL添加到問題模板來自動呈現在問題中。
在GitLab中查看重要的Sentry錯誤細節
上下文切換使每個人的速度變慢。不同工具的獨特UI和交互模式使日常分類任務變得繁瑣。為了克服這些挑戰，Sentry的集成中新增加了從GitLab中查看錯誤詳細信息的功能。
這使可以查看錯誤的相關方面，例如首次/最後一次看到，事件數，受影響的用戶數以及GitLab中的堆棧跟蹤，而無需切換到Sentry。當然，如果需要更深入地了解，需要通過點擊連結到Sentry的錯誤記錄。
指標面板的異常圖表
在可視化指標時，用戶通常喜歡為不同的指標選擇不同的可視化類型，並設置上限和下限以更好地發現圖表中的異常。
為了幫助實現這一目標，新版本中添加了異常圖表，以此來增強圍繞監控的儀錶板產品。
Omnibus的改進
GitLab 12.5中，Mattermost更新到了5.16，它是開源的Slack替代產品，其最新版本包括新的Plugin Marketplace，在桌面上的更快安裝等。此版本的Mattermost刪除了對IE 11的支持。 GitLab現在包括一個新的Mattermost插件，該插件可將GitLab通知和slash命令到Mattermost。
升級Omnibus GitLab時，/etc/gitlab現在會自動備份。這樣可以確保GitLab配置數據包含在升級前的備份中。如果升級期間由於某種原因備份配置數據失敗，會發出警告，但升級將繼續。
GitLab高可用性使用Consul管理PosgreSQL資料庫節點的服務發現，運行狀況檢查和故障轉移。在12.5中，Omnibus內置的Consul版本已從0.9.0更新到1.6.1。
默認情況下在Omnibus中啟用了GitLab容器註冊表。通過確保可以在構建階段將容器上傳到容器註冊表，而無需進行配置更改，這為構建和使用容器提供了一條更快捷的途徑。
GitLab Runner 12.5
GitLab還同期發布了GitLab Runner 12.5。改進包括：
Document GitLab的Docker Machine fork；
提供DOCKER_MACHINE_VERSION；
升級到Alpine Linux 3.10；
針對K3/容器的修復；
更改鎖定配置以創建單獨的鎖定文件
修復Linux卷的綁定；
可能尚未保留在磁碟上的計算機計算機列表；
在配置中為Kubernetes執行程序添加服務定義；
詳情可以查看GitLab Runner的CHANGELOG。
性能改善
GitLab 12.5中提供的一些性能改進包括：
將IP列入白名單時，跳過Redis請求；
從頭像請求中刪除不必要的SQL查詢；
SQL語句在確定要同步的Ci::JobArtifact記錄時超時設置；
使用批處理加載器加載GraphQL中的重大問題；
以及文本前面提到的一些緩存功能的改善。
功能棄用
在GitLab 12.6中將刪除對Knative版本0.5的支持
隨著對Knative 1.0的支持，在GitLab 12.6中將放棄對Knative 0.5的支持。
去除日期：2019年11月22日
不再對openSUSE Leap 15.0支持
openSUSE 15.0將於2019年11月結束生命周期。在GitLab 12.5中將不再支持openSUSE 15.0。 openSUSE Leap 15.1的軟體包現在可用。
變更日期：GitLab 12.5
GitLab 13.0將棄用PostgreSQL 9.6和10.x
為了利用PostgreSQL 11中改進的性能和功能（例如分區），計劃在GitLab 13.x中僅支持PostgreSQL 11和12版本。
通過最低要求PostgreSQL 11，能夠利用引入的新功能，而無需維護多個代碼路徑的開銷。未來將保持每年一次的PostgreSQL升級節奏，並在支持第二和第三最新版本後立即對其進行支持。
變更日期：GitLab 13.0
通過API請求組詳細信息時限制返回的項目
當通過GET或PUT請求返回組的詳細信息時，GitLab的API響應先前會返回組項目的完整列表，有時會導致大量的Gitaly調用。在GitLab 12.6中，計劃將返回的項目數限制為100，以提高服務這些請求時的性能。
生效日期：2019年12月22日
不再支持Elasticsearch 5.6
隨著持續改進和增強與Elasticsearch的集成，GitLab 12.7的發布將結束對Elasticsearch 5.6.x的支持。隨著Elasticsearch 7.x的發布，Elasticsearch 5.6達到了使用壽命。 GitLab 12.7的更新版本不再對Elasticsearch 6.x的提供支持。
變更日期：2020年1月22日
升級更新
Omnibus封裝自建的GitLab實例，可以使用發行版的包管理器一鍵升級。
CentOS下可以直接通過下面的命令：
yum updata/install gitlab-ce
有關升級到GitLab 12.5的重要說明
Omnibus GitLab中的Consul版本從GitLab 12.5中的0.9.0更新為1.6.1。在高可用性群集中升級Consul節點時，必須一次升級Consul節點一個節點。捆綁的Consul的升級中記錄了升級過程。