千万行Code 的挑战: Synology 如何掌握软件质量?

2021-08-06   出处:Synology Offical Blog  作/译者:Synology  

        对于一家以软件研究作为核心竞争优势的公司,除了工程技术的持续推进之外,如何在软件开发过程中,提高开发效率并且保证软件质量,可以说是相当严峻的挑战。

        Synology NAS的核心作业系统DiskStation Manager(DSM),就是一个亿级代码行大型软件开发的典型案例。以最近的两个DSM版本,DSM 6.2.4与DSM 7.0更新来看,两版之间的代码有近千万行的差别,为了应对日益增长的软件规模和复杂度,我们花费了更多的人力、时间在 DSM 7.0 的研发上,这两年来公司内部有超过 200 名 RD 进行开发、组建了 700 多个不同的专长小组,都是为了让DSM 7.0成为一个更加千锤百炼的系统,进一步应对更加严苛的IT环境。

什么是软件质量?浅谈 Synology 的产品开发架构

        要打造一套稳定、流畅的操作系统,需要许多严谨的步骤,而要如何在整个产品开发的流程中确保软件质量更是至关重要。首先,我们先来了解Synology在整个产品开发的流程中,主要有哪三个主要环节。

        第一个阶段,产品设计(Product Design)。这个阶段需要跨部门合作,RD、PM、Support、QC等相关部门会一同确认架构设计与规格。此外,包括安全性问题,也会在产品设计时一并考察进去。Synology的安全应变小组(SIRT,Security Incident Response Team)也会在这个阶段协助安全方面的架构设计,在产品开发初期即做到Security by Design / Default的源头管理。

        第二个阶段,产品研发(Develop)。通过使用静态分析工具(SAST)、编译失败预防机制(Build fail prevention)与持续整合(Continuous Integration),得以确保整个软件开发环节的质量。此外,我们也藉由Code Review,让RD彼此检视代码中是否有自己没有办法观察出的盲区并进而改善。

        第三个阶段,验收测试(Acceptance Test)。在此阶段进行针对DSM系统以及各套件不同的性能与压力测试方式。

        而在第二个产品研发阶段,是以工程的角度来看与软件质量最直接相关的环节。以下我们会专注谈,在DSM 7.0的产品研发阶段,主要通过解决了哪三个问题来提升软件质量。

        (Synology在产品研发流程中,通过解决软件编译,通过自动化工具找出缺陷以及执行性能验证来提升产品品质。)

