按照十年一代的移动通信的发展路径，到现在不知不觉5G已经快到整个发展周期的中间点的。从软件工程角度来考虑，5G就是属于整个软件项目中的一类。但是，很明显，5G网络包括下一个十年周期的6G都会是整个软件产业最具有代表性的那一类，不仅仅其软件体系中融入了几乎当前所有的最新的开发理念和方法论，而且所使用到的技术也几乎涵盖跟通信、网络、移动互联、cloud甚至AI/ML等相关的所有领域。

肉眼可见，5年后6G也会融入那些现在已经计划和提出，到时候将大规模盛行的更新的技术和理念，比如所谓的量子通信、AI原生网络、全息通信、分布式网络架构等等。

2.1 5G这块蛋糕有被更细的切分的趋势

自从3GPP的5G盛大开启之后，传统的玩家依然踏着之前4G甚至3G的步伐，按部就班地开启了十年的5G蓝图。但是，就有“好事者”掐指一算，发现如果再用十年仅仅给4G网络再增加“1G”与产业界包括硬件、芯片等行业的发展的所谓“摩尔定律”严重不符。如果还是按十年来作为新一代技术和网络的话，那么，新的网络和技术就不能仅仅满足于这“1个G”的单一增量，一方面需要增加更多的吞吐率，另一方面，比如让移动通信扩展为“无所不能的”新型智能、数字、移动、大规模的通信网络。

2.1.1 以ORAN为代表的“搅局者”

其实，5G的生态逐渐成形之际，包括OPEN-RAN（ORAN）在内的各种称呼的RAN让人目不暇接，简单化就叫做XRAN。但最终ORAN以其磅礴气势在业界脱颖而出。最大的行动计划就是比对于3GPP的多个RAN的工作组WG，RAN联盟也逐渐组建了超过十个工作组，最有分量的就是WG4，关于eCPRI接口的C/U/S-plane和M-plane的详细的规范的成熟。而且，ORAN规范似乎在可读性方面有意地在超越3GPP那种冷冰冰的、“没有人味”的行文方式。

ORAN的登场，仿佛一个摇滚乐队突然闯入了一场古典音乐的交响乐演出——既打破了既定规则，又让人忍不住鼓掌叫好。作为3GPP定义的5G生态系统中的“搅局者”，ORAN毫不羞涩地大喊：“开放接口！自由组合！让创新飞得更高一点！”这就像是一本传统的菜谱被打翻，厨师们一边抱怨锅碗瓢盆的乱糟糟，一边又忍不住尝试这些意想不到的新配方，期待着做出一道让食客大吃一惊的美味。

传统的3GPP体系，像一个稳如泰山的古典城堡，有着层层叠叠的复杂规则，每一个接口、每一个功能模块都像一块严丝合缝的砖石，保证网络平稳运行。而ORAN却像一个拆墙的建筑师，挥舞着“开放架构”的大旗，公开化和细化接口，鼓励更多厂商加入，随心所欲地“拼搭”他们的技术模块。这种“拆墙自由”的模式让整个行业既兴奋又焦虑——一方面，谁不想加入这场看起来充满无限可能的技术狂欢？另一方面，曾经那个有条不紊的生态系统，现在看起来倒像是一个闹哄哄的开放市场，谁都有可能拿着自己的“摊位”喊出一两个抢眼的主意。

当然，挑战随之而来。行业巨头们就像传统舞者，踩着3GPP的节拍，一招一式都精准到位，但面对ORAN这股“街舞风”，总有些不适应：节奏怎么乱了？套路怎么破了？甚至连舞池的边界都被重新划定了！不过，这种新旧碰撞的冲突也让人不禁感叹：“这不是挑战，这明明是进化！”

ORAN让整个产业看到了一个可能性：未来的5G网络，或许不再是一个封闭的城堡，而是一个开放的游乐园。更多创新者可以带着自己的“游乐设施”入场，每个功能模块都像一块乐高积木，拼出一个独一无二的未来网络。这样的想法着实让人兴奋——谁会不期待看到传统和创新在同一个舞台上共同演绎出一场前所未有的盛宴呢？

