上個月22日，GitLab官方blog按照慣例發佈了有一個月度版本12.7。在12.7中，做了多項改進，包括父子管道，管道資源組、blame視圖、結構化日誌等。關於本次發佈的功能介紹，請和蟲蟲一起學習。
主要功能介紹
父子管道
複雜的應用程序通常需要複雜的管道，這可能會導致執行變得緩慢且不好排查管理。隨著管道複雜性的增加，其可視化會變得越來越笨拙，配置更加複雜，執行速度也變慢。此時，將複雜的管道分成多個管道（以父子關係進行組織）可以提高性能並使管道清晰：因為子管道可以同時運行，所以可以提高性能，而配置和可視化可以分為不同的部分文件或視圖。新版本GitLab 12.7中，可以使用單獨的YAML文件定義這些單獨的管道。 .gitlab-ci.yml仍然是主要配置入口，但是可以在這個主配置中可以include任何其他YAML文件作為其自己的子管道，並歸還給父管道。還支持使用include來促進這些不同管道之間的代碼重用。
GitLab在線倉庫Beta版Windows共享運行程序
GitLab託管的Windows Shared Runners推出測試版。可以利用該託管，實現自動縮放和安全的環境，可與GitLab在線倉庫在同一GCP基礎結構上的Windows虛擬機上運行CI/CD作業。 Windows Shared Runners已預先配置了各種軟件包，例如Windows的Chocolately軟件包管理器，Visual Studio 2019 Build Tools和Microsoft .Net Framework等。
當然也可以繼續在自己的基礎架構上安裝和管理Windows Runner，以與GitLab團隊管理的新可用GitLab在線倉庫Runners一起使用或互相替換。
關於其相關說明、價格、限制和配置的更多信息，請參考Windows Runners beta官方相關文檔。
管道資源組
大多數情況下，用戶希望儘可能並行化其CI/CD，以加快總運行時間。但是，在某些情況下，可能希望限制併發性。例如，如果要防止作業在同一環境中同時在不同的管道中執行。當廣泛使用諸如智能手機，計算機芯片或嵌入式IoT設備之類的物理硬件來運行測試之前，經常會看到這種情況。嘗試從多個管道甚至同一管道中的多個作業同時運行測試可能會導致數據損壞，無效的測試結果，甚至使硬件變磚。
使用資源組，可以限制管道併發，以強制作業按順序執行，從而確保僅按計劃使用資源。使用.gitlab-ci.yml中的resource_group關鍵詞，可以限制每個作業指定屬於資源組一部分的環境。當作業請求運行程序並且資源已在運行現有作業時，它將一直排隊，直到現有作業完成。例如，如果有多個用於測試的IoT設備，並且希望測試作業在組中的任何一臺設備上運行，甚至可以為每個作業定義多個資源組。另一個很好的用例是使用Terraform將基礎結構作為代碼進行管理時，確保一次只對給定環境進行一次更改。
代碼審查分析（STARTER及以上）
代碼審查是任何軟件開發過程的推薦部分，它使對等方和自動化過程能夠檢查對存儲庫的建議更改。
由於錯過了交接，關鍵人員正在休假或待審核的項目積壓，因此遷入的更新可能停滯在那裡。週期時間取決於及時的代碼審閱，以保持團隊的運轉。
為了幫助GitLab實例始終處於開發過程的關鍵部分，新版本中引入了代碼審查分析以突出顯示正在審核的合併請求的狀態。
合併請求收到成員的commit後，代碼審查分析便開始審查過程，並跟蹤該合併請求已打開多長時間。表格中突出顯示的合併請求以遞減順序顯示審閱時間，因此很容易找到可能需要干預或進一步細分的合併請求。
顯示合併請求的部署時間
新版本中，"合併請求"小部件會在每個合併請求中顯示環境名稱和部署時間。之前，為了確定上一次部署的時間，將需要遍歷提交和管道列表以獲取此信息。通過跟蹤合併請求，開發人員將能夠輕鬆查看其更改何時進入特定環境。
與其他組共享組訪問權限
組可用於組織項目和組成員。典型的使用模式是為不同的團隊創建組，例如開發，運維和運營，並對每個小組共享相關項目。
對於具有數千個項目的大型實例，與一組共享單個項目很快變得不可擴展。為了簡化操作，新版本引入了與另一個組共享一個組的功能，而無需與一個組共享單個項目鏈接。
新增"不是"運算符（!=）篩選，支持過濾問題、合併請求、Epic和問題面板
精確查找所需的問題，合併請求和Epic可能很困難，尤其是當你想要省略結果的子集時。新版本中支持在使用（!=）運算符在問題面板中過濾問題，合併請求，Epic和問題列表。
Blame視圖瀏覽文件更改歷史
Blame視圖允許逐行跟蹤文件的歷史記錄，並檢查每次提交。在GitLab 12.7中，可以在更改之前使用標題為View blame的新按鈕輕鬆跟蹤特定行的歷史記錄。
允許在依賴項掃描中配置pip版本（ULTIMATE）
在GitLab 12.7中，可以使用DS_PIP_VERSION變量在"依賴關係掃描"中安裝自定義版本的pip。設置此選項後，它將向下傳遞到"依賴關係掃描"分析器。
發佈的審計事件（STARTER及以上）
在GitLab版本中更進一步，自動在GitLab審核日誌中包含創建或編輯版本，下載工件以及關聯或解除里程碑的事件，從而使過程審計更加輕鬆。
使用CI/CD更新Conan存儲庫（PREMIUM及以上）
GitLab 啟動了Conan存儲庫，以支持C/C++開發人員發佈和下載其依賴項。但是，在為了利用GitLab CI/CD，必須使用其用戶名和密碼，這樣效率低下並且存在潛在的安全風險。
GitLab 12.7中，用戶現在可以利用預定義的環境變量CI_JOB_TOKEN對他們的Conan存儲庫進行身份驗證，並輕鬆發佈和安裝其依賴項。
禁用用戶個人資料名稱更改（PREMIUM及以上）
管理員現在可以防止用戶更改其個人資料名稱，以提高用戶操作的可追溯性。對身份的附加控制將使注重合規性的組織能夠確保GitLab支持其內部策略以進行審核日誌記錄和身份驗證。
這是一個全局實例級功能，需要管理訪問權限，並且當前僅適用於自建GitLab實例。
用於與部署關聯的合併請求的API
新增加了API支持，可用於檢索給定部署中隨附的合併請求列表。這對於跟蹤合併請求何時合併到特定環境中很有用。
增加GitLab CI/CD分步部署指南
在對應用程序進行更改時，可以選擇只發布到部分Kubernetes Pods節點，用來降低風險。採用逐步上線（灰度發佈）策略，可以監視錯誤率或性能下降，如果沒有問題，則可以更新所有節點。GitLab支持使用增量式對Kubernetes生產系統的手動觸發和定時式部署，以支持持續交付和持續部署的應用程序。該策略已經在Auto DevOps項目中可用。新版本提供一份新指南，顯示僅使用GitLab CI/CD時如何獲得相同的結果。
直接從列表中切換功能標誌（PREMIUM及以上）
通過功能標誌，可以在生產環境中啟用或禁用最近引入的功能，以降低在完全測試功能之前破壞應用程序的風險。新版本中可以直接在功能標記列表中一鍵在GitLab中打開或關閉標記。而此前需要使用API實現切換。
忽略GitLab中的Sentry錯誤
錯誤有可能是多而嘈雜，這導致分類過程很耗時，很難通過分類來找到關鍵錯誤。能夠忽略GitLab用戶界面中的錯誤，可以使我們清除不需要關注的錯誤，以便可以輕鬆地專注於需要修復的錯誤。忽略非嚴重錯誤使錯誤列表易於掃描和分類。可以在錯誤的特定詳細信息頁面和錯誤列表上找到"忽略"按鈕。
Sentry錯誤詳細信息頁面上的語言和緊急信息
錯誤的分類具有挑戰性，因為它們嘈雜，並且難以找到相關信息。GitLab中的錯誤詳細信息頁面顯示了錯誤的最重要屬性。在GitLab 12.7中，這些詳細信息現在包括語言和緊急度，用來幫助儘快確定錯誤的根本原因。
在Sentry錯誤詳細信息頁面上鍊接到GitLab提交
遍歷堆棧跟蹤非常麻煩，而不必確定哪個版本影響了受影響的文件。在GitLab 12.7中，最有可能導致錯誤的提交會自動顯示在錯誤詳細信息頁面上。能夠自動將提交與可疑錯誤相關聯，可以大大減少解決錯誤的時間。這使我們能夠立即回滾更改，或使用補丁程序對其進行修復。
請注意，為了利用此功能，需要使用已部署提交的SHA來命名Sentry Release對象。
解決GitLab中的Sentry錯誤
一旦確定了錯誤的根本原因，就部署了修補程序並驗證了其成功（全部來自GitLab）。使用GitLab 12.7，現在只需單擊一個按鈕，就可以解決錯誤而無需切換到Sentry。在錯誤的特定詳細信息頁面上可以找到"解決"按鈕。
應用建議配置默認提交消息
建議合併請求中的更改使提出改進建議變得容易。但是，如果使用推送規則要求所有提交消息都採用特定格式，則在大多數情況下，無法應用建議的更改，因為GitLab生成的提交消息與推送規則的驗證模式不匹配。
在GitLab 12.7中，支持在應用建議的更改時為GitLab創建的提交配置提交消息模板，因此根據提交消息推送規則，設置才有效。
自動鏈接Rust軟件包名稱
瀏覽項目時，查看其依賴項通常很有用，但是依賴項通常存儲一個鏈接文件中。
新本中，在查看Rust項目的Cargo.toml依賴項配置文件時，GitLab將檢測用的依賴包並將其鏈接到crates.io，以便於理解其依賴項。之前的GitLab 9.3中已經添加了對Go，Ruby，Node.js，Python，PHP和Objective-C等語言項目的支持。
查找SSH並通過MD5和SHA-256指紋部署密鑰
2015年OpenSSH（6.8）默認的指紋算法默認切換到SHA-256，顯示SSH密鑰的MD5哈希值將沒多大意義。現在可以同時看到SSH和部署密鑰的SHA-256指紋，並支持通過新添加的API來通過密鑰指紋查詢用戶：
curl --header "PRIVATE-TOKEN: <your>" '/api/v4/keys?fingerprint=SHA256%3AnUhzNyftwADy8AH3wFY31tAKs7HufskYTte2aXo%2FlCg/<your>
重複指標儀表板
GitLab開箱即用，帶有許多有用的指標儀表板，用於監視應用程序的運行狀況。在12.7中，可以輕鬆地複製這些默認儀表板之一，以便進行少量自定義以添加例如應用程序的特定系統或業務指標。
要求所有用戶登錄才能訪問GitLab Pages網站
新版本中，GitLab Pages具有一種與項目隱私設置分開的禁用非授權訪問的方法，這樣即使對公開項目的Pages站點可以設置要求用戶登錄才能訪問。GitLab管理員可以通過頁面管理設置中的複選框啟用此設置。
對Elasticsearch 7.x的支持（STARTER及以上）
在GitLab 12.7中，更新了索引器和GitLab的依賴關係，以支持Elasticsearch 7.x和現有的對Elasticsearch 6.x的支持。這是Elasticsearch集成中最需要的功能。過更新以支持Elasticsearch 7.x，還發布了索引器的2.0.0版本，該版本正式提供了此支持。如前所述，GitLab不再支持Elasticsearch5.6.x。
項目所有項目服務的API路線在/projects/:id/services下可以使用新的API路由，該路由提供了給定項目的所有活動項目服務的列表。
獲取活動服務列表的功能使開發人員可以更輕鬆地通過API以編程方式在其項目中添加和編輯服務。
使用結構化的應用程序日誌記錄和分析實例活動
GitLab的日誌系統使管理員可以監視和評估日誌文件，以更好地瞭解實例的狀態。這些日誌具有廣泛的用例，包括性能監視，分析和系統審核。
但是，某些日誌僅以非結構化格式提供，使其難以解析。這些非結構化日誌之一為application.log，該日誌記錄了應用程序的活動，包括項目，組和用戶事件。在12.7中，GitLab中引入了更加靈活的日誌記錄系統，以application_json.log的形式引入了JSON格式的application.log。
創建此日誌文件的結構化版本會開闢很多有意思的用例，例如，將其納入監視工具以進行事件審核，將這些事件發送到可視化工具以構建自定義的儀表板，等等。
直接從Epic創建問題（ULTIMATE）
不再需要通過多個選項卡進行切換來創建問題並將其分配給史詩。現在，可以直接從Epic視圖創建問題。
從電子表格剪切並粘貼Markdown表
將表格數據整合到Markdown中可能是一個繁瑣而費力的過程。從12.7開始，你現在可以從電子表格中複製內容，將其直接粘貼到GitLab中的Markdown編輯器中。編輯器會自動將電子表格轉換為有效的Markdown語法，不用浪費時間進行格式化，將更多的時間用來創造更有意義的工作。
注意蟲蟲對該功能測試結果是在問題編輯器中是有效果的，而在給倉庫中文件的編輯器後者Web IDE中都是不支持的。
自動暫存Web IDE中的所有更改
GitLab中的Web IDE是很棒的在線進行項目更改的工具。但是，其文件的持久性是一個問題。用戶可能會更改多個文件，但是在離開Web IDE頁面瀏覽之前，並不能保證所有更改都被暫存和提交，可能會導致這些更改丟失。
為了使Web IDE對用戶更易於訪問並防止出現意外丟失情況，新版本中將自動暫存Web IDE中的更改。當用戶單擊"提交"時，提交屏幕將使他們能夠添加其提交消息並選擇其分支，而不是提供暫存更改的選項。
從用戶界面刪除管道
此前，只能通過API刪除管道。從12.7版開始，擁有項目所有者權限的用戶可以單擊新的"刪除"按鈕直接從"管道詳細信息"頁面中刪除特定管道。這個不可逆操作將使管道緩存過期，並刪除所有相關對象（構建，日誌，工件和觸發器）。
能夠從UI刪除管道的主要好處是，如果管道中的作業以純文本形式公開私鑰，則可以立即採取行動以保護洩露的機密。另一個一個更常見的用例是需要清理混亂的CI歷史記錄，該歷史記錄中充滿了由於CI配置嘗試或實驗導致的失敗管道；清理的另一個好處是可以確保不會意外使用不需要的管道。
查看設計時放大（PREMIUM及以上）
當將問題（如寬屏網站佈局）上傳到問題的"設計"選項卡時，由於圖像顯示在固定寬度的窗口中，因此很難看到圖像的細節。新版本中現，支持放大設計，因此可以深入瞭解細節。在圖像底部找到縮放控件。
Auto DevOps運行檢查
對於任何項目，Auto DevOps是入門現代DevOps實踐的好方法。但是Auto DevOps仍需要運行CI管道來通過檢查項目是否存在Dockerfile或匹配的buildpack來確定與項目的兼容性。為了提高效率，並利用GitLab CI中的workflow:rules新功能，只有在項目包含Dockerfile或項目語言存在匹配的buildpack時，Auto DevOps才會運行。
使用CI模板安裝Kubernetes應用程序
使用GitLab CI安裝Kubernetes應用程序是一種在安裝之前自定義Helm Chart和自定義資源（CRD）的好方法。新版本中添加用於使用GitLab CI安裝Cert-Manager以及GitLab Runner的模板。通過GitLab CI安裝GitLab Runner掌舵圖，用戶可以配置以前無法執行的設置，例如併發作業數或作業檢查間隔。
從服務檯創建電子郵件回覆模板（PREMIUM及以上）
現在可以根據組織自定義Service Desk電子郵件回覆，只需將模板Markdown文件添加到存儲庫中，並且Service Desk響應用戶時，就會自動使用該模板。這將允許自定義品牌和消息傳遞為客戶提供最佳體驗。
將用戶模板附加到收到的服務檯問題（PREMIUM及以上）
服務檯允許通過向唯一地址發送電子郵件來創建新問題。創建這些新服務檯問題後，如果可以將它們自動分配給特定用戶，給定標籤或分配給里程碑，則將是有益的。新版本中，可以通過創建要包含在所有新服務檯問題中的模板來做到這一點。在模板中包括任何快速操作，它們將在創建問題時激活。
Geo支持複製設計管理資產（PREMIUM及以上）
GitLab設計管理允許用戶將設計資產（例如，模型）上載到GitLab問題，並將其存儲在一個地方。
GitLab Geo現在支持將這些設計管理資產複製到輔助節點，以確保分佈式團隊可以從最近的Geo節點訪問它們。由於設計管理資產已複製，因此也可以從輔助節點還原它們。
目前還不支持對這些資產的驗證，並將在以後的版本中增加支持。
外觀API
新版本中，可以通過新的API調整實例的外觀設置，包括實例標題，描述，圖標，徽標等屬性。
改進了差異突出顯示的合併請求建議
使用"建議的更改"提出對"合併請求"的改進建議，通過應用更改並單擊解決解決方案，可以使協作更加輕鬆。
在GitLab 12.7中，改進了diff突出顯示了建議的更改，讓我們清楚哪些單詞和字符已更改，因此可以放心地應用建議，一鍵修改。
禁用自動關閉合並請求中的問題
每個團隊都有獨特的需求。通常，有必要在單個合併請求的生命週期之外保持問題處於打開狀態，或者在提交中引用問題而不試圖關閉問題。
在此版本之前，團隊無法通過在合併請求或提交中提及問題來禁用自動關閉問題的默認行為。為了向團隊提供對該功能的更精細控制，現在可以在項目設置中禁用自動關閉問題。
改善了/projects API初始響應時間
在GitLab 12.7中，對/projects API的首頁響應時間進行了顯著改進。此前，對於某些參數組合， GitLab官網上看到的響應時間高達30秒。通過改善，現在大多數響應將在一秒鐘之內。請注意，無論使用哪種分頁策略，這些改進都適用。
使用keyset分頁加速/ projects API
為/projects API端點引入了新的分頁機制。以前，基於偏移量的分頁是唯一可用的方法，該方法雖然提供了靈活的排序和過濾選項，但對請求的每個頁面的執行效果卻越來越差。這種不良的性能特徵使GitLab服務器的負載增加，並且響應時間越來越長。
在GitLab 12.7中，引入了基於keyset的分頁。儘管此方法僅允許基於項目ID進行排序，但是無論請求的是哪個頁面，它的執行速度都非常快，響應時間能保持很短。將keyset分頁用於檢索許多頁面的查詢，既可以減輕GitLab服務器的負擔，又可以加快數據檢索的速度。
預計在12.10中，將為基於偏移的分頁實現可配置的頁面深度限制，默認深度為10,000條記錄。10,000的限制將在12.10中在GitLab線上倉庫上強制執行。
使用API時，允許基於配置項跳過CI
在提交消息中使用CI skip（或跳過ci）或通過使用push選項時，已經可以跳過CI管道的創建，但是在重新rebase時無法跳過CI。從12.7版開始，現在可以使用rebase API。
Omnibus的改進
Omnibus GitLab中捆綁的Redis版本已從Redis 3.2.12更新到Redis 5.0.7，這使GitLab擁有最新的Redis穩定發行版。Redis 5包括許多改進。有關Redis 5中所做更改的更多信息，請參見Redis發佈公告。升級後，需要手動重新啟動Redis。更多升級說明，見本文最後的有關升級到GitLab 12.7的重要說明。
如果嘗試升級時仍在進行後臺遷移，則某些版本之間的升級有時會失敗。文檔已添加到更新GitLab中，該文檔說明了如何檢查後臺遷移是否仍在運行。
GitLab中包含的Ruby版本已從2.6.3更新到2.6.5，以包括一些修復程序和安全補丁。
添加了有關如何使用EXTERNAL_URL環境變量的文檔，以使其更易於啟動和運行GitLab實例。
GitLab Runner 12.7
同時還發布了GitLab Runner 12.7。一些改進包括：
在Docker執行程序中允許來自配置的服務別名
修復了"在沒有配置裁判的情況下，Kubernetes執行者的恐慌"
升級到Go 1.13.5
性能改進
GitLab 12.7中的一些改進包括：
刪除preset_group_root功能標誌。
添加里程碑日期來源外鍵。
允許Gitaly引用名稱緩存進行問題討論。
防止大量用戶引用導致堆棧溢出。
里程碑燃盡圖的性能改進。
將RelativeLinkFilter拆分為UploadLinkFilter和RepositoryLinkFilter。
對路線圖Epic使用緩衝渲染
導入：預加載項目，用戶和組以重用對象
導入：添加importing?禁用一些回調
導入：GroupProjectObjectBuilder的LRU對象緩存
GitLab Chart 3.0
與GitLab 12.7一起發佈的GitLab Chart 3.0是GitLab Helm Chart的新主要版本。由於此版本中的重大更改，升級需要執行其他步驟，並且應按照升級文檔進行。GitLab Chart 3.0包括許多組件的功能改進和更新，下面概述了每個組件，並鏈接到GitLab Chart 3.0史詩。
GitLab hart使用nginx-ingress Chart的分支。GitLab Chart 3.0引入了在上游nginx-ingress圖表中所做的更改，以確保GitLab與Helm 2.15.0和Helm 3兼容。
Kubernetes 1.16中不再支持extensions/*和apps/beta* API版本。GitLab使用的多個上游Chart已更新，以停止使用這些API版本。GitLab Chart 3.0包括更新的上游Chart：Prometheus Chart9.4.x，PostgreSQL Chart 7.7.0和Redis Chart 10.3.x（不再fork）。
Sidekiq部署現在使用唯一的選擇器，以避免在創建多個部署時混淆哪些部署擁有一組sidekiq容器。有關升級Sidekiq部署的重要信息，請參閱升級文檔。
添加了文檔，以提供有關將GitLab連接到用於對象存儲的外部Minio實例的說明。
GitLab Chart不再管理GitLab操作員CRD（Kubernetes自定義資源定義）的生命週期。現在可以直接使用kubectl完成CRD的安裝。有關安裝CRD的新說明，請參閱GitLab Operator安裝文檔。
禁用gitaly的標誌已移至全局設置。這簡化了禁用Gitaly的過程，因此不再需要跨服務編輯多個設置。有關如何禁用Gitaly以利用外部Gitaly服務的新說明，請參閱使用外部Gitaly配置文檔。
功能棄用
GitLab 13.0中刪除PostgreSQL 9.6和10.x的支持
為了利用PostgreSQL 11中改進的性能和功能（例如分區），計劃在GitLab 13.x中要求PostgreSQL 11和12版本。為此，將在即將發佈的GitLab 12.x版本中引入對PostgreSQL 11的支持，同時保持對9.6和10.x的支持。到GitLab 13.0中，將最低需要PostgreSQL 11版本。
通過最低要求PostgreSQL 11，能夠利用引入的新功能，而無需維護多個代碼分支。展望未來，Gitlab將保持PostgreSQL升級的年度節奏，並在能夠添加第二和第三最新版本後對其進行支持。
生效日期：2020年5月22日
/projects的偏移分頁限制為10,000
在GitLab官網上將基於偏移量的分頁限制10,000應用於GitLab 12.10中的/projects API端點，默認情況自建實例啟用。進行偏移量大於10,000的API調用的集成將需要切換到基於Keyset分頁方法，這將顯著縮短響應時間並減少GitLab服務器上的負載。自建實例將能夠將限制自定義為所需的值。
為了提供優化的性能，基於Keyset分頁僅提供基於項目ID的排序。如果偏移量保持在限制以下，則需要更靈活選項的用例可以繼續使用基於偏移量的分頁。如果用例需要具有較大偏移量的靈活排序選項，則建議對客戶端進行排序。
變化日期：2020年4月22日
升級更新
Omnibus版本升級
Omnibus安裝的自建實例可以使用包管理器可以升級。
CentOS: yum updata/install gitlab-ce 就會自動完成升級過程。
docker版本升級
先停止和刪除舊的容器
sudo docker stop gitlab
sudo docker rm gitlab
拉取gitlab官方最新的鏡像：
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.7的重要說明
Omnibus GitLab打包的Redis版本已更新到Redis 5.0.7。升級你的GitLab實例時，你將需要在升級後重新啟動Redis，以便新版本處於活動狀態。
要重新啟動Redis，請運行： sudo gitlab-ctl restart redis。
如果你的實例具有使用Sentinel的Redis HA，則你需要按照特定的升級步驟進行操作，這些步驟與Omnibus GitLab軟件包一起安裝的更新GitLab中記錄，以避免停機。
GitLab 12.7致力於實現性能更高的差異視圖。作為這項工作的一部分，我們更改了差異在Redis緩存中的存儲方式。隨著緩存開始接收流量，升級其GitLab安裝的用戶可能會看到Gitaly負載暫時增加。如果這嚴重影響可用性，請禁用hset_redis_diff_caching功能標誌。
此版本的GitLab映射到GitLab Chart的主要版本GitLab Chart 3.0。如果你已使用Helm Chart安裝了GitLab，則需要採取一些手動步驟從以前的版本升級到GitLab Chart 3.0。有關分步說明，請參閱官方文檔。
Helm 2.15.x包含影響GitLab Helm圖表使用的錯誤。不要將Helm 2.15.x與GitLab Chart一起使用。有關Helm的受支持版本，請參閱官方文檔。
閱讀更多 蟲蟲安全 的文章
