![](http://image.uc.cn/s/wemedia/s/upload/2024/7904b1d7fb445103caba0e8c76e8e6bd.jpg)
GitHub 針對開發者在其平台上頻繁執行的代碼推送操作推出了一系列技術革新,旨在提升操作的穩定性與效率。這些升級措施不僅解決了潛在的技術問題,還爲定期向 GitHub 推送代碼的用戶提供更流暢的體驗。
GitHub 的一位軟件工程師 William Haltom 詳細闡述了這次技術升級的背景。Haltom 首先分享了向 GitHub 推送代碼會觸發一系列動作,例如同步拉取請求、分發 Webhook、觸發工作流、安裝應用、發布 GitHub Pages 以及更新 Codespaces 配置。此外,每次推送還會激活 GitHub 內部的 60 多個流程,這些流程爲開發者提供了不同的特性和自動化工具。
在過去,GitHub 依賴一個叫作 RepositoryPushJob 的大型單體後台作業來處理所有由代碼推送觸發的動作。這個作業在 GitHub 的 Ruby on Rails 單體應用中,按順序執行所有的推送處理邏輯。然而,由于作業的規模龐大且複雜,導致了一些問題。在作業內重試個別任務非常困難,而且大多數步驟根本沒有進行重試。
缺乏可靠的重試機制意味著作業早期階段的錯誤可能會産生連鎖反應,影響後續的步驟,從而引發一系列的潛在問題。
![](http://image.uc.cn/s/wemedia/s/upload/2024/cfa6811a66e24841bacfcdd944c2f6c7.jpg)
來源:我們如何改進 GitHub 的推送處理邏輯
GitHub 對其代碼推送流程進行了徹底的改革,將原本漫長且順序執行的作業分解爲多個獨立且並行運行的流程。爲此,他們創建了一個新的 Kafka 主題用于廣播推送事件。根據任務所歸屬的服務或邏輯關系——例如它們之間的依賴關系和重試需求——對衆多的推送處理任務進行了細致的分析和分類。
每個任務組都重新分配到了一個新的後台作業中,這個作業有明確的所有者和適當的重試機制。然後,這些作業被配置成可以響應由新的 Kafka 事件所觸發的信號。
爲了支持這種架構,GitHub 使用了一個內部系統來響應 Kafka 事件並安排後台作業的隊列。包括開發 Kafka 事件的可靠發布者、設置專用的工作池來管理增加的作業數量、增強可觀測性以監控推送事件流,以及建立一致的特性標志系統,以確保新系統的安全發布。
![](http://image.uc.cn/s/wemedia/s/upload/2024/d077863537c276fd8360da16bb76fcd4.jpg)
來源:我們如何改進 GitHub 的推送處理邏輯
GitHub 最近在 GitHub Actions 中引入對 Arm64 的支持,爲開發者提供了在 Arm 架構上發布軟件的 Arm 構建的鏡像,這則消息在技術社區 Hacker News 上引發了廣泛的討論。一位 GitHub 和 Hacker News 的用戶 Obviyus 表示他對加入對 Arm64 的支持感到非常興奮,他們之前一直依賴自托管的 Arm 運行器來進行項目開發。他指出,在他們的小型 Arm VPS 上編譯代碼可能會顯著地拖慢其他任務的運行速度。爲此,他對官方提供對 Arm64 的支持表示熱烈歡迎,認爲這是一個迫切需要的改進。
今年早些時候,Hacker News 上的一篇帖子還討論了 Copilot Workspace,這是一項創新工具,旨在簡化開發流程,允許開發者使用自然語言進行頭腦風暴、規劃、編碼、測試和項目執行。
Haltom 進一步解釋了架構改革的結果,他指出,將原本龐大的流程拆解爲更小、更獨立的部分,問題的影響範圍得到了有效控制。推送處理邏輯中某一部分的問題不再會引起連鎖反應,影響到其他部分,從而提高了穩定性和可靠性。此外,這種解耦也減少了各個部分之間的依賴性。
此外,新架構還明確了所有權,將推送處理代碼的責任分配給了超過 15 個服務的所有者。這樣的分配機制使得各個團隊能夠在不引發意外後果的前提下添加和叠代推送功能。最後,由于作業的規模更小、複雜度降低,整個推送處理過程變得更加可靠。
查看英文原文:
https://www.infoq.com/news/2024/06/github-push-process-enhancement/