但同时，这种未来又让人难免带着一丝无奈和矛盾。毕竟，稳定性和可靠性是通信网络的生命线，而这种“天才与疯子齐飞”的创新模式，难免让人担忧是否会踩到一些无法预料的坑。就像在摇滚音乐中添加交响乐的元素，初听可能不习惯，但再一品味，那种前所未有的融合却有着令人上瘾的魅力。

所以，ORAN的到来，既像是一场搅局，也像是一场革命。无论是拥抱还是抗拒，我们都已经站在了这个新纪元的门槛前。唯一能确定的是，这场5G的“开放秀”，才刚刚开始。

2.1.2 ORAN带来的新的市场和机会

5G行业的“搅局者”的出现，虽然说掀起了一定的旋风，搅得水有点混，而这个业内的水本来还是比较清澈的，虽然说其中的鱼越来越少，但是，这些鱼在清水里还是能看得很清楚的。水至清则无鱼，现在水混了，可能鱼就会养得肥，也可能会养得多了，这样这股旋风就会让外界的虎视眈眈的猎手嗅到了腥味，纷纷杀将过来。

举个例子来说，因为ORAN对eCPRI接口进行了详细的定义，专门进行5G ORU的开发的公司目前大概就有几十到一百家，这些厂家除了传统的几个通信大厂爱立信、诺基亚等之外，更多的是传统的通信集成商和一些初创公司，比如富士康、富士通、benetel、BMI等等（据说国内也有好几家）。

还有一个例子，就是基于ORAN和CloudRAN的O-DU，其硬件是部署于通用的服务器（COTS），但是在处理物理层的大规模数据处理和运算的时候，就显得力不从心了。所以，业界普遍采用了使用加速卡（Accelerator）的方式来完成大部分的物理层的数据处理流程。所以，有很多的厂家专门设计生产所谓的L1加速卡，而且在O-RU端使用专门的FPGA的芯片主要处理IFFT（OFDM调制）等流程。这样，又会形成大量的厂家生产这些专用芯片。

2.2 新的参与者不希望在起跑线上“徘徊”

ORAN的发起现在看来并不是一夜之间就酝酿完成的，实际上也是经过众多的参与者的“思想斗争”而慢慢被多数人不同程度地接受。

ORAN Alliance联盟的发起，可以追溯到一群志同道合的网络运营商和技术驱动者对传统电信产业“封闭架构”模式的不满与挑战精神。这些先锋者看到了传统RAN（无线接入网）领域中，由少数大厂主导的封闭式生态系统所带来的局限性，例如高昂的成本、创新的阻碍以及灵活性的缺乏，于是决定“撬动”这个市场，推动开放和多样化。所以说，实际上ORAN首先是由主流的运营商发起和推动的，因为对他们而言，无论如何是新的生态和新的利益的机会。相对而言，对于厂家而言，特别是传统的几家大厂来说，大家还是面面相觑，很难下嘴咬下这第一口。而对于那些正在准备进入5G、6G市场的年轻的startup创业者来说，无疑燃起了参与竞争再创辉煌的雄心和热情。

实际上，ORAN联盟最初是由以下两大组织的整合和合作发展而来：

第一，C-RAN联盟，全称为“China Mobile-led Centralized Radio Access Network（C-RAN）联盟”，由中国移动等亚洲电信运营商于2014年左右发起，专注于推动无线接入网的集中化和虚拟化技术。

第二，xRAN论坛，由AT&T、Deutsche Telekom（德国电信）、Verizon和NTT DoCoMo等北美及欧洲主流运营商在2016年左右成立，目标是推动无线接入网架构的标准化与开放化。

2018年2月，C-RAN联盟与xRAN论坛正式合并，成立了今天的O-RAN Alliance（开放无线接入网联盟）。这一里程碑事件标志着ORAN正式从区域性的技术尝试上升为全球性的产业变革。

