最近幾年，devops原則和工具的應用已經改變了電信行業的服務交付流程。在2023年devops企業峰會倫敦大會上，愛立信公司發表了演講。他們的持續交付**概括了他們面臨的挑戰以及他們如何克服這些挑戰。
\u0026#xd;\n\u0026#xd;\n
電信系統**商在部署系統時面臨的困難在規模、監管限制、健壯性、可用性需求方面是獨一無二的。之前，在乙個開發周期中，愛立信需要花7個周測試、6個月部署、2到3年開發，現在，他們只需要90分鐘測試、3個周部署、6個月開發。電信軟體的任何新版本都會向多個網路運營商推出。他們在最初採用這種比較新穎的實踐方法時遇到了困難，但隨著時間推移有了改善。乙個版本從正式發布到在運營商的節點上線之間的時間逐漸縮短。特性發布頻率為每月一次，而網路運營商可以選擇一月一次部署，也可以選擇一季度一次。
\u0026#xd;\n\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n
開發模型是首先需要改變的——從多個並行版本鏈轉為「單軌（single track）」。第乙個採用這種變革的產品是gprs服務支援節點——移動管理實體軟體——然後是「演進型分組閘道器（evolved packet gateway）」。演進分組核心是乙個電信框架，其目標是在4g網路上提供統一的語音和資料服務，而不是分別針對資料和語音採用資料報交換和電路交換。
\u0026#xd;\n\u0026#xd;\n
轉型過程從2023年開始。首先開始的是流程變革——像小型跨職能團隊、產品經理任務分配、scrum管理員任命。他們引入了精益流程。類似**提交頻率這樣的指標被用來衡量他們的效率。然而，這導致了這些指標的誤用。在部分變革顯示出良好的前景後，領導者就有了增加團隊數量的壓力。這導致了更深層次的問題，包括快速增長的團隊以及低估了平台變革所要具備的條件。他們的平台不是對此有利的雲就緒平台。開發環境和ci實踐方法也還不成熟，加之程式結構也不成熟——這導致他們無法很好地監控團隊的進度。團隊的整體速度比以前慢了。2023年的一次盤點活動暴露出了這些問題。
\u0026#xd;\n\u0026#xd;\n
他們進行了一些變革來解決這些問題。相對於速度，質量被賦予更高的優先順序，而且特別重視質量驗收測試。他們增加了乙個引入新團隊及新成員的新流程。在工具方面，團隊開始借助kernel virtual machine（kvm）實現虛擬化，這將他們的公升級時間由22個小時縮減為3個小時。kvm是乙個框架，是乙個執行在linux核心上的虛擬層，同時也是愛立信雲平台的重要組成部分。他們還採用了持續整合框架，其中一部分是基於docker的。他們還採用了乙個集中式的硬體分配模型，根據請求分配資源。這簡化了管理，從整體上提高了硬體的使用率。組織變革包括專案管理實踐、更好的規劃、特性團隊、每日站立會議以及分享知識的培訓（指導）。
\u0026#xd;\n\u0026#xd;\n
愛立信的其他產品也已經採用了cd模型。這是電信行業
大趨勢的組成部分，傳統的服務交付方法已經讓位於devops。這也是由先前基於硬體的網路服務功能（nfv）的軟體虛擬化所推動的。這簡化了devops工具和實踐的應用，因為越來越多的功能改由軟體實現。
\u0026#xd;\n\u0026#xd;\n
檢視英文原文：continuous delivery of telecom software at ericsson
愛立信電信軟體的持續交付
最近幾年，devops原則和工具的應用已經改變了電信行業的服務交付流程。在2017年devops企業峰會倫敦大會上，愛立信公司發表了演講。他們的持續交付 概括了他們面臨的挑戰以及他們如何克服這些挑戰。電信系統 商在部署系統時面臨的困難在規模 監管限制 健壯性 可用性需求方面是獨一無二的。之前，在乙個...
持續交付的8條原則
軟體的發布或部署過程必須是可重複且可靠的。這就引出了下一條 所有操作的自動化！我很難相信 手工操作是可重複且可靠的 這種說法。所以一定要將所有重複性的操作變成自動化的，從而變得可靠。如果某件事情做起來很困難或者讓你覺得很痛苦，那麼就盡早且盡可能頻繁地去做。乍一看上去，這麼做太蠢了，因為人的直覺反應是...
談談持續整合，持續交付，持續部署之間的區別
經常會聽到持續整合，持續交付，持續部署，三者究竟是什麼，有何聯絡和區別呢？假如把開發工作流程分為以下幾個階段 編碼 構建 整合 測試 交付 部署 正如你在上圖中看到，持續整合 continuous integration 持續交付 continuous delivery 和 持續部署 continu...