GitLab 12.10 新增加AWS CI自動擴展、需求管理、Jira問題導入等

按照日常慣例，GitLab 官方博客宣佈了新月度版本12.10的發佈。該次升級主要在安全合、CI加速、高效項目管理方面做了改善。請跟著蟲蟲一切來學習該版本的功能。

概述

合規更容易

在大多數大型組織中，合規性是一個常見的挑戰，團隊和項目需要證明他們遵循組織的流程和程序並交付了實際"需要"的內容。項目是否真正滿足了業務需求是一個普遍的問題，從12.10開始， GitLab中將需求管理作為一個單獨的類別進行交付，幫助團隊定義，跟蹤和管理業務需求。另外，GitLab 12.10中加強了項目和發佈合規性證據證明，不再需要使用腳本對比發佈證據隨時間的推移，項目"合規性"證明。新的項目合規框架標籤使組織可以輕鬆地指出需要特定項目才能符合特定合規性框架。

關於合規性框架，為了幫助需要進行HIPAA審核和合規性的項目，新的HIPAA審核協議項目模板為他們提供了一個良好的開端。通過改進的HashiCorp Vault集成，有助於項目的安全策略合規。

減少週期時間並加快AWS交付

隨著持續集成，CI執行可能會成為一個瓶頸，會減慢交付速度。所以，很長一段時間內一直支持自動縮放GitLab CI的運行。在GitLab 12.10中，Gitlab將AWS Fargate的自動擴展功能擴展到自動擴展運行器，可以有效擴展以滿足需求。可以使用預定義的AWS部署變量將應用程序配置為部署到AWS上，變得更快，更輕鬆，GitLab在其中添加了AWS部署變量，還有助於進行格式驗證。

高效管理項目

管理多個項目和相關問題可能很難。對於很多跟蹤信息，很難知道哪裡可能存在問題。在GitLab 12.10中，團隊可以輕鬆跟蹤和共享問題的健康狀況，從而可以輕鬆的從可視化Epic整體健康狀況。另外新增加將問題從Jira導入到GitLab的功能，使團隊可以花費更少的時間在工具之間進行切換，而將更多的時間集中在構建出色的軟件上。

GitLab 12.10主要功能改進

在GitLab中創建和查看需求（ULTIMATE）

GitLab中新增加了需求管理功能，在第一版的功能中只支持用戶創建和查看項目級的需求。

開發團隊中常見的一個問題與外部需求管理工具、多個工具鏈和工作流的協調和集成。通過提供將所有需求，設計，代碼和測試在一棧環境中實現可以減少這樣的困惑。的機會，我們相信單個應用程序的強大功能。GitLab推出需求管理功能，將逐漸實現對所有工作流的整合和每個工作的可追溯性，通過創建一個無縫的工作流以直觀地展示完整性和合規性。

和HashiCorp Vault集成

在新版本中，GitLab添加了對輕量級JSON Web令牌（JWT）身份驗證的支持，實現與現有的HashiCorp Vault集成，可以利用HashiCorp的JWT身份驗證方法無縫地為CI/CD作業提供認證憑據，而不用在GitLab中手動密碼變量。

Epic和問題健康跟蹤（ULTIMATE）

跨多個組和項目管理多個Epic是困難的。為了幫助用戶跟蹤項目和進行中的工作，新版本中通過對Epic樹著色，上顯示紅色、琥珀色或綠色的健康狀況來報告並快速響應單個問題和Epic的健康狀況。將問題的健康狀態分配為"正常"（綠色），"需要關注"（琥珀色）或"有風險"（紅色），並在Epic級別查看健康狀況的彙總報告。

Jira問題導入

此前將Jira問題引入GitLab的唯一方法是手動導入，要用CSV導入器或手動執行遷移實用程序。GitLab 12.10新增加了一個MVC，可自動將Jira問題導入GitLab。可實現從Jira到GitLab的無縫導入：

在的GitLab項目上設置Jira集成，單擊項目的Issue List頂部的import圖標，然後選擇Import From Jira。

在AWS Fargate上自動縮放GitLab CI作業

GitLab Runner自動擴展功能通過配置新的雲託管虛擬機來響應CI作業需求。儘管這種自動上下虛擬機實例的模型對於特定用例已經足夠，但客戶還希望利用雲容器編排解決方案的功能來執行GitLab CI/CD作業。新版本中可以使用GitLab的AWS Fargate Driver MVC版本在AWS Fargate上自動縮放GitLab CI。

藉助這種新的自動縮放模式，GitLab的AWS Fargate驅動程序使用用戶定義的容器鏡像在Amazon彈性容器服務（ECS）上的單獨且隔離的容器中自動運行每個構建。

易於配置AWS部署變量

在部署到AWS時，應儘可能方便地應用必要的環境變量。新版本中可以從環境變量鍵列表中使用"WS_ACCESS_KEY_ID"，"AWS_SECRET_ACCESS_KEY"和"AWS_DEFAULT_REGION"的選擇預定義變量。還有一些輸入的經過驗證的變量，以確保以有效格式輸入它們。

在版本發行中鏈接運行手冊和資產

發佈和構建通常需要在GitLab之外進行多項活動，以有效地發佈版本。GitLab致力於使"發佈"頁面成為有關發佈的所有內容的唯一真實來源。新版本中添加了將運行手冊鏈接到發行版資產的功能，現在可以輕鬆地跟蹤所有這些相關活動，並瞭解目前的進度。