虽然说，一开始ORAN联盟刚刚成行的时候，大部分的传统的大厂态度是有点暧昧和羞羞答答，但几年以后，基本上所有的相关公司都被连拉带拽地加入了ORAN联盟，除了个别有想法的除外。总之，最终ORAN的大潮已经是不可阻挡的了，开花结果似乎是不言而喻的事情，具体开什么花，结什么果，我们将拭目以待。

2.3 5G开发项目已经不看中“个人英雄主义”

在5G开发的舞台上，曾经的“个人英雄主义”就像一把独奏的小提琴，虽然音色清亮动人，但在如今这场庞大的交响乐中，早已显得孤单和微弱。开发厂家们早就明白，5G这个庞然大物的构建，不是某个“技术天才”一个人的战场，而是一群才华横溢的团队共同挥洒汗水和智慧的协奏曲。这是一种对效率和质量的双重追求，一种将个人光芒融入集体智慧的必然选择。

试想，5G系统是一个巨大的拼图：有底层协议的细密运算，有硬件设备的繁复对接，还有天线参数的精确调校。如果仅靠一个“孤胆英雄”，那不仅累到他“代码写到怀疑人生”，还可能把项目拖到石器时代的进度。于是，厂家们纷纷祭出了“团队协作”的法宝，就像一支攻坚小队，每个人各司其职，有的负责打地基（硬件设计），有的负责盖房顶（软件优化），还有的负责选窗帘（用户体验）。只有这样，整个项目才能既快又稳地推进。

当然，有人可能会怀念过去那种“天才工程师一人包揽全场”的浪漫传说。可是现实是，今天的5G开发，项目复杂度已经像一锅放了几十种料的火锅，每个人的舀勺子和配料表都需要严格协调。如果有人一时兴起，多加了几勺辣椒，最后整个锅都可能变得“辛辣得让所有人落泪”。所以，现代5G开发强调的，是团队的整体节奏，而非个人的独奏表演。

更重要的是，团队协作的理念也带来了对项目管理和代码管理的深度重视。如今的开发者们不再是一群“埋头苦写代码的码农”，而更像是一群训练有素的“建筑师”。每一行代码都像砖块一样，需经多人审核，确保“建房”的每个步骤都符合设计蓝图。而版本管理工具和敏捷开发方法就像团队的“作战指挥中心”，把每个人的努力整合起来，确保这个“房子”最终不仅美观，还能抵御风雨。

所以，现在的5G开发，更像是一场复杂的马拉松接力赛，而不是短跑冲刺。个人英雄主义固然令人怀念，但在5G的赛场上，它已经让位给了一种更高级的美学：团队合作的和谐乐章。这是一种用无数人的默契和汗水交织而成的辉煌，是集体智慧在新时代技术开发中的完美体现。

未来，当我们看到5G网络在生活中无处不在的身影时，不妨想想那些埋头协作的开发团队。正是他们的“众人拾柴”，才让这场科技的火焰熊熊燃烧，让我们感叹：个人英雄主义固然精彩，但团结和协作，才是真正的大英雄。

这里说一个我自身的一个生动的例子，前不久也参与了一个某个厂家的5G的startup的项目，基本上从项目一上马就全程参与的我，原以为我在其中某个重要岗位会是不可缺少的。因为，该岗位涉及到软件、硬件、网络连接以及特定的配置等等，以为别人很难替代我从事这个岗位的活。所以，虽然那段时间几乎所有的相关公司都在掀起了裁员的风暴，但是，我就天真的以为，不会影响到我自己的，但是结果你们都应该猜到了，我还是突然间被通知离开这个项目，没有任何的提前迹象和预热，就这么毅然决然地把我这个“元老”给一脚踢开了。

2.4 DevOps和CICD正在盛行

针对5G这种非常复杂和需要长期迭代的项目，为了实现高效迭代，就自然会被引入现代的开发理念、工具和方法。这就是引入DevOps和CICD等的直接动力。可以说，在5G开发这片广袤的“高科技农场”上，DevOps和CICD正迅速成为主流，就像现代化的智能机械替代了传统的锄头和牛耕，给这个复杂又精密的行业带来了前所未有的效率和活力。厂家们发现，曾经的瀑布式开发流程，就像建造金字塔——一次性画好图纸，一砖一瓦慢慢垒，等到顶端封顶时，客户需求早已变了样。而如今，DevOps和CICD的引入，则更像是开启了一条流水线，快速迭代、持续交付，让5G的每一寸代码都能紧跟需求的脚步。

