CN115408049A - 文件版本控制方法、装置和电子设备 - Google Patents

文件版本控制方法、装置和电子设备 Download PDF

Info

Publication number
CN115408049A
CN115408049A CN202211020878.2A CN202211020878A CN115408049A CN 115408049 A CN115408049 A CN 115408049A CN 202211020878 A CN202211020878 A CN 202211020878A CN 115408049 A CN115408049 A CN 115408049A
Authority
CN
China
Prior art keywords
file
version
merged
current
target file
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202211020878.2A
Other languages
English (en)
Inventor
薛琦
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Orende Microelectronics Technology Co ltd
Original Assignee
Beijing Orende Microelectronics Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Orende Microelectronics Technology Co ltd filed Critical Beijing Orende Microelectronics Technology Co ltd
Priority to CN202211020878.2A priority Critical patent/CN115408049A/zh
Publication of CN115408049A publication Critical patent/CN115408049A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21Design, administration or maintenance of databases
    • G06F16/219Managing data history or versioning
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/70Software maintenance or management
    • G06F8/71Version control; Configuration management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • G06F11/3688Test management for test execution, e.g. scheduling of test suites
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23Updating
    • G06F16/2308Concurrency control
    • G06F16/2315Optimistic concurrency control
    • G06F16/2329Optimistic concurrency control using versioning

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Software Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明提供了一种文件版本控制方法、装置和电子设备,合并更新文件和当前第二版本的目标文件,对得到的第一合并文件进行云端仿真测试,若测试通过,从数据库中提取当前第三版本的目标文件,并与第一合并文件合并,将得到的第二合并文件作为最新版本的目标文件保存至数据库。该方式中,当对第一合并文件进行云端仿真的测试通过后,可以从数据库中提取当前第三版本的目标文件,并与该第一合并文件进行合并,由于合并后的第二合并文件中包含了更为完整的更新信息,可以提高对数据库中目标文件的版本控制的准确率,并且该方式不需要人工干预,提高了对目标文件的版本控制效率,进而保证了项目开发进度。

Description