为了让您的产品更好,我们做了哪三件事?

        第一,是解决软件编译失败的问题。

        软件编译是将代码转变成机器码的过程。在这个过程中,如果发生了代码因为某些原因(例如语法错误等)无法正确转换成机器码,则会发生编译错误。一旦发生软件编译错误,就必须回头修复后再度提交代码,影响到的会是所有与项目相关的工程人员。

        DSM套件是由700多个不同项目组合而成的复杂操作系统,由Synology内部超过200名全职RD协作进行开发,也因为人数众多,导致项目的变动次数相当可观,而大量项目之间的依赖关系,更进一步提升了编译失败的可能性。

        我们可以简单的计算一下编译失败所花费的时间成本:如果每次编译失败,得面临最少将近半天(一次编译时间以4.5小时来计算)的工作时间停摆,所有相关的项目人员(RD & QA)以200人计,那么每次编译失败所造成的时间成本就等于:「RD & QA数量*修复为止的耗时*」,整体耗费的成本相当惊人。因此,提升编译的成功率在推动项目进行可说是扮演关键性角色。

        为了防止编译失败,我们于是自行开发了代号为「甘道夫(Gandolf)」的系统,这个系统可以确保我们在任一项目签入(Commit)的时候,执行所有依赖项目的完整编译和单元测试,如此一来,就可以在签入阶段为编译错误以及单元测试的错误做把关,造成编译错误的代码就不会进一步进入到我们的储存库(Repository)中,直接降低了编译失败的可能性。

        过去我们一年平均每天执行甘道夫系统31次,一年总计执行了一万次,平均降低6.73%的编译失败率。以节省的成本来计算,就是200(RD & QA数量)* 4.5 * 200(4.5小时工作时间* 200个工作天)* 6.73 = 13325hr,总计为我们节省了超过一万个小时的开发时间,大幅提升开发效率,并降低沟通成本。

        第二,是自动发现缺陷(Defects)。

        首先先解释一下,随着系统的规模、复杂度不断成长,所谓的功能性弱点、漏洞(Bug),这些我们可以通称为缺陷(Defects)的项目,也会在正常情况下出现,且数量会越来越多。因此,通过使用静态分析工具(SAST)等自动化测试工具,可以协助我们提前找出各种缺陷跟安全性问题,并在每版更新发布之前,review完所有的缺陷并做相对应的调整。

        通过自动化测试工具,我们能定时且有规律扫出安全性问题与bugs,自动预防潜在的安全漏洞和Bug,更好且更有效率的把关安全性,且发布更新前,从源头就优先改善缺陷,也让研发人员可以将心力投注在更具价值的测试项目上。

        回到Synology的产品政策,随着Synology的使用者逐步从家用使用者成长到企业市场,我们在大概7年前即开始采用自动化测试工具,并在DSM 7.0上,导入更多不同的编码规范(Coding Standard)如CERT、MISRA等,为企业用户提供更佳的软件质量。

        (执行自动化全平台性能验证,协助提升Synology NAS的传输表现,满足对于服务器性能有高度要求的企业与使用者。)

        第三、执行自动化全平台性能验证

        从用户的角度来看,除了产品的稳定性、安全性外,性能(Performance)也至关重要,因此我们也花了不少经历在性能的改进上。

        相较于安全性问题与Bug能够通过手动测试或是自动化工具来找出来,性能问题则是很难在产品开发端就察觉,这是由于软件的开发是有一层一层的层级的,每一层都有机会导致性能出现落差,必须回头重新审视构架找出根本原因(Root cause)所在。

        有些软件公司采取的作法,是只在年度性重大版本更新才验证性能,平常每月或每季的稳定性更新并没有加入性能追踪指标。但Synology相当重视性能表现,也不希望使用者在每一版升级时遇到性能与预期不符,甚至下降的问题,我们因此建立自动夹板测试机制,协助我们在研发阶段提早找出性能可能下降的瓶颈。

        自动夹板测试,意即我们会针对每一个内部版本都进行性能测试,并追踪性能测试的各项指标在各版本之间的差异,只要和原先预期的有落差,就会通知相关的工程人员进行即时处置。执行夹板测试最大的好处在于,每一版之间的变化不会太多,因此较易于追踪最有可能导致性能下降的原因,让问题可以被更频繁的检视。

        例如,过去在某次版本升级时,我们就曾因为升级某个Open source版本,导致重要的档案传输性能下降。当时归功于夹板测试保留了每一板的完整性能测试报告,让我们在第一时间即可缩小范围,在追踪后发现是Open source的预设参数调整导致的性能变化。如果没有夹板的完整测试报告,我们可能要耗费更多倍的时间才可以找出这个问题。

更好的质量与更高的效率

        通过改善软件编译失败的问题,用自动化工具找出缺陷,以及执行夹板测试追踪性能变化这三种方式,让Synology得以在大规模的软件开发项目中更好的掌握软件质量,也让整体开发流程更为顺畅。

        事实上,一套复杂的系统的练成相当不简单,但背后的核心理念其实相当一致:尽量在越早期的阶段发现问题,就能在相对短的时间内处理问题,再到解决问题,提升开发效率并节省成本。未来,我们也会持续建立审核软件质量的指标,并且标准化自动化测试流程,持续增加程序的稳定,提供Synology的使用者更好的产品服务。

        


声明:本文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考(依行业惯例严格标明出处和作译者),目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。 如涉及作品内容、版权和其它问题,请原作者及时与本站联系(QQ:1017718740),我们将第一时间进行处理。本站拥有对此声明的最终解释权!欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,与我们的编辑和其他窝友交流。
142°|1423 人阅读|0 条评论

登录 后发表评论