想象一下，5G项目的开发就像搭建一个庞大的乐高城堡，传统的瀑布式开发模式则像“事先写好说明书然后全程照搬”的操作方式，耗时漫长且容错率低。可现实情况是，说明书一写好，客户就改主意了：“那个基站模型能不能换成更未来感的？”“AI调度模块能不能增加一点弹性？”这样的需求变化在5G行业是家常便饭。DevOps和CICD的出现，正是应对这种需求变动的“灵丹妙药”。

通过DevOps，团队实现了开发与运维的无缝对接，就像开发者和运维人员终于“住进了同一个群聊”，不再因为版本冲突或部署失误而互相“甩锅”。CICD则更进一步，把代码集成和交付变成了一条流畅的“高速公路”：每一次代码提交都能自动触发构建、测试和部署，就像按下“启动键”，系统自己就跑起来了。再也不用担心“等发布时才发现功能崩了”的惨剧发生。

这些工具的优势显而易见：开发周期大幅缩短，产品质量显著提高，团队协作更加高效。甚至连那些资深开发者都忍不住感叹：“用过CICD，再也回不去手工打包的年代了。”更重要的是，CICD还让团队具备了更强的容错能力，任何小问题都能在早期被发现并迅速修复，不会等到问题积累成“地震”级别时才亡羊补牢。

对于5G这种复杂的长期项目，DevOps和CICD不仅是一场技术革命，更是一场理念的转变。它鼓励团队以小步快跑的方式前进，每次更新都如水滴般注入整个项目的“大海”，既柔和又有力，逐渐推动整个系统向着完美靠拢。这种敏捷、灵活且高效的开发方式，让5G厂家们不禁感慨：“原来开发也可以这么从容又快乐。”

总的来说，DevOps和CICD的盛行，标志着5G行业从“体力劳动”迈向“智能化”的质变过程。它们让5G开发不再是一场耐力极限的长跑，而是一次次精准而优雅的百米冲刺。这不仅是技术的进步，更是对整个行业的一次解放，让我们更快地迈入5G所描绘的美好未来。

2.5 Agile敏捷开发

在5G开发这场激烈的科技竞赛中，Agile敏捷开发的引入，就像给一艘庞大的航母装上了灵活的转舵系统，让这个曾经笨重而缓慢的巨型工程变得轻快且机动。厂家们逐渐发现，传统的瀑布式开发方法虽然听起来稳扎稳打，但在面对快速变化的市场需求时，却像一个戴着脚镣跳舞的舞者，难以跟上节奏。而敏捷开发的到来，就像打开了全新的世界大门，以灵活应变、快速迭代的方式，让5G开发如虎添翼。

想象一下，5G开发的过程就像在一片未知的荒野中建造未来之城，瀑布式开发更像是“一口气规划好所有街道和建筑，再一砖一瓦慢慢盖”，然而，等到竣工时，客户的需求早已从“小镇风情”变成了“赛博朋克未来感”。而敏捷开发则不同，它的理念是：不用一次性铺满整个城市，而是先造出一条最需要的主干道，接着根据用户反馈，逐步完善城市的其他部分。这种“边建边调”的方式，既高效又贴合实际需求。

敏捷开发的核心是把一个大项目切分成许多个“小块”，每个“小块”都可以在短时间内完成，并不断调整方向。对于5G开发来说，这种方式尤为重要。5G项目的复杂性和多样性，使得需求变更成为常态，而敏捷开发的“拥抱变化”正好化解了这一痛点。团队可以通过每日站会快速同步进度，通过迭代开发不断完善功能，就像厨师不断品尝汤的味道，确保每一步都在正确的轨道上。