文件版本控制方法、装置和电子设备
技术领域
本发明涉及文件版本控制技术领域,尤其是涉及一种文件版本控制方法、装置和电子设备。
背景技术
随着集成电路技术的发展和市场规模的日益扩大,集成电路的规模和复杂度也越来越大,相应的逻辑设计和验证也变得越来越复杂,参与项目的研发人员越来越多,项目相关文档代码也不断增加,使得项目文件版本不断更新,对维护项目文件提出了较高的要求,相关技术中,采用代码版本管理工具可以在一定程度上缓解项目文件维护的问题,但该方式存在一定的局限性和缺陷,往往会导致项目开发无法按时完成,甚至失败;另外,也可以按一定规则,由人工配合代码版本管理工具进行项目文件版本的管理,但是人工干预既费时又费力,并且效率和准确率比较低,尤其当项目进行到关键节点时,常常出现工程师因为没有权限,导致无法提交代码而影响项目开发进度的问题。
发明内容
本发明的目的在于提供一种文件版本控制方法、装置和电子设备,以提高文件版本控制效率和准确率,保证项目开发进度。
本发明提供的一种文件版本控制方法,方法包括:获取对预先从数据库中提取的第一版本的目标文件进行更新后的更新文件,以及获取从数据库中提取的当前第二版本的目标文件;如果更新文件能与当前第二版本的目标文件合并,合并更新文件与当前第二版本的目标文件,得到第一合并文件;对第一合并文件进行云端仿真测试,得到第一测试结果;如果第一测试结果指示第一合并文件测试通过,从数据库中提取当前第三版本的目标文件;如果第一合并文件能与当前第三版本的目标文件合并,合并第一合并文件和当前第三版本的目标文件,得到第二合并文件,将第二合并文件作为最新版本的目标文件保存至数据库。
进一步的,合并第一合并文件和当前第三版本的目标文件,得到第二合并文件的步骤之前,方法还包括:判断云端仿真是否处于文件提交锁定状态;如果处于文件提交锁定状态,获取密钥,以通过密钥解锁文件提交锁定状态;其中,在文件提交锁定状态处于解锁状态下,允许将文件提交至数据库。
进一步的,方法还包括:按预设触发策略,对数据库中的最新版本的目标文件进行云端仿真测试,得到第二测试结果;其中,预设触发策略至少包括以下一种:定时触发策略、基于预设版本号规则的触发策略、基于文件变更数量的触发策略和手动触发策略;如果第二测试结果指示最新版本的目标文件存在异常,生成报警指示,以提示用户处理异常。
进一步的,合并更新文件与当前第二版本的目标文件,得到第一合并文件的步骤包括:比对第一版本的目标文件和当前第二版本的目标文件,得到第一比对结果;其中,第一比对结果用于:指示当前第二版本的目标文件相对与第一版本的目标文件的第一改动位置;如果第一改动位置与更新文件的更新位置有冲突,接收针对第一合并方式的第一选择指令,以确定第一合并文件;其中,第一合并方式包括以下至少一种:将当前第二版本的目标文件作为第一合并文件、将更新文件作为第一合并文件、将手动合并更新文件和当前第二版本的目标文件后得到的手动合并文件作为第一合并文件。
进一步的,合并第一合并文件和当前第三版本的目标文件,得到第二合并文件的步骤包括:比对当前第二版本的目标文件和当前第三版本的目标文件,得到第二比对结果;其中,第二比对结果用于:指示当前第三版本的目标文件相对与当前第二版本的目标文件的第二改动位置;如果第二改动位置与第一合并文件的更新位置有冲突,接收针对第二合并方式的第二选择指令,以确定第二合并文件;其中,第二合并方式包括以下至少一种:将当前第三版本的目标文件作为第二合并文件、将第一合并文件作为第二合并文件、将手动合并第一合并文件和当前第三版本的目标文件后得到的手动合并文件作为第二合并文件。
进一步的,获取对预先从数据库中提取的第一版本的目标文件进行更新后的更新文件,以及获取从数据库中提取的当前第二版本的目标文件的步骤包括:获取对预先从数据库中提取的第一版本的目标文件进行更新后的更新文件;判断是否需要对更新文件进行仿真验证;如果需要对更新文件进行仿真验证,判断是否需要对更新文件进行本地仿真;如果需要对更新文件进行本地仿真,对更新文件进行本地仿真,得到本地仿真结果;如果本地仿真结果指示更新文件测试通过,获取从数据库中提取的当前第二版本的目标文件。
进一步的,获取从数据库中提取的当前第二版本的目标文件的步骤包括:接收针对更新文件的云端仿真指令,从数据库中提取当前第二版本的目标文件。
进一步的,获取从数据库中提取的当前第二版本的目标文件的步骤之后,方法还包括:判断更新文件是否能与当前第二版本的目标文件合并;如果更新文件不能与当前第二版本的目标文件合并,重复执行接收针对更新文件的云端仿真指令的步骤,直至得到第一合并文件。
进一步的,方法还包括:如果第一测试结果指示第一合并文件测试未通过,重复执行获取对预先从数据库中提取的第一版本的目标文件进行更新后的更新文件的步骤,直至第一测试结果指示第一合并文件测试通过。
进一步的,从数据库中提取当前第三版本的目标文件的步骤之后,方法还包括:判断第一合并文件是否能与当前第三版本的目标文件合并;如果第一合并文件不能与当前第三版本的目标文件合并,重复执行获取对预先从数据库中提取的第一版本的目标文件进行更新后的更新文件的步骤,直至得到第二合并文件。
本发明提供的一种文件版本控制装置,装置包括:获取模块,用于获取对预先从数据库中提取的第一版本的目标文件进行更新后的更新文件,以及获取从数据库中提取的当前第二版本的目标文件;第一合并模块,用于如果更新文件能与当前第二版本的目标文件合并,合并更新文件与当前第二版本的目标文件,得到第一合并文件;测试模块,用于对第一合并文件进行云端仿真测试,得到第一测试结果;提取模块,用于如果第一测试结果指示第一合并文件测试通过,从数据库中提取当前第三版本的目标文件;第二合并模块,用于如果第一合并文件能与当前第三版本的目标文件合并,合并第一合并文件和当前第三版本的目标文件,得到第二合并文件,将第二合并文件作为最新版本的目标文件保存至数据库。
本发明提供的一种电子设备,包括处理器和存储器,存储器存储有能够被处理器执行的机器可执行指令,处理器执行机器可执行指令以实现上述任一项的文件版本控制方法。
本发明提供的一种机器可读存储介质,机器可读存储介质存储有机器可执行指令,机器可执行指令在被处理器调用和执行时,机器可执行指令促使处理器实现上述任一项的文件版本控制方法。
本发明提供的文件版本控制方法、装置和电子设备,获取对预先从数据库中提取的第一版本的目标文件进行更新后的更新文件,以及获取从数据库中提取的当前第二版本的目标文件;如果更新文件能与当前第二版本的目标文件合并,合并更新文件与当前第二版本的目标文件,得到第一合并文件;对第一合并文件进行云端仿真测试,得到第一测试结果;如果第一测试结果指示第一合并文件测试通过,从数据库中提取当前第三版本的目标文件;如果第一合并文件能与当前第三版本的目标文件合并,合并第一合并文件和当前第三版本的目标文件,得到第二合并文件,将第二合并文件作为最新版本的目标文件保存至数据库。该方式中,当对第一合并文件进行云端仿真的测试通过后,可以从数据库中提取当前第三版本的目标文件,并与该第一合并文件进行合并,由于合并后的第二合并文件中包含了更为完整的更新信息,可以提高对数据库中目标文件的版本控制的准确率,并且该方式不需要人工干预,提高了对目标文件的版本控制效率,进而保证了项目开发进度。
附图说明
为了更清楚地说明本发明具体实施方式或现有技术中的技术方案,下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图是本发明的一些实施方式,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本发明实施例提供的一种文件版本控制方法的流程图;
图2为本发明实施例提供的另一种文件版本控制方法的流程图;
图3为本发明实施例提供的一种云端仿真的流程图;
图4为本发明实施例提供的一种文件合并的流程图;
图5为本发明实施例提供的一种触发策略的示意图;
图6为本发明实施例提供的一种文件版本控制装置的结构示意图;
图7为本发明实施例提供的一种电子设备的结构示意图。
具体实施方式
下面将结合实施例对本发明的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
目前,伴随集成电路技术的发展和市场规模的日益扩大,集成电路的规模和复杂度也越来越大,相应的逻辑设计和验证都变得越来越复杂,参与项目的研发人员越来越多,项目相关文档代码也不断增加,因此,如何维护项目文件成为了项目开发过程中的难题。虽然近些年来不断涌现出的代码版本管理工具,如CVS(Concurrent Versions System,一种版本控制系统)、SVN(Subversion,一种开源的版本控制系统)、GIT(一种开源的分布式版本控制系统)等,虽然在一定程度上缓解了这个问题,但在实际项目开发过程中发现,单单依靠代码管理工具本身并不能解决代码版本冲突的全部问题,并且有一定的局限性和缺陷,往往会导致项目开发无法按时完成,甚至失败。
一个完整的集成电路开发项目,参与的工程师规模可以达到数十甚至数百人,对于一些复杂的片上系统(System on Chip,SoC)芯片,开发人员规模甚至可以达到千人以上。如此大规模的开发人员同时共同使用一套项目数据库,即便引入了项目版本管理工具,仍然不可避免的会产生冲突和错误,具体体现在:
1、不同开发人员同时更新同一文件,这些开发人员均以数据库中的最新版本为基础修改,但他们的修改之间存在重叠或冲突,所有人的修改提交到数据库之后无法保证正确性。
2、某开发人员正在修改模块A,与此同时另一开发人员在修改模块B,但是模块A的修改会影响到B,虽然并没有多个开发人员同时修改模块B,但模块B的代码修改提交到数据库后,由于模块A的代码已经改变,很可能导致模块B的功能不正确。
3、伴随开发人员规模的增长,开发人员所在地理位置不同(沟通不畅,时差等),很难建立有效机制保证不同开发人员在提交代码之前检查所有冲突的可能性。
通过人工干预,设定一定规则(如管理员机制,只有管理员审核通过才可提交),配合版本管理工具进行项目版本管理是目前的通用做法,但是人工干预既费时又费力,并且效率和准确率比较低,尤其当项目进行到关键节点时,常常出现工程师因为没有权限无法提交代码而影响项目进度的情况。
基于此,本发明实施例提供了一种文件版本控制方法、装置和电子设备,该技术可以应用于需要对项目开发过程中的文件进行版本控制的场景,尤其可以应用于需要对集成电路项目开发中的文件版本进行控制的场景中。
为便于对本实施例进行理解,首先对本发明实施例所公开的一种文件版本控制方法进行详细介绍;如图1所示,该方法包括如下步骤:
步骤S102,获取对预先从数据库中提取的第一版本的目标文件进行更新后的更新文件,以及获取从数据库中提取的当前第二版本的目标文件。
上述第一版本的目标文件可以理解为,当开发人员A需要对目标文件进行更新时,从数据库中提取的当时最新版本的目标文件;上述当前第二版本的目标文件可以理解为,在开发人员A对第一版本的目标文件进行修改的过程中,考虑到修改时间一般比较长,在开发人员A修改期间,可能有开发人员B对数据库中的第一版本的目标文件也进行了更新;当获取到开发人员A对第一版本的目标文件进行更新后的更新文件后,考虑到数据库中的目标文件的版本可能会有更新,此时,需要从数据库中提取当前第二版本的目标文件;该第二版本的目标文件可能与第一版本的目标文件相同,也可能不同。
步骤S104,如果更新文件能与当前第二版本的目标文件合并,合并更新文件与当前第二版本的目标文件,得到第一合并文件。
在实际实现时,为了保证不同开发人员对目标文件的更新信息不会遗漏,保证目标文件的数据完整性和准确性,在获取到更新文件以及第二版本的目标文件后,如果经判断,确认更新文件能与当前第二版本的目标文件合并,则可以将更新文件与当前第二版本的目标文件进行合并,得到第一合并文件;比如,在开发人员A对第一版本的目标文件进行修改的过程中,有开发人员B对数据库中的第一版本的目标文件也进行了更新,即数据库中存在了第二版本的目标文件,则合并后的第一合并文件中同时包含了开发人员A对第一版本的目标文件进行更新的更新信息,以及开发人员B对第一版本的目标文件进行更新的更新信息。
步骤S106,对第一合并文件进行云端仿真测试,得到第一测试结果。
当获取到上述第一合并文件后,可以对该第一合并文件进行云端仿真,由于云端仿真具备更丰富的仿真功能和仿真资源等,通过云端仿真得到的第一测试结果的准确性和精确性更高,与实际情况也更加贴合。
步骤S108,如果第一测试结果指示第一合并文件测试通过,从数据库中提取当前第三版本的目标文件。
当完成云端仿真测试,并且第一测试结果指示第一合并文件测试通过后,考虑到云端仿真也需要消耗一定的时间,在云端仿真过程中,可能有开发人员C对数据库中的第二版本的目标文件进行了更新;因此,当确认第一合并文件测试通过后,考虑到数据库中的目标文件的版本可能会有更新,此时,需要从数据库中提取当前第三版本的目标文件;该第三版本的目标文件可能与第二版本的目标文件相同,也可能不同。
步骤S110,如果第一合并文件能与当前第三版本的目标文件合并,合并第一合并文件和当前第三版本的目标文件,得到第二合并文件,将第二合并文件作为最新版本的目标文件保存至数据库。
在实际实现时,为了保证不同开发人员对目标文件的更新信息不会遗漏,保证目标文件的数据完整性,在完成对第一合并文件的云端仿真后,如果经判断,确认第一合并文件能与当前第三版本的目标文件合并,则可以将第一合并文件与当前第三版本的目标文件进行合并,得到第二合并文件;比如,在对第一合并文件进行云端仿真过程中,有开发人员C对数据库中的第二版本的目标文件也进行了更新,即数据库中存在了第三版本的目标文件,则合并后的第二合并文件中同时包含了第一合并文件中的更新信息,以及开发人员C对第二版本的目标文件进行更新的更新信息。将该第二合并文件作为当前的最新版本的目标文件提交至数据库,以更新数据库中的目标文件的文件版本。
上述文件版本控制方法,获取对预先从数据库中提取的第一版本的目标文件进行更新后的更新文件,以及获取从数据库中提取的当前第二版本的目标文件;如果更新文件能与当前第二版本的目标文件合并,合并更新文件与当前第二版本的目标文件,得到第一合并文件;对第一合并文件进行云端仿真测试,得到第一测试结果;如果第一测试结果指示第一合并文件测试通过,从数据库中提取当前第三版本的目标文件;如果第一合并文件能与当前第三版本的目标文件合并,合并第一合并文件和当前第三版本的目标文件,得到第二合并文件,将第二合并文件作为最新版本的目标文件保存至数据库。该方式中,当对第一合并文件进行云端仿真的测试通过后,可以从数据库中提取当前第三版本的目标文件,并与该第一合并文件进行合并,由于合并后的第二合并文件中包含了更为完整的更新信息,可以提高对数据库中目标文件的版本控制的准确率,并且该方式不需要人工干预,提高了对目标文件的版本控制效率,进而保证了项目开发进度。
本发明实施例还提供了另一种文件版本控制方法,该方法在上述实施例方法的基础上实现;该方法包括如下步骤:
步骤一,获取对预先从数据库中提取的第一版本的目标文件进行更新后的更新文件。
参见图2所示的另一种文件版本控制方法的流程图,一次完整的文件提交流程划分为代码修改,本地仿真,云端仿真,代码提交和事件触发云端仿真五大部分,其中本地仿真和云端仿真为可选项。
项目开发人员首先从项目数据库文件中获取目标文件的当前最新版本如版本A,在本地修改、新增、删除目标文件中的相关代码信息等,得到更新文件。
步骤二,判断是否需要对更新文件进行仿真验证。
步骤三,如果需要对更新文件进行仿真验证,判断是否需要对更新文件进行本地仿真。
如图2所示,如果经判断确认不需要对更新文件进行仿真验证,即如果其修改、新增、删除的相关代码信息不会影响项目整体,且不会影响其他人的工作,可以选择跳过本地仿真和云端仿真,直接提交代码,即直接将更新文件提交至数据库保存。
如果经判断确认需要对更新文件进行仿真验证,通常会继续判断是否需要对更新文件进行本地仿真,如果其修改、新增、删除相关代码信息极小可能会影响项目整体或其他人的工作,可以选择跳过本地仿真,直接进行云端仿真。
步骤四,如果需要对更新文件进行本地仿真,对更新文件进行本地仿真,得到本地仿真结果。
大多数情况下,项目开发人员无法判断其修改、新增、删除相关文件是否会影响项目整体或其他人的工作,应先在本地基于对更新文件进行仿真,得到本地仿真结果,本地仿真通过后再提交云端仿真。
下面对本地仿真进行具体描述,本地仿真是基于开发人员修改代码之前的数据库中的最新版本,如版本A;本地仿真完全由开发人员自行控制,可以在任何时刻(如修改完成或部分修改完成时)开始;本地仿真可以进行多次,如果一次不通过,开发人员可以继续修改再次启动本地仿真;本地仿真包含了用户修改代码的时机,所以一般时间较长。
步骤五,如果本地仿真结果指示更新文件测试通过,获取从数据库中提取的当前第二版本的目标文件。
该步骤五具体包括:如果本地仿真结果指示更新文件测试通过,接收针对更新文件的云端仿真指令,从数据库中提取当前第二版本的目标文件。
如图2所示,如果本地仿真结果指示更新文件测试失败,则通常需要开发人员重新修改代码,并重复执行上述步骤直至本地仿真结果指示更新文件测试成功;如果本地仿真结果指示更新文件测试成功,可以进入云端仿真,参见图3所示的一种云端仿真的流程图,当接收到云端仿真指令后,云端仿真开始前,需要先同步当前最新环境,具体可以从数据库中提取当前第二版本的目标文件。
步骤六,判断更新文件是否能与当前第二版本的目标文件合并。
步骤七,如果更新文件能与当前第二版本的目标文件合并,合并更新文件与当前第二版本的目标文件,得到第一合并文件;
该步骤七具体可以通过以下步骤A至步骤B实现:
步骤A,如果更新文件能与当前第二版本的目标文件合并,比对第一版本的目标文件和当前第二版本的目标文件,得到第一比对结果;其中,第一比对结果用于:指示当前第二版本的目标文件相对与第一版本的目标文件的第一改动位置;
步骤B,如果第一改动位置与更新文件的更新位置有冲突,接收针对第一合并方式的第一选择指令,以确定第一合并文件;
其中,第一合并方式包括以下至少一种:将当前第二版本的目标文件作为第一合并文件、将更新文件作为第一合并文件、将手动合并更新文件和当前第二版本的目标文件后得到的手动合并文件作为第一合并文件。
如图3所示,整个流程由脚本自动控制,无需用户介入。从图3中可以发现有两处提到了判断代码是否能够合并(在本地仿真中还有一次,由于本地仿真可以完全由用户人工控制,故不在此处讨论)。第一次为云端仿真开始前,同步获得项目数据库中最新版本(如版本B)后,判断本地的修改、新增、删除是否能与该版本自动合并;第二次为云端仿真结束后,本地修改、新增、删除文件提交前,判断是否能与此时项目数据库中最新版本(如版本C)自动合并。对于这两次是否能自动合并的判断,如果结论是否,需要引入人工干预。
参见图4所示的一种文件合并的流程图,本地修改、新增、删除文件与数据库中版本合并时,版本管理工具可以在一定范围内自动合并,具体的,可以根据文本内容比较,如果改动没有出现在相同的位置,则可以自动合并。具体的,可以检查代码与数据库中版本差异,对于新增文件,由于数据库中不存在记录,通常可以直接提交;对于修改和删除文件,需要考虑是否能够自动合并的问题,具体可以判断改动位置是否冲突,如果冲突,即改动出现在相同的位置,该版本管理工具不能自动合并,则需要用户手动选择,主要有三个选项:1.选择本地版本;2选择数据库中版本;3手动合并;按照选择的选项进行提交。对于删除文件来说,如果改动位置不冲突,可以直接提交;对于修改文件来说,如果改动位置不冲突,可以自动合并后提交。
针对本步骤来说,如果当前第二版本的目标文件的第一改动位置与更新文件的更新位置没有冲突,可以直接合并,如果有冲突,可以通过人工干预,用户手动选择将当前第二版本的目标文件作为第一合并文件,或者,将更新文件作为第一合并文件,或者,对更新文件和当前第二版本的目标文件进行手动合并,将手动合并后的手动合并文件作为第一合并文件,具体可以根据实际需求进行选择。
步骤八,如果更新文件不能与当前第二版本的目标文件合并,重复执行接收针对更新文件的云端仿真指令的步骤,直至得到第一合并文件。
具体的,如图3所示,如果更新文件不能与当前第二版本的目标文件合并,可以重新开始云端仿真的步骤。
步骤九,对第一合并文件进行云端仿真测试,得到第一测试结果。
如图3所示,具体可以对第一合并文件运行回归测试,得到第一测试结果;下面对云端仿真进行具体描述,云端仿真的过程由脚本自动完成,一旦触发开发人员无法控制其流程。云端仿真只能进行一次,如果失败需重新完成之前的流程。云端仿真会自动调用当前时间数据库中最新的版本(如版本B),并与开发人员提交的改动合并后进行仿真。由于开发人员修改、新增、删除相关文件往往需要一定时间周期,版本A和版本B之间有可能有一定差别,因此云端仿真结果和本地仿真结果也有可能不同。
步骤十,如果第一测试结果指示第一合并文件测试通过,从数据库中提取当前第三版本的目标文件。
云端仿真和本地仿真都通过(或被跳过)之后,所有修改、新增、删除的文件将会被提交到数据库。由于云端仿真本身需要消耗时间(取决于云端仿真使用的回归测试的仿真时间),因此,当修改、新增、删除的文件被提交到数据库的时,数据库最新的版本(如版本C)与云端仿真开始时获得的最新版本(如版本B)有可能并不相同,因此,为了保证不同开发人员对目标文件的更新信息不会遗漏,保证目标文件的数据完整性,当第一合并文件测试通过后,可以从数据库中提取当前第三版本的目标文件。
步骤十一,如果第一测试结果指示第一合并文件测试未通过,重复执行获取对预先从数据库中提取的第一版本的目标文件进行更新后的更新文件的步骤,直至第一测试结果指示第一合并文件测试通过。
如图3所示,如果运行回归测试失败,即如果第一测试结果指示第一合并文件测试失败,则通常需要开发人员重新修改代码,并重复执行上述步骤直至第一合并文件测试通过。
步骤十二,判断第一合并文件是否能与当前第三版本的目标文件合并。
步骤十三,如果第一合并文件能与当前第三版本的目标文件合并,判断云端仿真是否处于文件提交锁定状态。
步骤十四,如果处于文件提交锁定状态,获取密钥,以通过密钥解锁文件提交锁定状态;其中,在文件提交锁定状态处于解锁状态下,允许将文件提交至数据库。
在一定特殊情况下,云端仿真并自动提交的流程可以被冻结,比如,项目本身发现重大问题,如果用户继续提交则无法再不引入新问题的基础上解决现有问题等。此时可以采用加锁的方式,由管理员提供密匙,且一次提交对应一枚密匙,提交者只有输入正确的密匙才被允许提交文件。该检验密匙步骤仅在改动提交之前出现,如果开发人员仅仅想利用云端仿真验证自己的改动,并不提交,是被允许的。因此,如图3所示,如果经判断确认第一合并文件能与当前第三版本的目标文件合并,可以继续判断云端仿真是否处于冻结状态,如果处于冻结状态,则提供密钥,如果输入的密钥正确,可以执行后续操作,如果输入的密钥错误,则退出,不允许提交。
步骤十五,合并第一合并文件和当前第三版本的目标文件,得到第二合并文件。
步骤十六,如果第一合并文件不能与当前第三版本的目标文件合并,重复执行获取对预先从数据库中提取的第一版本的目标文件进行更新后的更新文件的步骤,直至得到第二合并文件。
如图3所示,如果第一合并文件不能与当前第三版本的目标文件合并,则通常需要开发人员重新修改代码,并重复执行上述步骤直至得到第二合并文件。
该步骤十六具体可以通过以下步骤H至步骤I实现:
步骤H,比对当前第二版本的目标文件和当前第三版本的目标文件,得到第二比对结果;其中,第二比对结果用于:指示当前第三版本的目标文件相对与当前第二版本的目标文件的第二改动位置。
步骤I,如果第二改动位置与第一合并文件的更新位置有冲突,接收针对第二合并方式的第二选择指令,以确定第二合并文件;
其中,第二合并方式包括以下至少一种:将当前第三版本的目标文件作为第二合并文件、将第一合并文件作为第二合并文件、将手动合并第一合并文件和当前第三版本的目标文件后得到的手动合并文件作为第二合并文件。
结合图4,针对本步骤来说,如果当前第三版本中的第二改动位置与第一合并文件的更新位置没有冲突,可以直接合并,如果有冲突,可以通过人工干预,用户手动选择将当前第三版本的目标文件作为第二合并文件,或者,将第一合并文件作为第二合并文件,或者,对第一合并文件和当前第三版本的目标文件进行手动合并,将手动合并后的手动合并文件作为第二合并文件,具体可以根据实际需求选择。
步骤十七,将第二合并文件作为最新版本的目标文件保存至数据库。
步骤十八,按预设触发策略,对数据库中的最新版本的目标文件进行云端仿真测试,得到第二测试结果;其中,预设触发策略至少包括以下一种:定时触发策略、基于预设版本号规则的触发策略、基于文件变更数量的触发策略和手动触发策略;
步骤十九,如果第二测试结果指示最新版本的目标文件存在异常,生成报警指示,以提示用户处理异常。
在得到第二合并文件后,脚本会自动提交第二合并文件至数据库并返回提交版本号,该第二合并文件即作为最新版本的目标文件。至此,代码已经成功提交至数据库,但如前,如果在云端仿真之后进行了文件合并(包含自动和手动),合并后的文件并没有经过仿真测试(回归)的检验。虽然云端仿真流程相比本地仿真消耗的时间较短,版本之间差别较小(如版本B与版本C之间的差别较小),但仍无法保证提交的文件百分百正确。因此,可以引入事件触发云端仿真流程。
事件触发云端仿真流程与之前的提交流程中的本地仿真、云端仿真不同,其独立于文件(代码)提交流程,事件触发云端仿真会按一定触发策略,在合适的时机获取项目数据库中最新版本的目标文件,并在云端进行仿真(回归测试),得到第二测试结果;该过程可以贯穿于整个项目生命周期,并结合可视化工具将历史仿真结果直观的展示给项目管理人员和开发人员,便于及时发现,分析和追踪问题,保障项目开发过程中任何的错误都能被及时发现。
参见图5所示的一种触发策略的示意图,事件触发云端仿真流程所涉及的触发策略包含且不限于以下几种:1.定时触发策略,如选取每天或每周的固定时间触发等;2.基于预设版本号规则的触发策略,如选取版本号为10的倍数,当出现相应的版本时触发;3.基于文件变更数量的触发策略,如当提交的版本包含的文件变更数量达到10个以上时触发;4.手动触发策略等其他触发策略。
上述文件版本控制方法,使用脚本语言结合版本管理工具,利用本地和云端的运算资源,实现了一种适用于多用户同时共同使用的文件版本控制方法,如果方法应用于集成电路开发辅助领域,则可以实现多用户同时共同使用的集成电路项目版本控制。该方式利用脚本语言(如PYTHON、PERL、SHELL等)调用仿真脚本、代码版本管理工具和仿真结果可视化工具等,形成一套完整的项目文件版本控制与管理流程。与传统的版本控制方法不同,该方法最大程度的实现了自动化,非特殊情况无需任何人为干预,从而极大的提高了效率并降低了出错的概率。
本发明实施例提供了一种文件版本控制装置,如图6所示,该装置包括:获取模块60,用于获取对预先从数据库中提取的第一版本的目标文件进行更新后的更新文件,以及获取从数据库中提取的当前第二版本的目标文件;第一合并模块61,用于如果更新文件能与当前第二版本的目标文件合并,合并更新文件与当前第二版本的目标文件,得到第一合并文件;测试模块62,用于对第一合并文件进行云端仿真测试,得到第一测试结果;提取模块63,用于如果第一测试结果指示第一合并文件测试通过,从数据库中提取当前第三版本的目标文件;第二合并模块64,用于如果第一合并文件能与当前第三版本的目标文件合并,合并第一合并文件和当前第三版本的目标文件,得到第二合并文件,将第二合并文件作为最新版本的目标文件保存至数据库。
上述文件版本控制装置,获取对预先从数据库中提取的第一版本的目标文件进行更新后的更新文件,以及获取从数据库中提取的当前第二版本的目标文件;如果更新文件能与当前第二版本的目标文件合并,合并更新文件与当前第二版本的目标文件,得到第一合并文件;对第一合并文件进行云端仿真测试,得到第一测试结果;如果第一测试结果指示第一合并文件测试通过,从数据库中提取当前第三版本的目标文件;如果第一合并文件能与当前第三版本的目标文件合并,合并第一合并文件和当前第三版本的目标文件,得到第二合并文件,将第二合并文件作为最新版本的目标文件保存至数据库。该装置中,当对第一合并文件进行云端仿真的测试通过后,可以从数据库中提取当前第三版本的目标文件,并与该第一合并文件进行合并,由于合并后的第二合并文件中包含了更为完整的更新信息,可以提高对数据库中目标文件的版本控制的准确率,并且该装置不需要人工干预,提高了对目标文件的版本控制效率,进而保证了项目开发进度。
进一步的,该装置还用于:判断云端仿真是否处于文件提交锁定状态;如果处于文件提交锁定状态,获取密钥,以通过密钥解锁文件提交锁定状态;其中,在文件提交锁定状态处于解锁状态下,允许将文件提交至数据库。
进一步的,该装置还用于:按预设触发策略,对数据库中的最新版本的目标文件进行云端仿真测试,得到第二测试结果;其中,预设触发策略至少包括以下一种:定时触发策略、基于预设版本号规则的触发策略、基于文件变更数量的触发策略和手动触发策略;如果第二测试结果指示最新版本的目标文件存在异常,生成报警指示,以提示用户处理异常。
进一步的,第一合并模块61还用于:比对第一版本的目标文件和当前第二版本的目标文件,得到第一比对结果;其中,第一比对结果用于:指示当前第二版本的目标文件相对与第一版本的目标文件的第一改动位置;如果第一改动位置与更新文件的更新位置有冲突,接收针对第一合并方式的第一选择指令,以确定第一合并文件;其中,第一合并方式包括以下至少一种:将当前第二版本的目标文件作为第一合并文件、将更新文件作为第一合并文件、将手动合并更新文件和当前第二版本的目标文件后得到的手动合并文件作为第一合并文件。
进一步的,第二合并模块64:比对当前第二版本的目标文件和当前第三版本的目标文件,得到第二比对结果;其中,第二比对结果用于:指示当前第三版本的目标文件相对与当前第二版本的目标文件的第二改动位置;如果第二改动位置与第一合并文件的更新位置有冲突,接收针对第二合并方式的第二选择指令,以确定第二合并文件;其中,第二合并方式包括以下至少一种:将当前第三版本的目标文件作为第二合并文件、将第一合并文件作为第二合并文件、将手动合并第一合并文件和当前第三版本的目标文件后得到的手动合并文件作为第二合并文件。
进一步的,获取模块60还用于:获取对预先从数据库中提取的第一版本的目标文件进行更新后的更新文件;判断是否需要对更新文件进行仿真验证;如果需要对更新文件进行仿真验证,判断是否需要对更新文件进行本地仿真;如果需要对更新文件进行本地仿真,对更新文件进行本地仿真,得到本地仿真结果;如果本地仿真结果指示更新文件测试通过,获取从数据库中提取的当前第二版本的目标文件。
进一步的,获取模块60还用于:接收针对更新文件的云端仿真指令,从数据库中提取当前第二版本的目标文件。
进一步的,该装置还用于:判断更新文件是否能与当前第二版本的目标文件合并;如果更新文件不能与当前第二版本的目标文件合并,重复执行接收针对更新文件的云端仿真指令的步骤,直至得到第一合并文件。
进一步的,该装置还用于:如果第一测试结果指示第一合并文件测试未通过,重复执行获取对预先从数据库中提取的第一版本的目标文件进行更新后的更新文件的步骤,直至第一测试结果指示第一合并文件测试通过。
进一步的,该装置还用于:判断第一合并文件是否能与当前第三版本的目标文件合并;如果第一合并文件不能与当前第三版本的目标文件合并,重复执行获取对预先从数据库中提取的第一版本的目标文件进行更新后的更新文件的步骤,直至得到第二合并文件。
本发明实施例所提供的文件版本控制装置,其实现原理及产生的技术效果和前述文件版本控制方法实施例相同,为简要描述,文件版本控制装置实施例部分未提及之处,可参考前述文件版本控制方法实施例中相应内容。
本发明实施例还提供了一种电子设备,参见图7所示,该电子设备包括处理器130和存储器131,该存储器131存储有能够被处理器130执行的机器可执行指令,该处理器130执行机器可执行指令以实现上述文件版本控制方法。
进一步地,图7所示的电子设备还包括总线132和通信接口133,处理器130、通信接口133和存储器131通过总线132连接。
其中,存储器131可能包含高速随机存取存储器(RAM,Random Access Memory),也可能还包括非不稳定的存储器(non-volatile memory),例如至少一个磁盘存储器。通过至少一个通信接口133(可以是有线或者无线)实现该系统网元与至少一个其他网元之间的通信连接,可以使用互联网,广域网,本地网,城域网等。总线132可以是ISA总线、PCI总线或EISA总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示,图7中仅用一个双向箭头表示,但并不表示仅有一根总线或一种类型的总线。
处理器130可能是一种集成电路芯片,具有信号的处理能力。在实现过程中,上述方法的各步骤可以通过处理器130中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器130可以是通用处理器,包括中央处理器(Central Processing Unit,简称CPU)、网络处理器(Network Processor,简称NP)等;还可以是数字信号处理器(DigitalSignal Processor,简称DSP)、专用集成电路(Application Specific IntegratedCircuit,简称ASIC)、现场可编程门阵列(Field-Programmable Gate Array,简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本发明实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成,或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器,闪存、只读存储器,可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器131,处理器130读取存储器131中的信息,结合其硬件完成前述实施例的方法的步骤。
本发明实施例还提供了一种机器可读存储介质,该机器可读存储介质存储有机器可执行指令,该机器可执行指令在被处理器调用和执行时,该机器可执行指令促使处理器实现上述文件版本控制方法,具体实现可参见方法实施例,在此不再赘述。
本发明实施例所提供的文件版本控制方法、装置和电子设备的计算机程序产品,包括存储了程序代码的计算机可读存储介质,所述程序代码包括的指令可用于执行前面方法实施例中所述的方法,具体实现可参见方法实施例,在此不再赘述。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是:以上各实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述各实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分或者全部技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims (13)

1.一种文件版本控制方法,其特征在于,所述方法包括:
获取对预先从数据库中提取的第一版本的目标文件进行更新后的更新文件,以及获取从所述数据库中提取的当前第二版本的目标文件;
如果所述更新文件能与所述当前第二版本的目标文件合并,合并所述更新文件与所述当前第二版本的目标文件,得到第一合并文件;
对所述第一合并文件进行云端仿真测试,得到第一测试结果;
如果第一测试结果指示所述第一合并文件测试通过,从所述数据库中提取当前第三版本的目标文件;
如果所述第一合并文件能与所述当前第三版本的目标文件合并,合并所述第一合并文件和所述当前第三版本的目标文件,得到第二合并文件,将所述第二合并文件作为最新版本的目标文件保存至所述数据库。
2.根据权利要求1所述的方法,其特征在于,合并所述第一合并文件和所述当前第三版本的目标文件,得到第二合并文件的步骤之前,所述方法还包括:
判断云端仿真是否处于文件提交锁定状态;
如果处于所述文件提交锁定状态,获取密钥,以通过所述密钥解锁所述文件提交锁定状态;其中,在所述文件提交锁定状态处于解锁状态下,允许将文件提交至所述数据库。
3.根据权利要求1所述的方法,其特征在于,所述方法还包括:
按预设触发策略,对所述数据库中的最新版本的目标文件进行云端仿真测试,得到第二测试结果;其中,所述预设触发策略至少包括以下一种:定时触发策略、基于预设版本号规则的触发策略、基于文件变更数量的触发策略和手动触发策略;
如果所述第二测试结果指示所述最新版本的目标文件存在异常,生成报警指示,以提示用户处理所述异常。
4.根据权利要求1所述的方法,其特征在于,所述合并所述更新文件与所述当前第二版本的目标文件,得到第一合并文件的步骤包括:
比对所述第一版本的目标文件和所述当前第二版本的目标文件,得到第一比对结果;其中,所述第一比对结果用于:指示所述当前第二版本的目标文件相对与所述第一版本的目标文件的第一改动位置;
如果所述第一改动位置与所述更新文件的更新位置有冲突,接收针对第一合并方式的第一选择指令,以确定所述第一合并文件;
其中,所述第一合并方式包括以下至少一种:将所述当前第二版本的目标文件作为所述第一合并文件、将所述更新文件作为所述第一合并文件、将手动合并所述更新文件和所述当前第二版本的目标文件后得到的手动合并文件作为所述第一合并文件。
5.根据权利要求1所述的方法,其特征在于,所述合并所述第一合并文件和所述当前第三版本的目标文件,得到第二合并文件的步骤包括:
比对所述当前第二版本的目标文件和所述当前第三版本的目标文件,得到第二比对结果;其中,所述第二比对结果用于:指示所述当前第三版本的目标文件相对与所述当前第二版本的目标文件的第二改动位置;
如果所述第二改动位置与所述第一合并文件的更新位置有冲突,接收针对第二合并方式的第二选择指令,以确定所述第二合并文件;
其中,所述第二合并方式包括以下至少一种:将所述当前第三版本的目标文件作为所述第二合并文件、将所述第一合并文件作为所述第二合并文件、将手动合并所述第一合并文件和所述当前第三版本的目标文件后得到的手动合并文件作为所述第二合并文件。
6.根据权利要求1所述的方法,其特征在于,所述获取对预先从数据库中提取的第一版本的目标文件进行更新后的更新文件,以及获取从所述数据库中提取的当前第二版本的目标文件的步骤包括:
获取对预先从数据库中提取的第一版本的目标文件进行更新后的更新文件;
判断是否需要对所述更新文件进行仿真验证;
如果需要对所述更新文件进行仿真验证,判断是否需要对所述更新文件进行本地仿真;
如果需要对所述更新文件进行本地仿真,对所述更新文件进行本地仿真,得到本地仿真结果;
如果所述本地仿真结果指示所述更新文件测试通过,获取从所述数据库中提取的当前第二版本的目标文件。
7.根据权利要求1所述的方法,其特征在于,所述获取从所述数据库中提取的当前第二版本的目标文件的步骤包括:
接收针对所述更新文件的云端仿真指令,从所述数据库中提取所述当前第二版本的目标文件。
8.根据权利要求7所述的方法,其特征在于,所述获取从所述数据库中提取的当前第二版本的目标文件的步骤之后,所述方法还包括:
判断所述更新文件是否能与所述当前第二版本的目标文件合并;
如果所述更新文件不能与所述当前第二版本的目标文件合并,重复执行接收针对所述更新文件的云端仿真指令的步骤,直至得到所述第一合并文件。
9.根据权利要求1所述的方法,其特征在于,所述方法还包括:
如果所述第一测试结果指示所述第一合并文件测试未通过,重复执行获取对预先从数据库中提取的第一版本的目标文件进行更新后的更新文件的步骤,直至所述第一测试结果指示所述第一合并文件测试通过。
10.根据权利要求1所述的方法,其特征在于,从所述数据库中提取当前第三版本的目标文件的步骤之后,所述方法还包括:
判断所述第一合并文件是否能与所述当前第三版本的目标文件合并;
如果所述第一合并文件不能与所述当前第三版本的目标文件合并,重复执行获取对预先从数据库中提取的第一版本的目标文件进行更新后的更新文件的步骤,直至得到所述第二合并文件。
11.一种文件版本控制装置,其特征在于,所述装置包括:
获取模块,用于获取对预先从数据库中提取的第一版本的目标文件进行更新后的更新文件,以及获取从所述数据库中提取的当前第二版本的目标文件;
第一合并模块,用于如果所述更新文件能与所述当前第二版本的目标文件合并,合并所述更新文件与所述当前第二版本的目标文件,得到第一合并文件;
测试模块,用于对所述第一合并文件进行云端仿真测试,得到第一测试结果;
提取模块,用于如果第一测试结果指示所述第一合并文件测试通过,从所述数据库中提取当前第三版本的目标文件;
第二合并模块,用于如果所述第一合并文件能与所述当前第三版本的目标文件合并,合并所述第一合并文件和所述当前第三版本的目标文件,得到第二合并文件,将所述第二合并文件作为最新版本的目标文件保存至所述数据库。
12.一种电子设备,其特征在于,包括处理器和存储器,所述存储器存储有能够被所述处理器执行的机器可执行指令,所述处理器执行所述机器可执行指令以实现权利要求1-10任一项所述的文件版本控制方法。
13.一种机器可读存储介质,其特征在于,所述机器可读存储介质存储有机器可执行指令,所述机器可执行指令在被处理器调用和执行时,所述机器可执行指令促使所述处理器实现权利要求1-10任一项所述的文件版本控制方法。
CN202211020878.2A 2022-08-24 2022-08-24 文件版本控制方法、装置和电子设备 Pending CN115408049A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211020878.2A CN115408049A (zh) 2022-08-24 2022-08-24 文件版本控制方法、装置和电子设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211020878.2A CN115408049A (zh) 2022-08-24 2022-08-24 文件版本控制方法、装置和电子设备

Publications (1)

Publication Number Publication Date
CN115408049A true CN115408049A (zh) 2022-11-29

Family

ID=84160883

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211020878.2A Pending CN115408049A (zh) 2022-08-24 2022-08-24 文件版本控制方法、装置和电子设备

Country Status (1)

Country Link
CN (1) CN115408049A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117453189A (zh) * 2023-12-22 2024-01-26 浪潮通用软件有限公司 一种应用分层开发的方法、系统、设备及介质

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117453189A (zh) * 2023-12-22 2024-01-26 浪潮通用软件有限公司 一种应用分层开发的方法、系统、设备及介质
CN117453189B (zh) * 2023-12-22 2024-03-15 浪潮通用软件有限公司 一种应用分层开发的方法、系统、设备及介质

Similar Documents

Publication Publication Date Title
CA3131079A1 (en) Test case generation method and device, computer equipment and storage medium
CN115167891B (zh) 接口控制文件的数据更新方法、装置、设备及存储介质
CN113127347B (zh) 一种接口测试方法、装置、设备及可读存储介质
CN110851539A (zh) 元数据校验方法、装置、可读存储介质和电子设备
CN110955432B (zh) 持续集成的发布方法、装置及系统
US20220414066A1 (en) Data management system, management method, and storage medium
CN113448862B (zh) 软件版本测试方法、装置及计算机设备
CN114780138B (zh) 流场模拟软件代码版本管理方法、装置和存储介质
CN115408049A (zh) 文件版本控制方法、装置和电子设备
CN114610286A (zh) 开发文档的生成方法、装置、计算机设备及存储介质
EP3514680B1 (en) Identification of changes in functional behavior and runtime behavior of a system during maintenance cycles
CN111367529A (zh) 代码贡献统计方法及装置
JP2018092361A (ja) テストスクリプト修正装置及びテストスクリプト修正プログラム
US20080172659A1 (en) Harmonizing a test file and test configuration in a revision control system
US11960862B2 (en) Source code correction assistance apparatus and source code correction assistance method
CN116185853A (zh) 代码校验方法及装置
CN114579171A (zh) 代码处理方法、装置、计算机设备和存储介质
JP2018092362A (ja) テストスクリプト修正装置及びテストスクリプト修正プログラム
CN114519003A (zh) 基于映射关系的回归测试方法、装置及电子设备
CN111078193A (zh) 一种面向数据分析系统的软件开发方法及系统
JP6546569B2 (ja) データ処理プログラム及びデータ処理方法
CN110609790A (zh) 解析程序测试方法、装置、介质和计算机设备
CN112947948B (zh) 应用服务的部署方法及装置
US20230252107A1 (en) Management device, management method, and storage medium
CN117971692A (zh) 代码提交方法、电子设备、存储介质和程序产品

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination