为了解决现有编译自动化手动执行效率低下的问题，本文提出了一种编译SONIC版本及组件自动化流程的实现方法，基于shell脚本和Linux系统服务自动进行SONIC编译，并对编译结果进行核验、上传、反馈、版本校验和回归自动化。从而实现SONIC工程在每日开发完毕之后第二日进行自动编译，解决了SONIC开发人员手动编译导致的效率低下，以及工作时间整体编译占用大量服务资源的问题。

        下面结合流程图来对本流程进行详细描述，图1是一种自研交换机每日编译发布自动化流程，包括如下步骤：

        S1 从代码仓库上拉取编译工程代码，确定所要开发的分支，并更新子仓，指定厂商的交换芯片，开始编译；

        具体实施时，建立shell自动化脚本,确定开发所需厂商的版本，开启Linux系统服务，以及编译服务开启的时间，建议在每日零时开启编译，间隔10分钟开启下个版本的编译，服务器不占用工作时间。

        S2 自动编译校验，并对编译结果进行判断和推送；

        具体实施时，在自动化脚本中对编译执行成功与否进行判断，如果编译成功则触发结果推送，推送到工作群中让开发成员获知编译结果。

        如果编译失败则自动进行编译校验，对编译log进行分析，自动定位到编译失败组件的log中，并获取相关报错信息，推送到工作群中，如果脚本有代码仓库的权限则可根据编译失败的组件和报错信息在最新一次编译成功时到此时编译的全部提交信息中筛选哪次合入导致的编译失败，为开发人员排查编译失败原因提供定位。

        S3 自动上传编译组件和版本，并推送版本到测试设备；

        具体实施时，在编译成功的基础上，获取编译好的版本文件（bin包）和相关的deb包通过自动上传流程上传到制品库，并通过scp命令将最新编译好的版本传入到测试设备以进行自动化测试。

        S4 开启自动化测试（包括每日自动化和回归自动化）；

        具体实施时，在编译成功的基础上，自动连接远端测试仪所在服务器，开启每日自动化校验已编译完成的版本，并将结果推送至工作群中。在每日自动化完成之后，开启回归自动化，自动执行测试用例，如果执行测试用例所用时间较长，可将该步骤放后台执行，同时进行其他厂商版本的编译。

        S5 保存工程文件及日志信息；

       具体实施时，将编译完成的SONIC编译工程文件备份，并将开始和结束直接SONIC编译服务的所有log保存在构建日志文件夹中，以便开发人员查验编译过程。

图1 每日编译发布自动化流程框图

 综上所述，对本流程的实现进行详细说明，如图2所示，

1、首先从代码仓库拉取SONIC工程代码，向工作群推送开始编译的消息。

2、切换到所要编译的分支，并更新子仓库。

3、确定所要编译的版本类型，并执行配置。

4、开始编译SONIC版本。

5、检查SONIC版本是否编译成功。

6、如果编译失败则进行自动编译校验，查验log并过滤出错误信息。从最新一天的代码提交中过滤匹配，定位到导致编译失败的提交，然后向工作群推送编译失败相关信息。

7、如果编译成功则上传编译组件到制品库，并通过scp推送版本到测试设备上，然后向工作群推送编译成功信息，开启每日自动化测试进行版本校验，之后开启回归自动化测试，执行测试用例。

8、完成编译后，保存SONIC代码工程文件和编译日志以备查验。

图2 每日编译发布自动化流程图