敏捷开发的引入还改变了团队的协作方式。开发人员不再是各自为战的孤岛，而是成为了协作紧密的团队成员，每个人都为最终目标贡献自己的力量。客户也从“只在项目验收时露面”变成了“全过程参与”，他们的需求和意见被即时纳入开发过程。这种方式不仅让开发团队更加高效，也大大提高了客户的满意度，堪称“双赢”的典范。

更令人称赞的是，敏捷开发还带来了更高的容错率。在敏捷的世界里，错误不是失败，而是学习的机会。团队可以在早期发现问题并迅速修正，而不是等到“最后一刻才抓狂地补救”。这种快速迭代、实时调整的机制，让5G开发的进程更加平稳和可靠。

所以说，敏捷开发的引入，就像为5G开发装上了涡轮增压器，使其从一场漫长的拉锯战，变成了一次次短小而精悍的冲刺。它让团队从繁琐的流程中解放出来，以更加灵活高效的方式去应对5G这个复杂的技术挑战。最终，当我们享受5G网络的高速和便捷时，不妨向这套“灵活变通”的开发理念致敬——正是它，赋予了这场科技革命更快、更优雅的节奏感。

2.6 5G项目中的DevOps/CICD/Agile

好几年前，作为一个项目开发的参与者和伪码农的身份，就被DevOps这个概念所严重“侵袭”，那是公司为每个项目成员购买了DevOps的整个课程，并且买的是个老外的课程，全英文的那种。虽然说，有一种又被这种所谓的高价的经典课程所忽悠的感觉，但还是在断断续续的课程学习中获得了不少在DevOps体系中包含的概念和理念，而且没想到，以后，在我接触到的几乎所有的大中型项目中，DevOps体系已经变成了一个业界默认的开发生态和方法论了。

2.6.1 5G项目基于DevOps的团队建设

从我接触和了解到的为数不多的5G开发项目来看，很多概念和设想都是大体一致的，特别是针对DevOps的体系和循环。

根据DevOps这个体系和迭代环，其团队的组建和建设需要依据上述循环所涉及到的所有环节进行对应。只是，针对不同的环节和岗位，不同的开发项目会有侧重点的差别。作为一个纯纯的码农，你可能只看重你的任务如何通过你的code在整个软件体系中实现，但是，你每天除了用大量的时间写你的function、class、object以及if语句等等等等的时候，你还得，在一大早被拎起来参加standup晨会，还要汇报你的进度、成绩和问题。当你完成了某个MAC层调度算法的代码修复之后，先完成了Component Test，然后，你希望把你的代码更新写入产品中并做整体的E2E测试，但是，你申请的这个PR（Push Request）需要等待一推code owner的审核和批准，好不容易等待所有关键owner上线之后，有张三和李四发现新的问题，需要你重新检查和更新…..

有一个经典的案例，几年前，一名程序员在WTS Paradigm这家美国企业资源规划软件（ERP）开发商的办公楼持枪杀人，而导致该程序员痛下决心的直接原因竟然是“同事不写注释，不遵循驼峰命名，括号换行，最严重的是天天使用 git push -f 参数强行覆盖仓库等因素”

所有的这些情况和案例，说明了形成团队的力量正是DevOps这个生态的核心，也说明，一个大型开发项目高效高质量地完成，基本前提是有一个最佳化合理配置的基于DevOps的团队体系和岗位体系。

1. 核心开发团队

比如一个典型的全新的startup ORAN的gNB项目，首先需要确定核心开发团队的阵容，O-CU团队，O-DU团队，L1团队、O-RU团队。但是具体每一个核心团队内部可以做如下的细分：

O-CU：分协议栈，比如L3（即RRC）、SDAP、PDCP、E1接口，或者在再细分为各自的Control-plane和User-plane；

O-DU：分协议栈，比如 RLC、MAC、scheduler、FAPI接口、F1接口等

L1：HL1（高层l1），LL1（低层l1，包含ORU集成），加速卡集成等

O-RU：也包含LL1、RF、硬件

2. 除了核心开发任务之外，需要有支持OAM、SMO包括M-plane等的OAM开发团队

3. 产品设计团队，负责对全线产品，以及各个产品模块根据总体的产品目标和市场需求，以及客户需求进行设计和规划

4. Platform团队，主要职责是适配5G ORAN在COTS服务器上的运行，包括cloud native和网络搭建的基础设施团队比如：Lab Infrastructure。

5. 传输层团队，负责典型接口的低层搭建和连接，比如支持eCPRI的Fronthaul， 支持F-C/U接口的Midhaul以及N2/N3接口的Backhaul等。特别是Fronthaul，需要根据ORAN规范做有针对性地开发适用于C/U/S/M-plane所有需求的传输链路。

6. 测试团队 测试团队职责不仅仅是执行测试本身，实际上需要在整个DevOps体系中起一个贯穿始终和迭代的作用。所以，整个测试团队可能会包含测试员（Tester）、自动化（Automation）、连续自动集成测试（CI， Continous Integration）、连续自动部署和递交CD（Continous Deploy/Delivery）

7. 专门用于维护和管理全产品线开发和交付集成的DevOps团队

2.6.2 Agile在5G项目中的运转方式

Agile从字面上看，也看不出有啥不得了的武林秘籍，可是，把它提炼出来并付诸实施，就被人赋予了丰富的内涵和强大的正能量。从网上找到的概念是说：

Agile 的核心是 “快速交付、高效协作、灵活应变、持续改进”。它的意义不局限于一种方法，而是开发团队如何思考问题、解决问题并交付有意义的成果。敏捷的实践方式因项目类型、团队规模和业务目标不同而有所调整，但它始终以客户满意、团队协作和持续改进为中心。”，我们前面提到的因为同事代码提交不规范而动枪的例子正是在这种理念之下的出现的一个极端的问题实例。

我没有做更细致的调查，这里仅仅给出我所理解的简单的Agile在5G项目中的应用的思路。

1. 需求分析阶段

名义上需求来自于客户，有客户给出需求，并且使用用户故事（User Stories） 表达需求，强调从用户视角定义功能，而不是从技术视角。但实际上，这个需求是面向3-5年以后的市场，对于初创项目来说，没有客户，你的产品定位来源于项目高层的“领导”的卓越的市场洞察力和遇见能力。当然，这里缺少不了大量的市场调研和模型推演。但是，有句话，计划比不了变化，有可能几年以后，你的产品会与那时的市场需求背道而驰。

不管怎样，一旦项目启动，大方向确定之后，接下来就需要将这一大型长时间的项目需求拆解为小的、可交付的增量工作项，每个迭代专注于部分高优先级需求。

为了弥补可能的市场变化造成的误判，需要定期与可能的运营商、供应商和开发团队进行 敏捷会议（如需求梳理会议），及时澄清需求变化。

同时，针对Agile的相应的线上平台就开始搭建和运转起来。 比如在Jira上，就有了相应的EPIC和Stories：记录和管理用户故事、任务和需求。在Confluence和sharepoint上，记录需求文档和团队知识库等等。

2. 设计阶段

设计阶段和需求分析实际上是相辅相成的，也可以是同步展开的。设计阶段也会使用到Jira系统和Confluence Page活sharepoint等平台，当然，还需要使用跟不同的设计内容和方法相应的工具（下面提到）。针对5G ORAN项目的设计强调简单性和模块化设计，设计以小的可交付组件为单位（如 DU、RU 或某些特定接口）。

使用迭代的方式开发架构，优先完成核心功能设计并随着开发逐步细化。

定期进行设计评审（Design Review），快速获得反馈并调整。

设计阶段可能使用到的工具：

Lucidchart/Draw.io：绘制系统架构图和接口设计图。

Enterprise Architect：设计和管理复杂的 5G ORAN 架构。

Figma：用于协作设计 UI 或服务流程。

3. 开发阶段