GitLab狀態頁（ULTIMATE）

當服務中斷或降級時，最重要的是要對其進行修復。同時，必須向客戶和業務干係人更新修復進度。用戶依靠狀態頁來確認提供者是否瞭解問題並瞭解如何做。當發生突發事件時，知道當前正在採取的步驟可以激發信心。它可以幫助人們選擇應對事件的方式。

在新版本中，新增加了GitLab狀態頁

首先顯示的是GitLab實例上專用事件管理項目中的問題的信息，並將其發佈到公共狀態詳細信息頁面。更多信息以後會陸續擴展和增加。

構建、發佈和共享Python軟件包到GitLab PyPI倉庫庫（PREMIUM及以上）

Python開發人員需要一種機制來創建，共享和使用包含使用這些軟件包的項目中包含已編譯代碼和其他內容的軟件包。PyPI是一個由Python Packaging Authority維護的開源項目，他用來定義、創建、託管和使用Python軟件包標準。

在GitLab 12.10中，提供了內建的PyPI倉庫庫。開發人員可以直接在GitLab發佈Python軟件包。通過與PyPI集成，GitLab將提供一個集中的位置，以在與源代碼和管道相同的位置存儲和查看這些軟件包。GitLab PyPI倉庫庫以及對其他軟件包管理器格式的支持將移至開源。

組級活動概述MVC（STARTER及以上）

開發主管和GitLab管理員通常希望瞭解其團隊中如何使用GitLab。在該MVC中，在組登錄頁面上看到三個計數：在過去90天內，合併請求，問題和添加到該組的用戶數。該功能當前以Beta版本發佈。

首先按最新活動查看問題和MR提要

問題是GitLab中進行協作的主要工具之一。從最早到最新的討論和系統註釋的默認順序對於某些用例（例如瞭解給定問題的歷史記錄）非常有用。但是，當團隊處於分類和故障修復模式時，該顯示順序顯然不太適合，因為需要滾動到問題末尾才能查看最新更新。

最新版本中支持可以顛倒默認順序，並與活動Feed互動，頂部的是最新項。 問題和 MR的首選項通過本地存儲分別保存，並自動應用於查看的每個問題和MR。

設計縮略圖（PREMIUM及以上）

上傳到問題的設計的文件大小可能非常大。加載這些文件可能需要很長時間，尤其是在一個Issue中有多個設計時。在新版本中，現在會自動生成"設計"縮略圖，並使用它們來縮短"設計"選項卡的加載時間。隨著我們繼續構建設計管理功能，這還將使我們能夠縮短在GitLab其他部分中的設計加載時間。

通過在GitLab官網測試，對一個2.6MB樣圖主頁，分辨率為1222px x 5113px，生成縮略圖圖後，大小僅僅為0.018MB，為原來的千分之一。

文件擴展名的倉庫文件小圖標

查看存儲庫中的文件時，GitLab現在會基於文件擴展名顯示一個圖標。不同的文件類型使用不同顏色和形狀的圖標實現文件列表類型的快速識別。

該改進還統一了倉庫視圖，Web IDE和合並請求中文件樹之間的圖標樣式保持一致。

使用GitLab Pages託管靜態網站是網站發佈運行的最簡便方法。但是，編輯發佈靜態站點的內容通常需要設置複雜的本地開發環境，對基礎項目體系結構的理解以及對Markdown語法的熟悉。對大多數人來說，這是一個障礙。

GitLab新版本中，提供了一個新的項目模板，該模板創建一個靜態網站，最初支持Middleman，該網站預先配置為可託管在GitLab頁面上，並具有可以在新的簡化的"靜態站點編輯器"中進行編輯的內容。部署網站後，只需單擊每個頁面上可見的"編輯此頁面"鏈接，這將啟動新編輯器，該編輯器將刪除多餘的界面，並完全專注於頁面內容。完成後，只需單擊一下即可生成一個新分支和一個合併請求以進行更改。

使用Deploy令牌讀取和寫入GitLab軟件包到容器註冊表

部署令牌使可以訪問組和項目的存儲庫以及容器註冊表。但是，已定義的範圍read_repository不允許向GitLab容器註冊表授予推送訪問權限。結果，DevOps團隊常使用不安全或昂貴的基於用戶的解決方法。

在GitLab 12.10中，GitLab部署令牌支持更精細的權限。可以為Container Registry設置讀取或寫入訪問權限。可以從GitLab應用程序中或使用API創建和管理Deploy Token。

在組級別查看Container Registry中的Docker鏡像

使用GitLab容器註冊表時，擁有所有Docker鏡像的跨項目視圖非常重要。直到最近，用戶界面僅在項目級別可用。這種低效的工作流程導致團隊之間缺乏協作和Docker鏡像共享。

在12.10中，現在可以在GitLab應用程序中查看小組的所有圖像。現在，可以在一個地方共享，發現和管理所有圖像。

獨立的ECS任務創建

作為Cloud Deploy Docker鏡像的一部分，Gitlab捆綁了一個腳本，可以在管道中利用該腳本來簡化ECS部署的任務創建。這可幫助在部署作業中移動模版代碼，並簡化CI/CD配置。

