愛立信電信軟體的持續交付

2021-09-17 06:16:04 字數 1453 閱讀 1782

最近幾年,devops原則和工具的應用已經改變了電信行業的服務交付流程。在2023年devops企業峰會倫敦大會上,愛立信公司發表了演講。他們的持續交付**概括了他們面臨的挑戰以及他們如何克服這些挑戰。

\\ 電信系統**商在部署系統時面臨的困難在規模、監管限制、健壯性、可用性需求方面是獨一無二的。之前,在乙個開發周期中,愛立信需要花7個周測試、6個月部署、2到3年開發,現在,他們只需要90分鐘測試、3個周部署、6個月開發。電信軟體的任何新版本都會向多個網路運營商推出。他們在最初採用這種比較新穎的實踐方法時遇到了困難,但隨著時間推移有了改善。乙個版本從正式發布到在運營商的節點上線之間的時間逐漸縮短。特性發布頻率為每月一次,而網路運營商可以選擇一月一次部署,也可以選擇一季度一次。

開發模型是首先需要改變的——從多個並行版本鏈轉為「單軌(single track)」。第乙個採用這種變革的產品是gprs服務支援節點——移動管理實體軟體——然後是「演進型分組閘道器(evolved packet gateway)」。演進分組核心是乙個電信框架,其目標是在4g網路上提供統一的語音和資料服務,而不是分別針對資料和語音採用資料報交換和電路交換。

\\ 轉型過程從2023年開始。首先開始的是流程變革——像小型跨職能團隊、產品經理任務分配、scrum管理員任命。他們引入了精益流程。類似**提交頻率這樣的指標被用來衡量他們的效率。然而,這導致了這些指標的誤用。在部分變革顯示出良好的前景後,領導者就有了增加團隊數量的壓力。這導致了更深層次的問題,包括快速增長的團隊以及低估了平台變革所要具備的條件。他們的平台不是對此有利的雲就緒平台。開發環境和ci實踐方法也還不成熟,加之程式結構也不成熟——這導致他們無法很好地監控團隊的進度。團隊的整體速度比以前慢了。2023年的一次盤點活動暴露出了這些問題。

\\ 他們進行了一些變革來解決這些問題。相對於速度,質量被賦予更高的優先順序,而且特別重視質量驗收測試。他們增加了乙個引入新團隊及新成員的新流程。在工具方面,團隊開始借助kernel virtual machine(kvm)實現虛擬化,這將他們的公升級時間由22個小時縮減為3個小時。kvm是乙個框架,是乙個執行在linux核心上的虛擬層,同時也是愛立信雲平台的重要組成部分。他們還採用了持續整合框架,其中一部分是基於docker的。他們還採用了乙個集中式的硬體分配模型,根據請求分配資源。這簡化了管理,從整體上提高了硬體的使用率。組織變革包括專案管理實踐、更好的規劃、特性團隊、每日站立會議以及分享知識的培訓(指導)。

\\ 愛立信的其他產品也已經採用了cd模型。這是電信行業

大趨勢的組成部分,傳統的服務交付方法已經讓位於devops。這也是由先前基於硬體的網路服務功能(nfv)的軟體虛擬化所推動的。這簡化了devops工具和實踐的應用,因為越來越多的功能改由軟體實現。

\\檢視英文原文:continuous delivery of telecom software at ericsson

愛立信電信軟體的持續交付

最近幾年,devops原則和工具的應用已經改變了電信行業的服務交付流程。在2017年devops企業峰會倫敦大會上,愛立信公司發表了演講。他們的持續交付 概括了他們面臨的挑戰以及他們如何克服這些挑戰。u0026 xd n u0026 xd n 電信系統 商在部署系統時面臨的困難在規模 監管限制 健壯...

持續交付的8條原則

軟體的發布或部署過程必須是可重複且可靠的。這就引出了下一條 所有操作的自動化!我很難相信 手工操作是可重複且可靠的 這種說法。所以一定要將所有重複性的操作變成自動化的,從而變得可靠。如果某件事情做起來很困難或者讓你覺得很痛苦,那麼就盡早且盡可能頻繁地去做。乍一看上去,這麼做太蠢了,因為人的直覺反應是...

談談持續整合,持續交付,持續部署之間的區別

經常會聽到持續整合,持續交付,持續部署,三者究竟是什麼,有何聯絡和區別呢?假如把開發工作流程分為以下幾個階段 編碼 構建 整合 測試 交付 部署 正如你在上圖中看到,持續整合 continuous integration 持續交付 continuous delivery 和 持續部署 continu...