既然是DevOps体系，就不能把开发阶段和其他阶段完全隔离开来，比如测试、交付等。所以这里所说的开发阶段，更侧重于单纯的开发和迭代本身，但需要意识到需要使用 持续交付和持续集成（CI/CD） 方法，确保代码快速集成并可用。开发的基本流程是首先以任务为导向。具体的说，就是在之前设计阶段所细分和按时间和顺序划分的story和task活subtask，一个一个地完成。当然，要彻底完成某个任务，需要Dev和Ops的多次迭代。如果在CICD的过程中出现新的问题（比如高速数据导致O-DU出现coredump），则会及时自动或人工生成一个defect或bug的ticket，人后围绕这个ticket，需要进行解决问题的循环迭代。

另外，如果必要拆分开发任务为可完成的小功能（如实现一个 O-RAN 接口，如 M-plane 或 C-plane）。

考虑到5G ORAN系统的模块复杂性和团队多样性，需要专门的机制实现跨职能团队协作，例如：RU 软件开发团队与 gNB 开发团队的紧密配合等，这些合作往往由专门的团队活组织者来协调和管理。比如跨功能模块的合作项目XFT（cross-functionality test）团队就属于此类团队。

典型的Agile的日常活动包括每日站会（Daily Standup），利用dashboard和kanban汇报进展，解决阻碍。

可发阶段可能用到相关的工具：

Git/GitLab/GitHub：进行版本控制，支持分支协作和代码合并。

Jenkins/GitLab CI/CD：自动化构建、测试和部署。

Docker/Kubernetes：容器化部署 ORAN 模块，加速开发和测试。

VSCode/JetBrains IDEs：进行代码开发。

4. 测试阶段（CI）

在整个DevOps生命周期内，测试阶段是必不可少和极其重要的过程。测试与开发同步进行，使用 测试驱动开发（TDD） 和 行为驱动开发（BDD） 方法。5G ORAN项目可以包含单元测试、接口测试和集成测试、端到端测试等等，而且这些测试总体以Automation（自动化）的方式和continous(连续)的方式实现。

最典型的测试流程如下：

在自动化测试平台（比如Jenkins）预定义自动化测试的测试组（test suite）和测试用例（Test case），以及测试Pipeline和Job，在规定的时间以规定的周期进行自动测试。测试的结果自动输出，并根据测试结果，自动给出判断，如果出现问题，则自动在Jira上生成bug的Ticket，自动分配给相关领域的责任人。

定期进行 Sprint Review，验证迭代目标是否达到。

可能用到的工具：

Robot Framework：自动化测试框架，适用于 O-RAN 测试用例。

Postman：测试 O-RAN API 和接口。

Selenium/Appium：用于自动化前端或管理平台测试。

Wireshark：抓包分析 ORAN 的通信协议。

5. 部署阶段（CD）

使用 持续部署（CD） 工具，快速将开发成果推向测试环境甚至生产环境。可以部署基于虚拟化和容器化技术，支持不同环境快速切换（如云端和本地的 ORAN RU）。

典型的部署流程也是通过Jenkins预定义部署的CD（continous deploy）的Pipeline或Job，并定义该Job所用到的目标代码的Repository极其分支branch（比如O-DU的App代码，Jenkins files，部署Platform和transmit用到的代码等）。

在部署阶段，尤其需要DevOps 团队实时监控部署状况，及时处理部署问题。

部署阶段（CD）可能用到的工具：

Ansible/Terraform：进行基础设施即代码（IaC）管理，快速配置 ORAN 网络。

Helm：管理 Kubernetes 应用部署。

Prometheus/Grafana：实时监控 ORAN 部署的性能指标。

6. 运维与反馈阶段（如果已经有客户的情况下）

如果已经有客户在使用该产品，则会引入 持续反馈，从运营商和用户收集数据，改进产品功能。使用敏捷的 回顾会议（Retrospective） 分析上一次迭代的成功与失败，快速修复部署中的问题，通过微小增量发布（Hotfix）。

该阶段可能用到的工具：

ELK Stack（Elasticsearch, Logstash, Kibana）：日志收集和分析。

Nagios/Zabbix：监控 O-RAN 系统健康状态。

Slack/MS Teams：快速沟通和问题反馈。

注：本文部分章节使用到了ChatGPT