GitLab UI刪除環境

在GitLab UI中而不是API管理環境非常有必要。將環境管理擴展到UI可以節省時間，並支持用戶在GitLab前端中度過一天。

自定義指標

瞭解系統性能通常始於監視傳達有關組件的運行狀況和性能的指標。每個開發團隊都需要這些功能，我們希望我們的指標解決方案可廣泛提供給所有使用GitLab新版本中監控階段的自定義指標從GitLab Ultimate遷移到GitLab Core全面免費。從GitLab 12.10開始，所有用戶都可以在GitLab UI中使用Prometheus添加和顯示他們收集的任何度量。

可用的Sidekiq群集

Sidekiq Cluster允許啟動其他Sidekiq進程來運行後臺作業，並提供方便的選項來選擇要處理的一組特定的作業隊列。這些選項可以改進Sidekiq隊列的管理，並可以繼續擴展大型實例。

此功能需要在STARTER及更高版本中可用。作為2020年禮物的一部分，從GitLab 12.10開始，現在在Core中免費可用，在GitLab 13.0開始默認啟用它。

GitLab告警

監控和觀察系統及應用程序性能的關鍵部分時候發出告警，該告警可在發生問題時發出。沒有告警，就無法關閉DevOps循環並有效地響應已突破關鍵閾值的服務。作為2020年禮物的一部分，Gitlab監控告警從GitLab Ultimate移至GitLab Core全面免費。從GitLab 12.10開始，所有用戶都可以從指標儀表板上的圖表創建IT警報，並通過通用REST端點在GitLab中接收警報。

摺疊問題中展開的圖表

解決事件時，直接嵌入到問題中的圖表可以通過在一個位置顯示所有信息而不是強迫在多個位置之間跳動來節省的時間。但是，如果只想閱讀文本並快速使用信息，則圖表可能會令人沮喪。新版本中，可以摺疊和展開圖表，並在查看圖表或將其從視圖中刪除之間進行選擇。

使用條形圖顯示指標

在監控儀表板上添加了條形圖作為新的可視化選項，以幫助以所需的方式顯示指標。

開箱即用的NGINX警報，可在Auto DevOps中進行自動監控

自動監視是Auto DevOps的功能，Auto DevOps是一種預定義的CI/CD配置，使可以自動檢測，構建，測試，部署和監視應用程序。

自動監視使可以在部署應用程序後立即監視應用程序的服務器和響應指標。自動監控使用Prometheus直接從Kubernetes中顯示系統指標，例如CPU和內存使用情況，以及從NGINX Server顯示響應指標，例如HTTP錯誤率，延遲和吞吐量。儘管聽起來需要進行大量配置，新版本中為NGINX吞吐量和HTTP錯誤率指標添加了開箱即用的警報，可在使用後立即使用它們，從而減少了查看指標和執行警報所需的配置為Auto DevOps設置自動監視。

指標圖表URL的時間範圍

現在，在查看度量標準圖表時，更新時間範圍將更新圖表的URL，從而使可以輕鬆共享或標記指向特定時間範圍的鏈接。

Geo將對未同步存儲庫的HTTP（S）請求重定向到主節點（PREMIUM及以上）

Geo支持 項目的選擇性同步，這使系統管理員可以選擇要複製到輔助Geo節點的數據子集。到目前為止，嘗試訪問未同步的輔助節點上的存儲庫的用戶將收到一個錯誤，指出該項目不可用。這可能是由於選擇性同步或由於複製滯後。這使用戶感到困惑，並打亂了他們的Git工作流程。

在GitLab 12.10中，任何通過HTTP（S）向未同步的輔助Geo節點發出的Git請求都將轉發到主要節點，以便用戶仍然可以訪問存儲庫。這樣用戶將不需要知道重複的內容或不重複的內容-Geo將嘗試滿足請求。在GitLab 13.0中將提供對代理SSH Git操作的支持。

在全局搜索結果中代碼高亮

長期以來，GitLab中的全局搜索能夠為執行的搜索返回代碼結果。但是，對於用戶來說，尚不清楚他們的搜索查詢在返回結果中的實際位置。這樣用戶必須在結果中尋找這一點，並且可能錯過了可能已多次返回字符串的重要結果。

現在，將會將高亮顯示搜索到的每一行，以更好地指示搜索項在結果中的匹配位置。

使用Puma減少GitLab的內存消耗

GitLab正在將應用服務器從Unicorn切換到Puma，從而將GitLab的內存佔用量減少了40%。效率的提高可以使GitLab管理員利用較小的內存實例，從而降低服務的運營成本。與Unicorn的單線程模型相比，通過利用Puma中的多線程支持實現了這些節省。Puma支持通常在Omnibus中可用，而Helm中是實驗性的。計劃使Puma成為GitLab 13.0中的默認應用程序服務器。

用戶統計數據得到改善

"用戶統計信息"頁面為管理員提供了按角色劃分的用戶帳戶的概述，以及所有用戶，活動用戶和被阻止用戶的總數。GitLab計費基於活動用戶數。

使用複製和粘貼將圖像上傳到"設計"選項卡

使用新的"複製和粘貼"功能，現在可以將剪貼板歷史記錄頂部的一個圖像作為.png文件直接粘貼到"設計"選項卡中。此功能對於在任何問題中快速共享剪貼板中的屏幕截圖特別有用。

跟蹤Wiki活動

到GitLab 12.9為止，當貢獻Wiki內容時，它不會影響在GitLab中的活動。在新版本中，將在項目，組和用戶活動頁面上看到所有Wiki貢獻。現在，可以跟蹤Wiki的更改。

緩存Git信息/引用

從Git存儲庫中獲取更改時，服務器會發布存儲庫中所有分支和標籤的列表，稱為refs。在某些情況下，觀察到對GitLab Web服務器的所有請求中，多達75%是對引用的請求。最好的情況是，當所有參考文件都打包好時，這是一種廉價的操作。但是，當有解壓縮的引用時，Git必須遍歷解壓縮的引用。這會導致額外的磁盤I/O，當使用高延遲存儲（如NFS）時，會很慢。

在GitLab 12.10中，info/refs通過緩存來提高引用廣告的性能，並減少引用非常頻繁獲取的情況下對Gitaly的壓力。在GitLab官網上測試此功能時，觀察到讀操作數比寫操作數多10到1，並且中值等待時間減少了70%。對於使用NFS進行Git存儲的GitLab實例，我們期望會有更大的改進。

輕鬆訪問Container Registry命令

GitLab容器註冊表用來顯示一個插圖，其中包含易於複製的構建和推送命令以及適用於項目的正確註冊表URL。但是，將鏡像添加到註冊表後，命令功能將消失。

在12.10中，即使註冊表不為空，現在也會顯示這些Docker命令。這將使新用戶的入職過程更加容易，並將提高他們對Docker命令的熟悉程度。

按名稱過濾軟件包註冊表（PREMIUM及以上）

GitLab的Package Registry使可以在一個通用的註冊表中存儲多種軟件包類型。直到最近，瀏覽軟件包列表的唯一方法是更改​​排序順序。這樣很難有效地找到特定的程序包，尤其是如果在註冊表中存儲了許多程序包時。

從GitLab 12.10開始，現在可以過濾name以快速找到的軟件包。

使用GitLab API從依賴代理中清除Blob （PREMIUM及以上）

GitLab Dependency Proxy允許代理和緩存託管在DockerHub上的鏡像，因此可以隨時在GitLab CI/CD中使用它們。在此之前還沒有清除緩存的方法，這導致了額外的存儲成本。

在新版本中可以用GitLab API清除組的Dependency Proxy的緩存並降低總存儲成本。

Gatsby的GitLab Pages項目模板

GitLab頁面本身支持最常見的靜態站點生成器。在GitLab 12.10中，可以通過新Gatsby項目模板利用靜態網站的最新技術，包括ReactJS，Webpack，GraphQL，現代ES6 + JavaScript以及CSS。

將指標自動嵌入到GitLab問題，並在Prometheus告警

在對事件進行分類時，圖表可幫助可視化錯誤原因，這可以加快調查和解決的速度。在12.9中，GitLab開始自動將相關圖表嵌入從GitLab配置的Prometheus告警創建的所有事件問題中。新版本中，對該功能進行了擴展，用以解決GitLab收到的所有Prometheus警報生成的問題，無論告警是在GitLab中配置還是在外部配置。

篩選搜索的Pod日誌

日誌無處不在，僅在可以輕鬆找到相關日誌的情況下才有用。在GitLab 12.10中，新引入了對Pod日誌的過濾搜索，使能夠使用單個可伸縮的搜索欄搜索和定義Pod日誌的過濾器。這取代了繁瑣的終端視圖，過濾器和搜索欄的組合，最終使能夠更輕鬆地查找相關日誌。

支持指標圖表中的自定義間隔

有時，使用預定義的時間間隔將很難確定特定的時間段。GitLab監控儀表板現在支持自定義間隔，這使能夠在選擇的間隔內可視化聚合指標數據，並且能夠以默認間隔可視化。

Geo管理員界面改進（PREMIUM及以上）

系統管理員需要了解其地理安裝的總體狀態。如果檢測到複製錯誤，這尤其重要。在GitLab 12.10中，對Geo管理員界面進行了多次迭代改進，使系統管理員可以更輕鬆地診斷Geo問題，並幫助他們瞭解需要採取的糾正措施，例如，通過識別無法複製的存儲庫。

最大的變化之一是添加了一個彈出窗口，該彈出窗口顯示了所有已同步，排隊和失敗的項目的詳細分類。在可用的地方，有一個鏈接到詳細信息頁面，該鏈接使系統管理員可以調查單個項目。

此外，管理員界面也進行了其他一些用戶體驗改進：

在所有地理表格中啟用實時驗證

更新了地理健康狀態以使其更加可見

重做了我們不復制的商品的同步狀態

改進的地理節點形式錯誤，可提供錯誤原因的更多詳細信息

輕鬆清理未使用的LFS文件

GitLab支持通過Git LFS管理項目中的大型二進制文件，例如音頻，視頻或圖形文件。可以通過重寫Git歷史記錄從LFS中刪除這些文件；但是，未引用的文件仍會耗盡存儲空間。到目前為止，刪除這些未引用的LFS對象的唯一方法是刪除整個項目，在許多情況下這不是一個選擇。因此，用戶可能會遇到存儲限制的情況，並意識到他們在不再需要或不需要的LFS對象上使用了大量存儲，而沒有明確的前進路徑。

為了適應，新版本中添加了兩個Rake任務

gitlab:cleanup:orphan_lfs_file_references和gitlab:cleanup:orphan_lfs_files，

它們允許從單個項目中刪除LFS文件。Rake任務可以在逐個項目的基礎上運行，並根據需要進行計劃。

進階全局搜尋索引大小減少約50%（PREMIUM及以上）

以前，由於所需的Elasticsearch索引的大小，將GitLab中的Advanced Global Search擴展到非常大的實例一直很困難。該索引由搜索數據和配置組成，僅部分使用。已經重新評估了需要為哪些內容建立索引的用法，並更新了index_options"高級全局搜索"配置的。在GitLab官網上，生產Elasticsearch Index減少了近50%。此項更改將使使用Advanced Global Search的入門變得更容易，並幫助節省在GitLab中運行Advanced Global Search時的運營開銷。

默認使用PostgreSQL

GitLab提供的PostgreSQL的默認版本現在為PostgreSQL11。對於新安裝以及不使用HA或Geo的現有安裝的升級，默認情況下將自動使用PostgreSQL 11。有關Geo和HA的安裝，請參閱12.10升級說明(文末)。在使用10K用戶參考體系結構的GitLab性能測試，結果顯示 PostgreSQL 11每秒處理的請求數比PostgreSQL 10多出7%，並且顯示了合併請求討論終端的CPU使用率減少了20%。

請注意，自GitLab 13.0起，不再支持PostgreSQL 9.6和PostgreSQL 10。在升級到13.0之前，需要先升級PostgreSQL版本。

如果使用Geo架構，請記住，由於需要在輔助群集上重新同步數據庫，因此在不中斷Geo輔助服務器的情況下無法進行主要的PostgreSQL更新。Geo升級文檔中提供了針對Geo的特定步驟。如果使用Helm安裝，則需要手動切換到PostgreSQL 12.10版。

切換到GitLab模式的普通SQL

GitLab 12.10已經從利用切換schema.rb到structure.sql用於管理數據庫模式。切換到純SQL structure.sql允許GitLab使用PostgreSQL特定的命令，例如分區。

貢獻者和管理員在需要進行遷移時可能希望瞭解更改。更改為structure.sql將會自動執行，並且不需要任何操作。

Omnibus的改進

GitLab PackageCloud存儲庫的GPG簽名密鑰已過期，已經用新密鑰替換。所以，需要已經在其計算機上配置了GitLab軟件包存儲庫，通過apt，yum或zypper使用的現有用戶，必須要重新獲取並添加新密鑰，才能繼續從GitLab軟件包存儲庫安裝或更新軟件包。

GitLab 12.10引入了Mattermost 5.21，其最新版本包括與AWS，GitLab和CodeShip的ChatOps集成。此版本還包括安全更新，建議從早期版本進行升級。

Omnibus GitLab現在默認安裝新版本的PostgreSQL 11。對於升級，如果未配置HA和Geo，則默認為PostgreSQL 11。

GitLab Runner 12.10

同期也發佈了GitLab Runner 12.10。新增加功能包括：

支持raw變量：此功能支持從GitLab檢索變量的原始標誌。標誌的值是未解釋和按字面意義對待變量。

bug修正包括：

修復有時作業失敗，並且運行器生成no such file or directory錯誤。

修復當Runner主機名包含下劃線（_）時，Docker機器無法在AWS上創建自動縮放的Runner實例。

修復有時作業在Google Kubernetes Engine（GKE）上失敗，並且Runner生成error dialing backend: EOF錯誤。

修復作業失敗，容器名稱已經在使用Docker executor的錯誤。

修復作業因Docker executor失敗而出現" No such container"錯誤。

修復包含下劃線（_）的生成容器主機名不符合RFC1035。

修復包含下劃線（_）的運行程序主機名不符合RFC1035。

修復Helm圖表配置中出現拼寫錯誤，導致Runner無法使用先前定義的Google secret。

更多詳細的信息，請參考GitLab Runner CHANGELOG中。

性能改進

在GitLab 12.10中，提供了問題，項目，里程碑等方面的性能改進包括：

具有大量問題的里程碑頁面不再超時；

合併請求討論API不再隨著評論數而降低；

問題創建具有可自定義的速率限制；

使Rails.cache和Gitlab::Redis::Cache使用相同的池；

向GraphQL組端點添加問題；

從GraphQL EpicType刪除N + 1個查詢；

通過流串行器導出，引入Writer抽象；

Redis中啟用緩存Elasticsearch的檢查。

安全和審計

增強的安全工作流程，可用於離線環境（ULTIMATE）

GitLab安全掃描儀需要互聯網連接才能下載更新和最新簽名。在脫機或連接受限的情況下自建GitLab實例，這些任務是不可以的。在GitLab 12.10中，使得在離線環境中安全掃描器變的可用。對基礎掃描儀作業定義的多項調整均支持此工作流程。

脫機環境的新文檔介紹了脫機環境中安全掃描所需的高級工作流程。新版本還在每個掃描儀的文檔頁面上添加了特定於掃描儀的說明。

通過提供對其他語言，工具和用例的支持，GitLab將在將來的版本中添加對脫機安全掃描的支持。

提供嚴重性級別以進行依賴項掃描漏洞（ULTIMATE）

現在，所有"依賴性掃描"分析器都支持報告嚴重性級別，從而使發現的風險和優先級更加容易評估。以前，並非所有語言都得到具有嚴重性的調查結果的支持，而某些嚴重性設置為Unknown，因此很難優先考慮其補救措施。

項目的合規性框架標籤（ULTIMATE）

使用GitLab的組織具有決定其運作方式的公司政策和行業法規。許多客戶的首要目標是確保其GitLab項目遵守受行業法規影響的公司內部政策。以前，沒有一種簡單的方法可以將一個項目標識為具有某些合規性要求或附加監督的項目，這是跟蹤合規性狀態的基本需求。

現在，可以通過導航到項目Settings區域，然後在該General部分中的Compliance framework下拉菜單中進行選擇，為具有特定合規性框架的項目添加標籤。此功能為將來簡化項目合規性管理奠定了基礎。

合規性儀表板顯示最新合併的MR的管道結果（ULTIMATE）

當管理員或組所有者評估其GitLab項目的合規性時，他們需要知道所部署代碼的管道狀態。管道可以包含確定是否遵守組織策略的階段或工作。到目前為止，管理員或組所有者必須調查每個項目以驗證每個管道。

現在，"合規性儀表板"包含組中所有項目的最新管道狀態。管理員和組所有者現在可以一眼識別出已批准和合並的MR的潛在合規性問題。

禁用DAST中的單個規則（ULTIMATE）

作為黑盒工具，DAST掃描對底層站點或應用程序體系一無所知。這可能導致用戶立即知道不是可利用的漏洞的誤報。例如，當應用程序體系結構中沒有SQL數據庫時，DAST掃描報告可能存在SQL注入漏洞。由於這個問題，GitLab 12.10支持使用DAST_EXCLUDE_RULES變量打開和關閉特定規則。這允許使用逗號分隔的漏洞規則ID列表從掃描中排除。使用此變量排除特定規則時，可以針對目標應用更好地進行掃描，以減少誤報。

容器網絡策略統計報告（ULTIMATE）

新版本中可以同時看到總流量和阻止流量的數據，從而可以更輕鬆地確定如何配置，調整和評估網絡策略。

容器網絡策略統計信息將顯示在"安全與合規性"菜單項下的新"威脅監控"頁面上。默認情況下，數據為期30天。

用於記錄和阻止模式的Web應用程序防火牆（WAF）控件

為了幫助調整誤報或誤報的規則，可以在"操作"->" Kubernetes"頁面上將WAF全局設置為"記錄"或"阻止"模式。

比較一段時間內的Release證據（PREMIUM及以上）

在12.6中，GitLab引入了一種簡化的方法來收集所有必要的信息，以支持Release對象中的合規性和審計工作。利用此新功能，證據收集時間戳將顯示在下載證據哈希的鏈接旁邊。這使審核員可以輕鬆地比較一段時間內的發佈證據，而不需要腳本來收集和比較每個證據。

新的HIPAA審核協議項目模板（ULTIMATE）

藉助GitLab，可以自動化高度可重複的HIPAA審核協議工作流程。manbetx客戶端打不開可以利用問題和項目模板來幫助簡化這些工作流程。此過程可以幫助將新問題映射到HIPAA審核協議中的每個要求。它還可以幫助的組織在GitLab工作流程中管理審核證據的收集和總體狀態。

GitLab現在通過新的企業合規性模板支持HIPAA審核協議。為了幫助符合HIPAA審核要求，GitLab可以幫助創建新項目，每個項目都有180個問題映射到HIPAA審核協議。每個問題都是每個HIPAA協議的審核跟蹤，並且可以幫助團隊在GitLab中管理其HIPAA合規性計劃時保持聯繫。

可選的SSH密鑰有效期

注重合規性的組織需要一種方法來控制對其GitLab環境的SSH憑據訪問。SSH密鑰通常配置為沒有到期日期。對於具有訪問管理和/或憑據管理策略的組織而言，這是有問題的，這些策略要求所有訪問憑據上的有效期。在新版本中，GitLab支持用戶可以在GitLab UI中設置的SSH密鑰的到期日期。

Bug修復

GitLab 12.10修正很多bug，其中包括：

使用GraphQL API時，合併請求不再返回空數組；

Elasticsearch集成菜單現在可以防止URL字段中出現非URL模式；

更新Elasticsearch index_options以修復複雜的搜索查詢；

改善Elasticsearch設置的自動完成結果；

遇到數據庫連接錯誤時引發異常；

具有大量問題的里程碑頁面不再超時；

發行板搜索返回1和2個字母搜索的結果；

董事會列表成為組標籤時不再失去其過濾器標籤；

修復帶有2個標籤和搜索文本的列表中的史詩過濾時的異常；

創建發佈API對於無效標籤返回500錯誤；

將發行說明設為可選，並且在刪除發行說明時不要刪除發行說明；

使用來賓帳戶的用戶看不到發佈；

GitLab頁面的最大大小不接受值0；

在分頁時不加載時釋放頁面。

GitLab Chart 改進

Helm Chart文檔已更新，包括命令行選項和特定於Helm 3的文檔鏈接，並著重強調了Helm 2和Helm 3之間的某些區別。

