我們在 GitLab 以兩種方式處理軟件修復 - 手動和自動。 請繼續閱讀，了解有關發布經理通過自動部署到 gitlab.com 來創建和交付重要更新的工作的更多信息，以及為使用其安裝的用戶提供的修復程序。
我建議在您的智能手錶上設置提醒：每個月的 22 日，在其設施中使用 GitLab 的用戶都可以看到我們產品當前版本的更新。 在每月版本中，您可以找到新功能、對現有功能的增強，並且經常會看到社區工具或合併請求的最終結果。
但是，實踐表明，軟件開發很少是沒有缺陷的。 當發現安全錯誤或漏洞時，交付團隊的發布經理會使用自己的設置為我們的用戶創建補丁。 Gitlab.com 在 CD 過程中更新。 我們將此 CD 過程稱為自動部署，這樣就不會與 GitLab 中的 CD 功能混淆。 這個過程可以包括用戶、客戶和我們的內部開發團隊提交的拉取請求的建議，因此發布補丁的無聊問題可以通過兩種截然不同的方式解決。
«我們確保開發人員所做的一切每天都會部署到所有環境中，然後再部署到 GitLab.com”，解釋說 ，基礎設施部高級技術經理。 ”考慮您的安裝的版本，例如 gitlab.com 部署的快照，我們為此添加了單獨的構建步驟，以便我們的用戶可以使用它在他們的設施上安裝“。
無論 bug 或漏洞如何，gitlab.com 客戶都會在發布後不久收到修復程序，這是自動 CD 流程的好處。 針對自定義安裝的用戶的修復需要發布經理單獨準備。
交付團隊正在努力實現創建版本所涉及的大部分流程的自動化，以減少 （平均生產時間，即生產所花費的時間），從開發人員處理合併請求到部署到 gitlab.com 的時間段。
«交付團隊的目的是確保我們作為一個公司能夠更快地工作，或者至少加快交付人員的速度，對吧？”馬林說。
gitlab.com 客戶及其安裝的用戶都受益於交付團隊為縮短週期時間和加快部署所做的努力。 在本文中，我們將解釋這兩種方法的異同。 ，以及我們的交付團隊如何為內部用戶準備補丁，以及我們如何通過自動部署使 gitlab.com 保持最新狀態。
發布經理做什麼的？
團隊成員每月 我們在用戶的設施中向用戶發布的版本，包括版本之間可能發生的修復和安全版本。 他們還負責公司向自動、持續部署的過渡。
Marin 解釋說，內部版本和 gitlab.com 版本使用類似的工作流程，但運行時間不同。
首先，無論發布類型如何，從應用程序在 gitlab.com 上啟動的那一刻起，發布經理就確保 GitLab 的可用性和安全性，包括確保相同的問題不會落入客戶的基礎設施中自己的能力。
一旦 Bug 或漏洞在 GitLab 中被標記為已修復，發布經理應評估是否將其包含在用戶安裝的補丁或安全更新中。 如果他認為某個錯誤或漏洞值得更新，則準備工作就會開始。
發布經理必須決定是否準備修復程序或何時部署它 - 這在很大程度上取決於情況的上下文，”與此同時，機器並不像人那樣善於管理環境馬林說。
關於修復的所有內容
什麼是修復以及為什麼我們需要它們？
發布經理根據錯誤的嚴重程度決定是否發布修復程序。
錯誤根據其嚴重程度而有所不同。 因此，S4 或 S3 錯誤可能是風格上的，例如像素或圖標未對齊。 Marin 解釋說，這同樣重要，但它不會對某人的工作流程產生太大影響，這意味著不太可能針對這些 S3 或 S4 錯誤創建修復程序。
然而，S1或S2漏洞意味著用戶不得升級到最新版本，或者存在影響用戶工作流程的重大錯誤。 如果它們進入跟踪器，許多用戶都遇到過它們，因此發布經理立即開始準備修復。
一旦 S1 或 S2 漏洞的補丁準備就緒，發布管理器就會觸發補丁的發布。
例如，GitLab 12.10.1 補丁是在發現幾個阻塞問題之後創建的，並且開發人員修復了導致這些問題的根本問題。 發布經理評估了分配的嚴重級別的正確性，確認後啟動了發布修復程序的流程，該修復程序在發現阻塞問題後的 XNUMX 小時內準備就緒。
當大量 S4、S3 和 S2 積累時，發布經理會查看上下文來確定發布修復的緊急程度，當達到一定數量時，將它們全部合併並發布。 博客文章中簡要描述了發布後修復或安全更新。
發布經理如何創建補丁
我們使用 GitLab CI 和其他功能（例如 ChatOps）來創建補丁。 發布經理通過激活我們內部渠道上的 ChatOps 團隊來觸發修補程序版本 #releases 在鬆弛中。
/chatops run release prepare 12.10.1ChatOps 在 Slack 中工作，觸發不同的事件，然後由 GitLab 處理和執行。 例如，交付團隊設置 ChatOps 來自動化發布補丁。
一旦發布經理在 Slack 中啟動 ChatOps 團隊，其餘工作就會使用 CICD 在 GitLab 中自動進行。 在發布過程中，Slack 中的 ChatOps 和 GitLab 之間存在雙向通信，因為發布經理會激活該過程中的一些主要步驟。
下面的視頻提供了為 GitLab 準備補丁的技術流程。
gitlab.com 自動部署的工作原理
用於更新 gitlab.com 的過程和工具與用於創建補丁的過程和工具類似。 從發布經理的角度來看，更新 gitlab.com 需要更少的手動工作。
我們不使用 ChatOps 運行部署，而是使用 CI 功能，例如 ，發布經理可以使用它安排在所需時間執行的某些操作。 與手動流程不同，有一個每小時定期運行一次的管道，它會下載對 GitLab 項目所做的新更改、打包並安排部署，並自動啟動測試、QA 和其他必要步驟。
“因此，在 gitlab.com 之前，我們在不同環境中運行了很多部署，在這些環境狀況良好並且測試顯示出良好結果之後，發布經理開始了 gitlab.com 部署活動，”Marin 說。
支持 gitlab.com 更新的 CICD 技術使整個過程自動化，直到發布經理必須手動開始將生產環境部署到 gitlab.com。
Marin 在下面的視頻中詳細介紹了更新 gitlab.com 的過程。
交付團隊還做什麼
更新 gitlab.com 和在客戶自己的設施中向客戶發布補丁之間的主要區別在於，後者過程需要發布經理更多的時間和更多的手動工作。
“有時，我們會延遲向客戶安裝補丁，因為報告的問題、工具問題，以及發佈單個補丁時需要考慮的細微差別，”Marin 說。
交付團隊的短期目標之一是減少發布經理的手動工作量以加快發布速度。 該團隊正在致力於簡化和自動化發布流程，以消除低嚴重性問題（S3 和 S4、 約譯員）。 關注速度是一個關鍵性能指標：您需要減少 MTTP（從接受拉取請求到將結果部署到 gitlab.com 的時間），從當前的 50 小時減少到 8 小時。
交付團隊還致力於將 gitlab.com 遷移到基於 Kubernetes 的基礎設施。
編者註：如果你已經聽說過 Kubernetes 技術（我毫不懷疑你也聽說過），但還沒有親手感受過，我建議參加在線強化課程 ，將於 28 月 30 日至 XNUMX 日舉行，以及 將於14月16日至XNUMX日舉行。 這將使您能夠自信地駕馭該技術並使用它。
這兩種方法具有相同的目標：向 gitlab.com 及其設施中的客戶快速交付更新。
對我們有什麼想法或建議嗎？
每個人都可以參與 GitLab 的開發，我們歡迎讀者的反饋。 如果您對我們的交付團隊有任何想法，請隨時 標記的 team: Delivery.
來源： www.habr.com