Linux基金会下的OPNFV项目是通过集成，部署和测试促进各种开源生态系统网络功能虚拟化（NFV）组件的开发和演进的开源项目，该项目目前宣布了其跨社区持续集成（XCI）方案，意图通过增加OPNFV社区和上游社区之间的协作来实现创新。
通过XCI，OPNFV能够定期整合来自选定的上游社区项目的每个支持的分支的最新信息，缩短实施新功能的时间和解决问题的时间。OPNFV项目通过构建复杂的持续集成（CI）来支持DevOps开发模式，目前已经整合了OpenStack、OpenDaylight、FD.io等上游项目的主要版本，这些项目的主要版本更新周期可能会很长，延迟了OPNFV成员对上游项目的应用，同时也延迟了上游社区从OPNFV测试中获得有价值的反馈的速度。XCI计划通过定期集成和测试多个上游项目的最新软件版本来解决这个问题。
Orange NFV架构师Morgan Richomme表示：“开源社区需要XCI来解决OPNFV中复杂的测试挑战，从压力、稳健性、弹性、VNF和端到端测试入手，XCI已经成为OPNFV DNA的一部分，使OPNFV的成员能够尽快地从上游进行测试，以提供真实的电信级的反馈和编排。”
面临的挑战
最新的针对通信服务提供商（CSP）的调查显示，80%的受访者认为DevOps软件开发模式对NFV的成功至关重要。DevOps最主要的实现方式是评估DevOps工具链、自动化和测试基础设施。
从OPNFV的角度看，DevOps意味着通过应用CI/CD原则、自动化和实践来开发、测试、部署和监控软件系统，开发和运维团队协同工作，从而实现文化和思维方式的转变。持续集成和持续部署（CI/CD）作为DevOps的重要组成部分，是OPNFV项目成立以来一直在努力的方向。OPNFV的CI管道使得社区从DevOps方式中受益，用户可以快速访问新功能，开发人员能够快速收到反馈，整个软件堆栈以渐进式的方式得到改进。
目前OPNFV CI渠道可以概括如下：
OPNFV项目带动了上游项目的主要版本的发展，例如OPNFV集成了OpenStack的Newton版本对发送给OPNFV Gerrit的补丁进行审查，向提交者和审阅者提供对该补丁的反馈通过OPNFV Pharos项目，在多个硬件平台的各种环境中进行自动部署。CI渠道目前每天都集成并安装堆栈组件、项目和配置的不同组合，并对每个方案执行烟雾测试（smoke test），并针对该场景附加自动化测试。下图总结了这三个流程：
现有的途径虽然相对先进，但总是可以改进的，现有方法的主要挑战是上游项目的代码不是最新的，下图显示上游项目融入OPNFV的方式。
下面将介绍目前的方式存在的缺陷：
· 对上游最新版本概念验证（PoC）周期非常长，如上图所示，一旦开发人员提交代码，可能需要2到8个月的时间才能在OPNFV中显示特性，然后还需要4个月左右的时间才能在OPNFV的版本中实现该功能，总体时间长达7个月至12个月。以OpenStack为例，假设在2016年3月底或4月初为Newton版本合并的补丁将在2017年4月4日在OPNFV Danube上出现。
· 上游项目中的新功能存在错误，OPNFV用户想要提交一个修复补丁，这个周期可能需要3到8个月。然后可能还需要5到10个月才能在下一个上游项目的版本中才能修复，然后再过6个月会在OPNFV的下一个版本中出现。因此，要开发、调试并最终出现在OPNFV版本中的新功能可能需要14-24个月的时间。
很明显，这么长的整合周期不利于社区的快速整合、验证并实现验证目标，XCI的目标是改变这种状况。
XCI方案简介
XCI计划定期集成来自所有支持的上游社区的最新版本，而不是等待主要的发布版本。该举措将从OpenStack、OpenDaylight控制器和FD.io虚拟交换机的定期集成开始。下图显示了XCI的工作机制：
XCI涉及到两个主要的集成和测试任务：
· 对于社区成员上传的补丁，OPNFV XCI将根据项目和补丁进行验证，以+1/-1的形式向上游社区提供反馈
· OPNFV XCI将定期使用来自所有支持的版本的最新信息，将其集成并安装到场景中，并针对这些场景执行CI测试
这有效解决了上述提到的关键问题，能够快速利用上游项目的变化，可以迅速提供反馈，功能开发或错误修复将会缩短到几天时间内完成。
XCI利用RelEng和Pharos项目中的大部分当前工具。此外，XCI使用两种OpenStack基础设施工具：Bifrost和OpenStack-Ansible（OSA），用于配置节点，并安装由最新支持的OpenStack，ODL和FD.io分支构建的不同方案：
· Bifrost：Bifrost是OpenStack配置服务器节点的裸机配置项目，建立在OpenStack Ironic项目的基础之上，除了独立于其他OpenStack服务之外，该项目提供了一套Ansible操作手册，以自动方式将基本映像部署到裸机硬件上。
· OpenStack-Ansible：OSA也是一个OpenStack项目，它使用Ansible在预配节点上部署OpenStack环境。该项目创建Ansible可以部署核心和可选的OpenStack服务，OSA用于安装ODL和FD.io的不同场景。
借助上述工具，XCI将支持三种基本的操作系统：Ubuntu 16.04，CentOS 7和OpenSUSE 42.2。XCI计划还有其他复杂性：因为Bifrost和OSA实际上是OpenStack项目，所以它们也必须定期固定和测试，因为旧版本可能无法部署最新的代码。因此，用户可能需要安装CI软件和CI工具。
XCI开发者沙箱
除了上述自动化流程之外，开发人员还能够根据最新版本的上游项目进行本地开发和测试，XCI沙箱环境使得开发人员使用最新的上游代码或他们本地开发的代码来实施方案。而且XCI沙箱环境还能够让开发人员在单个节点，甚至在笔记本电脑上实现这些功能，而不需要完整的Pharos POD。其功能包括：
· 提供自动化设置开发和测试环境的方式
· 提供不同风格的环境
· 支持不同版本的上游组件
· 支持同一种机制来启用或禁用额外的OpenStack或其他上游项目
目前来看，沙箱环境有四种选择（xci-aio，xci-mini，xci-noha，xci-ha），随着硬件需求的增加，这些不同的沙箱环境消耗1-6个虚拟机。例如，xci-ha的风格是最耗资源的，每个虚拟机需要8个vCPU，16GB RAM和80GB磁盘，安装需要2个小时10分钟。
总之，XCI计划将CI管道的连续性延伸到上游项目。 而最初的上游项目XCI将整合在一起OpenStack，ODL和FD.io，未来还将努力扩展到其他上游项目，如ONAP。
免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。