在GitLab的下一發行版GitLab 13.0中，將刪除環境變量的ConfigMap條目puma.rb和unicorn.rb文件。請注意，如果過去曾經unicorn.rb通過ConfigMap（通過Helm + Kustomize）修改了，則將受到此更改的影響。

到目前為止，puma.rb和unicorn.rb文件在gitlab-webservice容器內是靜態的，並被gitlab/unicorn圖表中的ConfigMap項覆蓋。

現在使用的Web應用程序服務器的Unicorn或Puma之間進行選擇，Unicorn圖表的名稱將從更改unicorn為webservice。

功能棄用

GitLab CI/CD管道配置模板由""取代only和except

更改日期：2020年5月22日

gitlab不鼓勵使用only和except支持。該rules參數提供了更詳細，更具表現力的作業執行邏輯，這些邏輯對於評估和理解不太複雜。

從GitLab 13.0開始，將使用並將轉換為的Auto DevOps和Secure 配置模板。我們強烈建議定製工作模板的客戶過渡，因為這兩個配置選項不能一起使用。更改將影響以下作業配置模板：

Build.gitlab-ci.yml

Test.gitlab-ci.yml

Deploy.gitlab-ci.yml

安全功能有關的 .gitlab-ci.yml模版s:

Container-scanning.gitlab-ci.yml

DAST.gitlab-ci.yml

Dependency-Scanning.gitlab-ci.yml

License-Management.gitlab-ci.yml

License-Scanning.gitlab-ci.yml

SAST.gitlab-ci.yml

使用only和對這些模板的任何自定義except都應轉換為語法。在某些情況下，現有only和except邏輯無法與匹配rules。我們很樂意聽到有關此rules

Auto DevOps的默認PostgreSQL

生效日期：2020年5月22日

作為更新Auto DevOps以支持Kubernetes 1.16的一部分，在GitLab 12.9中添加了Auto DevOps的啟用功能，以使用PostgreSQL圖表版本8.2.1。當前默認的PostgreSQL圖表版本是0.7.1。在GitLab 13.0中，計劃將默認的PostgreSQL圖表版本從0.7.1切換到8.2.1。要保留舊的默認設置，需要將AUTO_DEVOPS_POSTGRES_CHANNELCI變量顯式設置為1。要將現有的0.7.1 PostgreSQL數據庫遷移到較新的基於8.2.1的數據庫，請遵循升級指南以備份數據庫，安裝新版本的PostgreSQL並還原數據庫。

Auto DevOps Auto Deploy設置值已棄用

棄用日期：2020年5月22日

由於Kubernetes 1.16啟用了多種API，默認值extensions/v1beta1對於deploymentApiVersion在汽車的DevOps'設置自動部署圖現在已經過時。

該deploymentApiVersion設置計劃apps/v1在GitLab 13.0中更改為新的默認值。如果使用的是Kubernetes 1.9及更低版本，則需要升級Kubernetes集群以獲得apps/v1版本支持。對於Auto DevOps，GitLab需要Kubernetes 1.12+版本。

項目端點的偏移分頁限制為50,000

生效日期： 2020年5月22日

基於偏移量的分頁限制50,000將在GitLab.com上應用，默認情況下在自管實例上將應用於/projects GitLab 13.0中的API端點。進行具有以上偏移量的API調用的集成50,000將需要切換到基於鍵集的分頁方法，該方法可顯著改善響應時間並減少GitLab服務器上的負載。自建實例將能夠將限制自定義為所需的值。

為了提供優化的性能，基於鍵集的分頁僅提供基於project的排序id。如果偏移量保持在限制以下，則需要更靈活訂購選項的用例可以繼續使用基於偏移量的分頁。如果用例需要具有較大偏移量的靈活排序選項，則建議對客戶端進行排序。

刪除代碼片段內容搜索

更改日期：2020年5月22日

隨著繼續為代碼段進行版本控制，將進行更改以在UI和API中搜索代碼段，從而從搜索結果中刪除代碼段內容。標題和說明內容可通過搜索和API訪問。

默認的應用服務器使用Puma

更改日期：2020年5月22日

GitLab將在13.0中將默認應用程序服務器從Unicorn切換到Puma。Puma是多線程應用程序服務器，使GitLab可以將其內存消耗減少約40%。

作為GitLab 13.0升級的一部分，自定義Unicorn設置的用戶將需要手動將這些設置遷移到Puma。也可以通過禁用Puma並重新啟用Unicorn，直到在將來的版本中刪除對Unicorn的支持之後，才能保留在Unicorn上。

棄用Redis 3

更改日期：2020年5月22日

在GitLab 12.7中，Redis版本已更新為Redis 5。Redis 3已過期，並且從GitLab 13.0開始將不再受支持。

14.0不再支持GitLab Pages磁盤源

更改日期：2020年5月22日

GitLab Pages基於API的新配置將在13.0中可用，並將替換磁盤源配置。仍然可以在明年之前使用舊配置，儘管我們建議儘快（而不是稍後）切換到基於API的配置，因為舊配置將不支持新功能。在許多情況下，GitLab頁面將自動切換到基於API的配置，而無需執行任何操作。現在無需執行任何操作。從13.0開始，GitLab Pages將自動使用新的配置源，並在出現錯誤時回退到舊的配置源。還有一種方法可以強制執行舊的配置源，但是它將在14.0中刪除。

Projects API中刪除'marked_for_deletion_at'屬性

棄用日期：2020年5月22日

對於使用GitLab Silver，Premium或更高版本的客戶，GitLab在列出項目時的API響應當前返回一個名為的屬性marked_for_deletion_at，該屬性表示將項目標記為軟刪除的日期。為了使我們的API中的術語標準化，在GitLab 13.0中將不推薦使用此屬性。marked_for_deletion_on已經添加了一個具有相同信息的新屬性。

刪除"projects"和" shared_projects"屬性

為了提高性能，我們限制了`groups /：id端點返回的項目數量。從GitLab 12.9開始，我們將在組詳細信息API上返回的項目數限制為100。

為了進一步改善此端點的性能，從GitLab 13.0開始，當通過API 請求組的詳細信息時，我們將從響應中刪除"項目"和"共享項目"屬性。用戶仍然可以在同一組API的列表中找到一個組的項目端點。

引入"id"字段，用來替換JSON通用安全性報告中的"cve"

更改日期：2020年5月22日

GitLab當前用於安全報告的JSON通用報告格式需要改進，特別是當我們鼓勵並添加第三方安全供應商集成時。主字段cve屬性令人困惑，因為它不包含CVE數據，因此應將其刪除。將引入id字段，該字段是為GitLab掃描儀自動計算的，並且是第三方合作伙伴掃描儀必需的。該id字段最終將替換cve為唯一的發現標識符。任何cve使用安全性報告，自定義腳本或作為我們的安全功能的集成者利用該屬性的人，最終將需要停止使用該cve屬性，而應該開始使用新id屬性。請注意，今天id和cve都是必填字段。

sidekiq-cluster將成為在GitLab 13.0中調用Sidekiq的默認方法

更改日期：2020年5月22日

在GitLab 13.0中，我們將棄用sidekiq-cluster用於啟動多個Sidekiq進程的參數。在GitLab 13.0中，默認情況下將啟用Sidekiq Cluster，而不是sidekiq-cluster如啟動多個進程中所述手動啟用和指定參數，並提供一組默認參數。如果已經啟用了Sidekiq群集，則應該沒有可見的更改。

計劃刪除Runner的details API中的" token"屬性

棄用日期：2020年5月22日

在GitLab 13.0（2020年5月）中，token將從Runners API接口中刪除該屬性，該屬性通過ID來獲取runner的詳細信息。可以在相關問題或通常的支持渠道中提供反饋。

搬遷日期： 2020年5月22日

Omnibus GitLab中不推薦使用"user"設置

更改日期：2020年5月22日

在consul[user]和repmgr[user]的設置被取消，將在GitLab 13.0去除。GitLab中的其他服務使用username而不是user。為了保持一致性，將從13.0開始使用consul[username]和repmgr[username]設置提供Consul和repmgr的用戶名。

升級更新

Omnibus版本升級

通過Omnibus安裝自建實例可以使用Linux包管理器可以升級。

比如對CentOS:

yum updata/install gitlab-ce

就會自動完成升級：

docker版本

停止和刪除舊的容器

sudo docker stop gitlab

sudo docker rm gitlab

Pull官方最新鏡像：

sudo docker pull gitlab/gitlab-ce:latest

重新啟動容器（啟動參數和以前保持一致）即可，比如:

sudo docker run --detach \\

--hostname gitlab.example.com \\

--publish 443:443 --publish 80:80 --publish 22:22 \\

--name gitlab \\

--restart always \\

--volume /srv/gitlab/config:/etc/gitlab \\

--volume /srv/gitlab/logs:/var/log/gitlab \\

--volume /srv/gitlab/data:/var/opt/gitlab \\

gitlab/gitlab-ce:latest

Docker compose版本

可通過：

docker-compose pull

docker-compose up -d

有關升級到GitLab 12.10的重要說明

用於簽名GitLab軟件包的GPG密鑰已於2020年4月6日更改。如果之前在計算機上配置了GitLab軟件包存儲庫，則需要採取一些手動步驟來添加新密鑰，然後才能進行安裝或安裝。更新GitLab軟件包。

PostgreSQL 11是GitLab 12.10中的默認PostgreSQL版本。GitLab的所有新安裝都將自動默認為PostgreSQL 11。對於現有GitLab安裝的升級，如果檢測到PostgreSQL 9.6或10，則PostgreSQL版本將自動升級到PostgreSQL 11。

但是，對具有高可用性和Geo的安裝進行主要PostgreSQL升級需要自行手動操作。如果GitLab檢測到正在使用repmgr或Geo，它將要求按照HA或Geo的手動升級說明進行操作，不會自動升級的PostgreSQL數據庫。

對於12.10，如果想先升級GitLab版本，然後再升級PostgreSQL，仍然可以選擇在升級GitLab（sudo touch /etc/gitlab/disable-postgresql-upgrade）前禁用PostgreSQL升級，以保留在PostgreSQL 9.6或10上。

請注意，GitLab 13.0中將刪除PostgreSQL 9.6和10。必須要先將PostgreSQL數據庫升級到PostgreSQL 11，然後才能升級到GitLab 13.0。

閱讀更多 蟲蟲安全 的文章

關鍵字: 軟件 美好，一直在身邊 JSON