CN111158674A - 组件管理方法、系统、设备及存储介质 - Google Patents

Abstract

本发明实施例提供了组件管理方法、系统、设备及存储介质，该方法包括：根据获取的组件开发配置信息，生成待开发组件相应的组件开发模板；获得初始组件并存放于预创建的开发分支下，所述初始组件由开发者基于所述组件开发模板在所创建开发分支下开发形成；以对应所述开发分支的打包权限打包所述初始组件，并将打包后满足发布条件的目标组件发布到组件管理平台，该方法与现有方案相比，保证了组件开发中开发规则的统一化，降低了不同版本组件的分支裂变，保证了所发布组件能够满足组件统一管理的规则要求，实现了对组件打包、发布以及权限管理的统一化，有效提高了组件的管理效率。

Description

组件管理方法、系统、设备及存储介质

技术领域

本发明涉及版本控制和代码管理技术领域，尤其涉及组件管理方法、系统、设备及存储介质。

背景技术

在软件项目开发中，具有特定功能的一系列代码组成了一个组件，所形成的组件可以在多个软件项目中复用，为便于开发者对组件的复用、组件的问题修复或新功能开发，往往采用一些仓库对组件进行管理。

通过代码仓库对组件的现有管理实现中，主要将组件代码分仓库进行管理，开发者通常需要将不同的组件代码以建立多个Jerkins项目的形式进行组件打包并分别发布到代码仓库中。

发明人在实现本发明的过程中，发现现有对组件进行管理的方式存在如下问题：现有组件管理对组件负责人依赖性强，组件的维护阶段均需要有组件负责人参与；此外，一个组件被所多个项目复用时，在不同项目中可能会被修改，修改后的组件将直接存储在代码仓库中，导致代码仓库的同一路径下存在组件的多个不同版本，由此加重了不同版本组件的分支裂变。

发明内容

本发明实施例提供了组件管理方法、系统、设备及存储介质，实现了组件开发及发布的流程统一化，有效提高了组件的管理效率。

第一方面，本发明实施例提供了一种组件管理方法，包括：

根据获取的组件开发配置信息，生成待开发组件相应的组件开发模板；

获得初始组件并存放于预创建的开发分支下，所述初始组件由开发者基于所述组件开发模板在所创建开发分支下开发形成；

以对应所述开发分支的打包权限打包所述初始组件，并将打包后满足发布条件的目标组件发布到组件管理平台。

第二方面，本发明实施例提供了一种组件管理系统，包括：

组件开发及发布平台和组件管理平台；

所述组件开发及发布平台，包括：

模板生成模块，用于根据获取的组件开发配置信息，生成待开发组件相应的组件开发模板；

组件获取模块，用于获得初始组件并存放于预创建的开发分支下，所述初始组件由开发者基于所述组件开发模板在所创建开发分支下开发形成；

组件发布模块，用于以对应所述开发分支的打包权限打包所述初始组件，并将打包后满足发布条件的目标组件发布到组件管理平台；

所述组件管理平台，用于接收所述组件开发及发布平台上传的目标组件，并在所述目标组件所对应开发分支的存储路径下存储所述目标组件。

第三方面，本发明实施例提供了一种组件管理设备，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序；

所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现本发明上述实施例提供的方法。

第四方面，本发明实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现本发明上述实施例提供的方法。

本发明实施例提供了组件管理方法、系统、设备及存储介质，该管理方法包括：根据获取的组件开发配置信息，生成待开发组件相应的组件开发模板；获得初始组件并存放于预创建的开发分支下，所述初始组件由开发者基于所述组件开发模板在所创建开发分支下开发形成；以对应所述开发分支的打包权限打包所述初始组件，并将打包后满足发布条件的目标组件发布到组件管理平台。上述技术方案，在组件开发过程中，能够为组件开发提供与待开发组件功能类型匹配的组件开发模板，保证了组件开发中开发规则的统一化；同时，组件开发中还采用了开发分支来存储以及限定所开发组件的打包形式，保证组件打包的统一化，降低了不同版本组件的分支裂变；并通过发布条件来限定组件的发明，保证了所发布组件能够满足组件统一管理的规则要求，与现有组件管理方案相比，采用本方案提供的开发形式、打包形式以及发布形式实现了对组件打包、发布以及权限管理的统一化，有效提高了组件的管理效率。

附图说明

图1为本发明实施例一提供的一种组件管理方法的流程示意图；

图2给出了本发明实施例一中进行组件信息展示的展示效果图；

图3给出了本发明实施例一中组件详情信息展示的展示效果图；

图4为本发明实施例二提供的一种组件管理方法的流程示意图；

图5给出了本发明实施例二中用于组件打包配置的配置界面展示图；

图6给出了本发明实施例一所提供组件管理方法中源码替换修复的实现流程图；

图7为本发明实施例三提供的一种组件管理系统的结构框图；

图8为本发明实施例四提供的一种组件管理设备的硬件结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施例方式作进一步地详细描述。应当明确，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。另外，在不冲突的情况下,本发明实施例及实施例中的特征可以相互结合,各个实施例可以相互参考和引用。

实施例一

图1为本发明实施例一提供的一种组件管理方法的流程示意图，该方法可以由组件管理系统中的组件开发及发布平台实现，其中，该组件开发及发布平台可以由软件和/或硬件实现，并同处于后台端的组件管理平台一起组成了本实施例提供的组件管理系统，执行本实施例上述组件管理方法的组件开发及发布平台一般由至少一台组件管理设备构成，该组件管理设备相当于组件管理方法的执行主体，具体可以是具备有组件开发编程及发布工具计算机设备。

需要说明的是，本实施例所提供的组件管理方法可以由作为组件开发及发布平台的计算机设备作为执行主体，而作为执行主体的计算机设备上预先配置有进行代码管理的分布式版本控制系统-Git，在此基础上，本发明实施例提供的组件管理方法可看做Git上的一个项目工程。

具体的，在通过本执行主体执行本发明所提供的组件管理方法之前，可以由相关技术人员首先在Git上创建一个新的用于实现组件管理的项目工程，并在该项目工程下设定多个不同功能类型组件的组件目录。示例性的，所构建的各组件目录的目录名根据功能类型的不同可分别包括但不限定为下述几种：Common组件、arch组件(farmework相关组件)、performance组件(性能相关组件)、network组件(网络相关组件)以及business(业务相关组件)等等。

可以理解的是，相关技术人员在设定上述组件目录后，对应各所述组件目录还设定了相应的组件模型生成规则，以用于本实施例后续组件开发模板的生成。此外，作为本实施例所提供方法执行主体的计算机设备上还配置有用于软件开发的开发编程工具，相关技术人员可以在开发编程工具中通过集成组件管理插件的形式设定组件管理入口，将上述创建的用于组件管理的项目工程与开发编程工具建立关联，以为本实施例所提供的组件管理方法提供组件管理入口，实现组件的开发、打包以及发布的统一化管理。

同时，上述采用的Git具体为一个分布式版本控制系统，其还包括处于后台端的代码管理仓库，本实施例同时还包括了处于Git后台端的组件管理平台，与执行本实施例组件管理方法的组件开发及发布平台构成了本实施例提供的组件管理系统。

具体的，如图1所示，本发明实施例一提供的一种组件管理方法，该方法可以包括如下操作：

S101、根据获取的组件开发配置信息，生成待开发组件相应的组件开发模板，其中，所述组件开发配置信息由开发者通过给定的组件管理入口进行配置形成。

在本实施例中，所述组件开发配置信息具体可理解为开发者进行组件开发之前在给定开发配置界面进行组件开发所需配置形成的信息。根据上述描述，可认为本实施例该步骤的执行首先需要待进行组件开发的开发者来人为触发，其形式可以是开发者对当前所使用开发编程工具中的组件管理入口进行触发。由此，本步骤可以接收到上述触发后向开发者提供用于组件开发信息配置窗口，从而形成本步骤可获取的组件开发配置信息。

在本实施例中，本步骤可以对获取的组件开发配置信息进行分析，由此确定出待开发组件的功能类型，然后可以从上述已创建的组件管理项目工程中确定与上述功能类型匹配的模板生成规则，最终生成与上述组件开发配置信息对应的组件开发模板。

S102、获得初始组件并存放于预创建的开发分支下，所述初始组件由开发者基于所述组件开发模板在所创建开发分支下开发形成。

可以知道的是，上述步骤确定的组件开发模板可以呈现在安装于本执行主体上用于编程开发工具上，以供开发者实现对待开发组件的开发编程，本步骤获得的初始组件可认为是开发者基于上述组件开发模板编程并经过编译调试后的组件。

在本实施例中，所述开发分支可以是本步骤形成组件开发模板后，由开发者对应待开发组件在上述所创建组件管理项目工程下创建的一个分支，该开发分支区别于在Git上创建该组件管理项目工程时采用的主分支，为一个仅与开发者当前待开发组件关联的分支。

S103、以对应所述开发分支的打包权限打包所述初始组件，并将打包后满足发布条件的目标组件发布到组件管理平台。

需要说明的是，为防止组件的分支裂变，本实施例为所创建的开发分支进行了打包权限设定，优选限定非主分支外的其他所有分支均只允许进行非稳定版本类型的组件打包。本步骤中，所述开发分支相当于一个非主分支，其具备的的打包权限仅包括用于内测或测试的组件打包，由此，采用本步骤对初始组件进行打包后可以形成非稳定版本的内测版本组件或测试版本组件。

在本实施例中，所述组件管理平台可以处于Git的后台端上，作为一个组件管理仓库，具体可用于接收本执行主体打包后发布的组件并进行相应的存储，以便于后续相关人员的搜索与查询。

可的以理解的是，一般情况下组件的生命周期可以包括开发、打包、检验以及发布等阶段，本步骤在按照对应开发分支的打包权限对初始组件进行打包后，还需要经过一个组件检验来判定打包后的初始组件是否满足组件的发布条件，最终当打包后的初始组件满足发布条件时向后台端的组件管理平台发布初始组件，且可将该初始组件记为目标组件。

在本实施例中，在该打包分支具备的打包权限下包括两个可打包的打包类型，本步骤可采用上述两种打包类型对初始组件进行打包由此形成不同打包类型的初始组件，此外，不同打包类型还对应了不同的组件检验规则，本步骤可以按照不同打包类型对应的检验规则来对打包后的初始组件进行检验，示例性的，所进行的检验可以包括组件间的功能检验以及组件开发及打包规则的检验。

需要注意的是，本步骤将目标组件发布在组件管理平台上的同时，还携带了目标组件所归属的开发分支，由此对于组件管理平台而言，在对目标组件上进行存储时，同样可以在其上构建一个与上述开发分支相同分支名的分支目录，并将目标组件存储在该分支目录。对应于上述开发分支，该分支目录同样为非主分支目录，仅用于存储当前由本执行主体开发并发布的目标组件，以此来防止组件管理中的组件的分支裂变。

本发明实施例一提供的一种组件管理方法，在组件开发过程中，能够为组件开发提供与待开发组件功能类型匹配的组件开发模板，保证了组件开发中开发规则的统一化；同时，组件开发中还采用了开发分支来存储以及限定所开发组件的打包形式，保证组件打包的统一化，降低了不同版本组件的分支裂变；并通过发布条件来限定组件的发明，保证了所发布组件能够满足组件统一管理的规则要求，与现有方案相比，采用本方案提供的开发形式、打包形式以及发布形式实现了对组件打包、发布以及权限管理的统一化，有效提高了组件的管理效率。

作为本发明实施例一的一个可选实施例，在上述实施例的基础上，还进一步包括了：向所述组件管理平台发送组件列表展示请求，其中，所述组件列表展示请求通过权限用户在所给定操作界面上触发组件搜索按钮形成；接收所述组件管理平台相对所述组件列表展示请求反馈的的已发布组件列表并展示，其中，所述已发布组件列表中包括至少一条稳定版本组件；向所述组件管理平台发送组件详情展示请求，其中，所述组件详情展示请求由所述权限用户对所述已发布组件列表中任一条稳定版本组件触发时生成；接收所述组件管理平台反馈的对应所述组件详情展示请求的组件详情列表并展示。

需要说明的是，本实施例提供的组件管理方法中还包括了组件信息的搜索查询功能，该搜索查询功能具体体现在向组件管理平台发送组件查询相关的请求，然后可以接收到组件管理平台根据所接收请求筛选出的相关组件信息，并进行相关组件信息的展示。

具体的，上述组件搜索查询功能的实现过程可表述为：本执行主体上还提供了用于组件搜索与查询的组件信息展示入口，具备组件搜索与查询权限的权限用户可以通过该组件信息展示入口进入组件搜索与查询的操作界面，之后权限用户可以将待查询组件的功能类型或组件名称等作为组件查询的关键词并在所展示操作界面中的搜索框中进行关键词输入，由此触发组件搜索按钮，以触发本执行主体生成组件列表展示请求。其中，所述权限用户具体可指具备组件搜索查询权限的用户，该组件搜索查询权限可以是用户预先通过注册而获得，在本实施例所提供方法的执行中，用户只要进行一次登录权限验证，就可进行任意组件的查询以及复用。

可以理解的是，组件列表展示请求中包含了权限用户输入的关键词或者组件的功能类型，组件管理平台中包含了多个不同功能类型的组件目录，而不同组件目录下包含较大数量的组件，由此，组件管理平台通过对组件列表展示请求的解析，可以在所存储的组件中查找到多条相关的组件信息，且可以将查找到的组件信息以已发组组件列表的形式反馈给本执行主体，本执行主体可以接收到该已发布组件列表并形成信息列表展示界面进行组件列表信息的展示。

在本实施例中，处于后台端的组件管理平台上除了接收本执行主体对应开发分支发布的非稳定版本组件并进行相应的存储外，还接收并存储有对应主分支发布的稳定版本组件，且组件管理平台在本执行主体发布的组件进行存储时，除存储组件本身外，还一并保存记录该所存储组件的组件名、组件的开发者信息、组件具备的功能描述、组件适用的软件平台以及组件归属的组件目录等属性信息。

对于组件管理平台而言，其在接收到本执行主体发送的组件相关请求时，只考虑对主分支下存储的稳定版本组件中进行相应的组件查询匹配。由此，组件管理平台对应组件列表展示请求反馈给本执行主体的已发布组件列表中所包括的内容均为稳定版本组件，且本执行主体展示的已发布组件列表中行数表示了所包含稳定版本组件的组件总数，列数则表示了组件所具备的属性信息。

示例性的，图2给出了本发明实施例一中进行组件信息展示的展示效果图，如图2所示，具体提供了一个组件列表信息展示界面21，该组件列表信息展示界面21中包括了一个组件搜索框210和一个组件管理平台反馈的已发布组件列表211，还可以看出，已发布组件列表211的每一行展示了一个查询到的稳定版本组件，每一列则展示了对应稳定版本组件的属性信息，具体包括组件名、组件开发团队、组件功能描述、组件适用平台、组件归属目录、组件开发者以及组件相关文档等。

接上述描述，本实施例进行已发布组件列表展示后，还可以进一步对应该已发布组件列表中的任一个已发布组件生成相应的组件详情展示请求，并可接收到组件管理平台相对组件详情展示请求反馈的组件详情列表。

具体的，所述组件详情展示请求通过权限用户对上述展示的已发布组件列表中任一条稳定版本组件的触发生成，优选可以在权限用户触发已发布组件列表中的组件名时触发生成。

对于组件管理平台而言，其本身依赖于Git，在Git架构的基础上，组件管理平台同样具备组件版本管控的功能，但该组件版本管控同样仅针对与主分支下的稳定版本组件，对于每个稳定版本组件，组件管理平台可以追溯其历史版本号及其对应的发布时间，还可以获取到各历史版本所对应的功能完善描述、修订码以及最后的提交者信息等。

当组件管理平台接收到本执行主体发送的组件详情展示请求后，可以确定出该组件详情展示请求对应的稳定版本组件并进一步获取到与该稳定版本组件关联的各历史版本组件的详情信息，最终可将确定的详情信息汇总成组件详情列表反馈给本执行主体。本执行主体可以将该组件详情列表展示给权限用户。

示例性的，图3给出了本发明实施例一中组件详情信息展示的展示效果图，如图3所示，具体提供了一个组将详情展示界面22，该组件详情展示界面22中包括了进行详情信息展示的组件名，还包括了对应该组件名的所有历史版本号下对应的详情信息。优选地，所述组件详情列表中可以包括稳定版本组件的历史版本号、历史版本的修改描述以及历史版本的发布时间等。

本发明实施例一上述可选实施例具体给出了组件管理方法中进行组件信息查询的功能实现，可以看出，本组件管理方法对组件进行了集中管理，只要是具备了登录权限的权限用户可实现对任意组件的查询与复用。现有的组件管理中，开发所形成的不同组件可能存储在不同的代码仓库中，组件的分散管理导致在使用组件时需要进行繁杂的权限申请；与现有相比，本可选实施例上述方式有效避免了现有组件使用时需要进行繁杂申请的问题，通过本实施例所提供组件管理方法对组件的整体管理，达到了便于查找、维护以及追溯组件修改历史的有益效果。

此外，站在组件使用用户的角度，现有将组件应用到新项目开发中时，需要经常从代码仓库中拷贝待复用的组件代码，但现有组件代码的查找过程较为繁琐。而基于本实施例上述组件管理方法形成的组件管理系统，使用用户只需登录系统验证通过成为权限用户后，就可以直接对所需组件进行查询以及获取并复用到所需的项目中，无需使用用户按照现有的方式从代码仓库中层层查找获得，提高了用户的使用体验。

实施例二

图4为本发明实施例二提供的一种组件管理方法的流程示意图，本实施例二以上述实施例为基础进行优化，在本实施例中，进一步将根据获取的组件开发配置信息，生成待开发组件相应的组件开发模板具体优化为：获取所述开发者在组件开发配置窗口中编辑的组件开发配置信息，其中，所述组件开发配置窗口由所述开发者点击组件管理入口按钮后弹出；根据所述组件开发配置信息中组件归属目录，确定所述待开发组件对应的功能类型；将与所述功能类型匹配的空组件模板确定为所述待开发组件的组件开发模板。

同时，进一步将以对应所述开发分支的打包权限打包所述初始组件，并将打包后满足发布条件的组件发布到组件管理平台具体优化为：获取所述开发者在所给定打包配置界面中编辑的打包配置信息，其中，所述打包配置界面通过所述开发者对组件打包按钮的触发形成；如果所述打包配置信息中的打包类型满足所述开发分支的打包权限，则按照所述打包类型打包所述初始组件并采用对应所述打包类型的版本命名规则进行版本命名，形成待发布版本组件，其中，所述开发分支的打包权限包括内测打包和测试打包；按照所述开发分支对应的第一检验规则检验所述待发布版本组件，将满足所述第一检验规则的待发布组件作为目标组件发布到组件管理平台。

如图4所示，本实施例二提供的一种组件管理方法，具体包括如下操作：

S201、获取所述开发者在组件开发配置窗口中编辑的组件开发配置信息，其中，所述组件开发配置窗口由所述开发者点击组件管理入口按钮后弹出。

示例性的，相关技术人员在Git上创建组件管理项目工程并考虑设定了组件管理入口来与开发者使用的开发编程工具进行关联，本步骤可以通过开发者对开发编程工具中组件管理入口按钮的触发来弹出组件开发配置窗口，并获取开发者在组件开发配置窗口中编辑的组件开发配置信息。

S202、根据所述组件开发配置信息中组件归属目录，确定所述待开发组件对应的功能类型。

在本实施例中，所述组件开发配置信息可以包括用户选定的该待开发组件应该归属于组件管理项目工程下的哪个组件目录中，并将待开发组件所归属的目录确定为组件归属目录。

可以理解的是，开发者通常考虑结合待开发组件的所具备的功能来划分待开发组件应当归属的组件目录，由此，本步骤在获得组件开发配置信息中的组件归属目录后，根据待开发组件所归属的目录就可以确定该待开发组件实际具备的功能类型，所述功能类型可以包括但不限于基础类型、框架类型、性能类型、网络类型以及业务类型等。

S203、将与所述功能类型匹配的空组件模板确定为所述待开发组件的组件开发模板。

示例性的，本实施例在上述确定待开发组件的功能类型后，可以确定从各功能类型对应的空组件模板中选定出与该待开发组件匹配的组件开发模板。

S204、获得初始组件并存放于预创建的开发分支下，所述初始组件由开发者基于所述组件开发模板上开发形成。

可以知道的是，开发者基于本步骤确定的组件开发模板可以进行待开发组件的开发编程，本步骤可以获取到开发者开发编程形成的组件并可记为初始组件。此外，开发者还可以在上述创建在Git下的组件管理项目工程中创建该初始组件对应的开发分支，由此，本步骤可以将获得的初始组件缓存在对应创建的开发分支中。

S205、获取所述开发者在所给定打包配置界面中编辑的打包配置信息，其中，所述打包配置界面通过所述开发者对组件打包按钮的触发形成。

在本实施例中，开发者在形成初始组件后，将考虑对初始组件进行打包以及发布，本实施例可以在开发者对组件打包按钮的触发后形成打包配置界面，并可以获取到开发者在各打包配置界面中编辑的打包配置信息。所述组件打包按钮可以集成在开发者当前使用的编程工具中。

示例性的，图5给出了本发明实施例二中用于组件打包配置的配置界面展示图，如图5所示，所提供的打包配置界面23中包括了组件所对应分支的配置、组件名称的配置、组件打包类型的配置以及组件版本更新类型的配置等。

在本实施例中，在开发者形成初始组件后，对组件进行打包之前可以按照本实施例给定的规则对初始组件进行打包配置。示例性的，图5所给定打包配置界面23中组件所对应分支的配置以及组件名称的配置可以根据初始组件具体信息进行具体配置，而组件打包类型的配置总的包括了正式打包、内测打包以及测试打包这3中打包类型，但实际配置时则只能从开发分支所具备打包权限对应的打包类型中选定。

同时，组件版本更新类型的配置则需要开发者根据初始组件的实际更新内容来确定相应的版本更新类型，如，本实施例设定的版本更新类型包括：主版本号(MAJOR)、次版本号(MINOR)以及修订号(PATCH)，对于一个开发者开发的初始组件，当开发者在开发中进行了不兼容的接口修改时，则需要考虑限定的版本更新类型为MAJOR；当开发者在开发中进行了向下兼容的功能性新增时，则可以考虑限定的版本更新类型为MINOR；当开发者在开发中仅进行了向下兼容的问题修正时，则只需考虑限定版本更新类型为PATCH。

S206、如果所述打包配置信息中的打包类型满足所述开发分支的打包权限，则按照所述打包类型打包所述初始组件并采用对应所述打包类型的版本命名规则进行版本命名，形成待发布版本组件。

接上述描述，本实施例提供的组件管理方法中，设定了组件管理的对应的分支，并规定了不同分支具备的打包权限，如除主分支以外的其他分支只具备内测打包和测试打包的权限。以图5所示的打包配置界面为例，当开发者在该打包配置界面中选定组件所对应的分支后，若分支为非主分支，则其在进行下面的组件打包类型配置时，仅能进行内测打包或测试打包的选择。

由于在打包类型的配置阶段考虑了从满足打包权限的打包类型中选择，本步骤从打包配置信息中提取的打包类型一般情况下均满足开发分支的打包权限，其中，所述开发分支的打包权限包括内测打包和测试打包。本步骤由此可以根据提取出的打包类型对初始组件进行打包。

在本实施例中，针对不同的打包类型还设定了相应的版本命名规则，本步骤可以在对初始组件打包后，采用对应打包类型的版本名字规则对初始组件进行版本命名，从而形成初始组件的待发布版本组件。

进一步地，所述按照所述打包类型打包所述初始组件并采用对应所述打包类型的版本命名规则进行版本命名，具体可以包括：若所述打包类型为内测打包，则以所述内测打包对应的版本命名规则确定所述初始组件的内测版本命名，并编译打包形成内测版本组件；若所述打包类型为测试打包，则以所述测试打包对应的版本命名规则确定所述初始组件的测试版本命名，并编译打包形成测试版本组件。

示例性的，如打包类型为内测版本时，所对应的版本命名规则可以为保持初始组件的当前版本号不变，将当前版本号和内测标记一同作为组件版本命名；又如打包类型为测试版本时，所对应的版本命名规则可以为保持初始组件的当前版本号不变，将当前版本号和测试标记一同作为组件版本命名。其中，本实施例中提到的当前版本号均可以自动从Git上读取，所述当前版本号可认为是在此初始组件之前的组件所具备的最新版本号。整个打包过程减少了不必要的人为操作，为组件版本的自动化管理提供了前提基础。

S207、按照所述开发分支对应的第一检验规则检验所述待发布版本组件，将满足所述第一检验规则的待发布组件作为目标组件发布到组件管理平台。

在本实施例中，基于上述步骤形成待发布版本组件后，还需要对待发布组件进行组件检验，本实施例对应不同的分支设定不同的检验规则，本步骤主要对待发布版本组件进行与开发分支所对应检验规则的检验。示例性的，开发分支下的检验规则主要包括了待发布组件为内测版本组件时的检验以及为测试版本时的检验。

具体的，所述按照所述开发分支对应的第一检验规则检验所述待发布版本组件，可以优化包括：将所述待发布版本组件带入相关联项目进行功能验证；若所述待发布版本组件通过功能验证，则当所述待发布版本组件为内测版本组件时，验证所述内测版本组件的组件依赖是否为展平依赖方式且内测版本命名中是否包括组件当前版本号和内测标记；或者，当所述待发布版本组件为测试版本组件时，验证所述测试版本组件的组件依赖是否为展平依赖方式且测试版本命名中是否包括组件当前版本号和测试标记。

在本实施例中，首先对待发布组件进行功能检验，所述功能检验具体可通过将待发布组件代入所需的项目中进行检验，如果待发布组件在项目中成功实现相应的功能，则认为功能检验成功；反之，认为功能检验失败。本实施例通过功能检验后，需要进一步检验待发布组件是否依照设定的规则实现组件开发以及组件打包。

示例性的，本步骤在待发布组件为内测版本组件或测试版本时，可以验证该内测版本组件或测试版本组件的组件依赖是否为展平依赖方式，其中，该待发布组件中的组件依赖设定具体组件编程开发阶段有开发者进行设置。同时，还需要验证内测版本组件的版本命名是否采用了所对应的版本命名规则，即，包含了当前版本号和内测标记；或者，验证测试版本组件的版本命名中是否采用了所对应的版本命名规则，即，包含了当前版本号和测试标记。

对于上述提及的组件依赖，一般的，在一个组件开发中往往需要引入存在依赖关系的其他组件，现有普通的依赖方式往往将依赖声明隐藏在所依赖的组件中，由此出现了组件打包时对所依赖组件的好几个不同版本均进行打包的问题。本实施例考虑在组件开发中统一采用展平依赖(即CompileOnly的依赖方式)来建立组件与其他组件的依赖，该种依赖方式直接将组件与其他组件的依赖关系在本实施例所创建的组件管理项目工程下进行依赖声明，从而保证了依赖透明，避免了因依赖关系不确定而导致的组件打包包含多个不同版本组件的问题。

本发明实施例二提供的一种组件管理方法，进一步具体化了组件开发模板的确定过程，同时具体化了组件打包以及组件发布前的检验和发布的实现过程。利用该方法，为组件开发提供与待开发组件功能类型匹配的组件开发模板，保证了组件开发中开发规则的统一化；通过确定开发分支下具备打包权限，形成了初始组件的内测版本组件和测试版本组件，并由此在内测版本组件和测试版本组件通过检验后发布至组件管理平台上，该种操作保证了所发布组件能够满足组件统一管理的规则要求，与现有组件管理方案相比，采用本方案提供的开发形式、打包形式以及发布形式实现了对组件打包、发布以及权限管理的统一化，有效提高了组件的管理效率。

作为本发明实施例二的一个可选实施例，在上述实施例基础上，本可选实施例还进一步包括了：接收到问题反馈信息时，通过源码依赖替换策略修复所述开发分支下开发形成的初始组件，其中，所述问题反馈信息由组件审核者在验证出所述目标组件存在问题时形成并通过所述组件管理平台发送。

在本实施例中，目标组件发布至组件管理平台后，还会有相应的组件审核者对目标组件进一步进行审核，以确保目标组件的实际可用性，当组件审核者发现目标组件在审核中存在问题时，将通过组件管理平台向本执行主体发送问题反馈信息。

本执行主体接收到问题反馈信息后，将考虑对初始组件进行问题修复。一般的，初始组件中因存在对其他组件的依赖，在开发中往往会引入一些其他组件，而这些所依赖的组件主要以压缩包形式引入，但压缩包中的文件内容并不是可直接编译调试的源码。现有组件管理中对存在问题的初始组件进行修复时，首先需要通过类文件或关联源码进行问题定为，然后与组件负责人进行联系，让组件负责人对所发布组件中的问题进行修改，组件负责人进行问题修改后在重新编译打包以及发布，最终再对修改后的组件进行验证，如果存在问题将再次重复上述操作，整个组件维护过程需要人为参与，增大了组件维护成本。

为解决现有进行组件修复时产生的问题，本实施例考虑采用源码依赖替换的策略对进行组件修复。

具体的，图6给出了本发明实施例一所提供组件管理方法中源码替换修复的实现流程图，如图6所示，本可选实施例进一步将所述通过源码依赖替换策略修复所述开发分支下开发形成的初始组件，通过下述步骤实现：

S2081、查找所述初始组件中当前存在的压缩包文件。

示例性的，本实施例可以直接查找定位初始组件中所引入的压缩包文件。

S2082、针对每个压缩包文件，检测所述开发分支所属的项目工程下是否存在所述压缩包文件的源码路径。

本实施例可以针对检查出的每个压缩包文件进行源码路径检查，具体的，本步骤可以对开发分支所属的项目工程进行检测，检测其中是否包含该压缩包文件的源码路径。其中，开发分支所属的项目工程实际为本实施例最初由相关技术人员在Git上创建的组件管理项目工程。

S2083、若存在，则基于所述压缩包的源码路径获取所述压缩包文件的第一源码，并采用所述第一源码替换所述压缩包文件。

示例性的，当上述项目工程中存在该压缩包文件的源码路径时，可以直接基于其对应存在的源码路径获取压缩包文件的源码，本实施例记为第一源码，之后可以采用该第一源码替换初始组件中相应的压缩包文件。

S2084、若不存在，则从代码仓库中拉取所述压缩包文件的第二源码，并采用所述第二源码替换所述压缩包文件。

示例性的，当上述项目工程中不存在所对应压缩包文件的源码路径时，则需要从代码仓库中拉取该压缩包文件的第二源码。具体的，所述代码仓库可以指本实施上述提起的Git，其拉取所述第二源码的过程可表述为从Git上的对应一个开发组构建的代码主目录中查找该压缩包文件对应的源码文件，将源码文件复制到本实施例上述所提的组件管理项目工程下。

S2085、将各所述压缩包文件源码替换完成后的初始组件记为待修复组件，以供所述开发者进行问题修复。

本实施例采用上述步骤对初始组件中的所有压缩包文件进行替换后，可以将初始组件记为待修复组件，待修复组件可以调取显示在开发者当前所采用的的编程开发工具中，从而供开发者在显示有待修复组件的编程界面中进行问题修复。

需要说明的是，本实施例在开发者对待修复组件进行问题修复后，可重新获取修复后的组件作为初始组件，并返回本实施例上述给出的S205重新执行组件的打包以及发布流程。

本实施例上述可选实施例的技术方案，在组件存在问题时，采用了源码依赖替换的方式来进行问题修复，采用该种方式减少了组件的维护成本，减少了组件问题修复的修复流程，实现了组件管理的简洁化、统一化以及高效化。

可以理解的是，进行组件查询和调用的权限用户在使用过程中发现所使用的的组件存在问题，同样可以将问题反馈给本执行主体，本执行主体在接收到问题反馈信息后，仍可采用源码依赖替换的方式进行组件问题修复以及新一轮的打包及发布，从而保证组件管理平台上所存储稳定版本组件的正确性。

在上述可选实施例的基础上，本实施例在在将打包后满足发布条件的目标组件发布到组件管理平台之后，还优化包括：接收到组件验证成功信息时，控制在所述开发分支下形成的初始组件作为正式组件合并入预创建的主分支。

在本实施例中，目标组件发布至组件管理平台后，组件审核者对目标组件进一步审核并确保组件没有问题时，将通过组件管理平台向本执行主体发送组件验证成功信息。

本执行主体接收到验证成功信息后，将考虑对开发分支下的初始组件进行合并操作，即，将初始组件从开发分支下拷贝到预先创建的主分支下，这里的主分支可认为是最初相关技术人员创建组件管理项目工程时所采用的分支。

进一步地，所述主分支的打包权限包括正式打包；相应的，在控制在所述开发分支下形成的初始组件作为正式组件合并入预创建的主分支之后，还包括：在所获取打包配置信息中打包类型为正式打包时，以所述正式打包方式打包所述初始组件，并采用对应所述正式打包的版本命名规则进行版本命名，形成稳定版本组件；当所述稳定版本组件满足所述主分支对应的第二检验规则时，将所述稳定版本组件发布到所述组件管理平台。

在本实施例中，区别于开发阶段采用的开发分支，本实施例设定所述主分支具备正式打包的打包权限，之后本步骤可以将上述存在于开发分支下的初始组件复制到主分支下，并采用正式打包的打包类型形成稳定版本组件。

具体的，本实施例在将初始组件合并入主分支后，进行组件打包之前仍然需要按照本实施例给定的规则对初始组件进行打包配置，此时，接收到开发者的打包需求后，仍旧会弹出打包配置界面供开发者进行打包配置，在打包配置中，开发者可以选定主分支作为初始组件的打包分支，并选定正式打包作为打包类型，同时也可根据初始组件的具体更新内容选定组件版本更新类型。

之后，本实施例可以按照正式打包的方式打包该初始组件，并采用该正式打包对应的版本命名规则进行版本命名，形成稳定版本组件。示例性的，在稳定版本组件的命名实现中，本实施例可以结合开发者配置的版本更新类型结合版本递增的规则确定初始组件的最新版本号，来作为稳定版本组件的最新版本号。然后，本实施例还需要对稳定版本组件按照正式打包对应的第二检验规则进行组件检验，以确定稳定版本组件的功能作用、组件依赖以及版本命名是否正常。最终本实施例可以将检验合格的稳定版本组件发布至组件管理平台，并具体存储在组件管理项目工程对应的主分支下。

本实施例上述可选实施例具体实现了组件开发成功后到主分支的回归，本实施例所提出的仅为主分支设定正式打包的权限，很好的防止了组件开发及发布过程中产生的分支裂变。

实施例三

图7为本发明实施例三提供的一种组件管理系统的结构框图，如图7所示，该组件管理系统包括：组件开发及发布平台31和组件管理平台32；

其中，组件开发及发布平台31，包括：

模板生成模块310，用于根据获取的组件开发配置信息，生成待开发组件相应的组件开发模板；

组件获取模块311，用于获得初始组件并存放于预创建的开发分支下，所述初始组件由开发者基于所述组件开发模板在所创建开发分支下开发形成；

组件发布模块312，用于以对应所述开发分支的打包权限打包所述初始组件，并将打包后满足发布条件的目标组件发布到组件管理平台。

组件管理平台32，用于接收所述组件开发及发布平台上传的目标组件，并在所述目标组件所对应开发分支的存储路径下存储所述目标组件。

本发明实施例三提供的一种组件管理系统，在组件开发过程中，能够为组件开发提供与待开发组件功能类型匹配的组件开发模板，保证了组件开发中开发规则的统一化；同时，组件开发中还采用了开发分支来存储以及限定所开发组件的打包形式，保证组件打包的统一化，降低了不同版本组件的分支裂变；并通过发布条件来限定组件的发明，保证了所发布组件能够满足组件统一管理的规则要求，与现有组件管理方案相比，采用本方案提供的开发形式、打包形式以及发布形式实现了对组件打包、发布以及权限管理的统一化，有效提高了组件的管理效率。

进一步地，模板生成模块310具体可以用于获取所述开发者在组件开发配置窗口中编辑的组件开发配置信息，其中，所述组件开发配置窗口由所述开发者点击组件管理入口按钮后弹出；根据所述组件开发配置信息中组件归属目录，确定所述待开发组件对应的功能类型；将与所述功能类型匹配的空组件模板确定为所述待开发组件的组件开发模板。

进一步地，组件发布模块312具体可以包括：

组件打包单元，用于当所获取打包配置信息中的打包类型满足所述开发分支的打包权限时，按照所述打包类型打包所述初始组件并采用对应所述打包类型的版本命名规则进行版本命名，形成待发布版本组件，其中，所述开发分支的打包权限包括内测打包和测试打包；

组件检验单元，用于按照所述开发分支对应的第一检验规则检验所述待发布版本组件，将满足所述第一检验规则的待发布组件作为目标组件发布到组件管理平台。

进一步地，组件打包单元具体可以用于当所获取打包配置信息中的打包类型满足所述开发分支的打包权限时，若所述打包类型为内测打包，则以所述内测打包对应的版本命名规则确定所述初始组件的内测版本命名，并编译打包形成内测版本组件；若所述打包类型为测试打包，则以所述测试打包对应的版本命名规则确定所述初始组件的测试版本命名，并编译打包形成测试版本组件。

进一步地，所述组件检验单元具体可以用于将所述待发布版本组件带入相关联项目进行功能验证；若所述待发布版本组件通过功能验证，则当所述待发布版本组件为内测版本组件时，验证所述内测版本组件的组件依赖是否为展平依赖方式且内测版本命名中是否包括组件当前版本号和内测标记；或者，当所述待发布版本组件为测试版本组件时，验证所述测试版本组件的组件依赖是否为展平依赖方式且测试版本命名中是否包括组件当前版本号和测试标记，将满足相应检验条件的待发布组件作为目标组件发布到组件管理平台。

进一步地，组件开发及发布平台31还包括：组件修复模块，该组件修复模块可以用于接收到问题反馈信息时，通过源码依赖替换策略修复所述开发分支下开发形成的初始组件，其中，所述问题反馈信息由组件审核者在验证出所述目标组件存在问题时形成并通过所述组件管理平台发送。

在上述实施例的基础上，所述组件修复模块具体可以用于：接收到问题反馈信息时，查找所述初始组件中当前存在的压缩包文件；针对每个压缩包文件，检测所述开发分支所属的项目工程下是否存在所述压缩包文件的源码路径；若存在，则基于所述压缩包的源码路径获取所述压缩包文件的第一源码，并采用所述第一源码替换所述压缩包文件；否则，从代码仓库中拉取所述压缩包文件的第二源码，并采用所述第二源码替换所述压缩包文件；将各所述压缩包文件源码替换完成后的初始组件记为待修复组件，以供所述开发者进行问题修复。

在上述实施例的基础上，该组件开发及发布平台31还可以包括：分支合并模块，所述分支合并模块可以用于在将打包后满足发布条件的目标组件发布到组件管理平台之后，接收到组件验证成功信息时，控制在所述开发分支下形成的初始组件作为正式组件合并入预创建的主分支。

进一步的，所述主分支的打包权限包括正式打包；

相应的，该组件开发及发布平台31还包括了稳定版本发布模块，用于在控制在所述开发分支下形成的初始组件作为正式组件合并入预创建的主分支之后，在所获取打包配置信息中打包类型为正式打包时，以所述正式打包方式打包所述初始组件，并采用对应所述正式打包的版本命名规则进行版本命名，形成稳定版本组件；当所述稳定版本组件满足所述主分支对应的第二检验规则时，将所述稳定版本组件发布到所述组件管理平台。

进一步地，该该组件开发及发布平台31还包括：第一请求发送模块、第一信息展示模块、第二请求发送模块、第二信息展示模块。

其中，第一请求发送模块，可以用于向所述组件管理平台发送组件列表展示请求，其中，所述组件列表展示请求通过权限用户在所给定操作界面上触发组件搜索按钮形成；

第一信息展示模块，可以用于接收所述组件管理平台相对所述组件列表展示请求反馈的的已发布组件列表并展示，其中，所述已发布组件列表中包括至少一条稳定版本组件；

第二请求发送模块，可以用于向所述组件管理平台发送组件详情展示请求，其中，所述组件详情展示请求由所述权限用户对所述已发布组件列表中任一条稳定版本组件触发时生成；

第二信息展示模块，可以用于接收所述组件管理平台反馈的对应所述组件详情展示请求的组件详情列表并展示。

在上述实施例的基础上，所述组件详情列表中包括稳定版本组件的历史版本号、历史版本的修改描述以及历史版本的发布时间。

需要说明的是，本实施例所提供的智能管理平台32，具备对打包上传的组件信息进行集中管理的功能，其自身相当一个组件管理仓库，能够在前端用户对组件进行增、删、改以及查等常规操作后，实时的进行组件信息的更新。

实施例四

图8为本发明实施例四提供的一种组件管理设备的硬件结构示意图。如图8所示，该组件管理设备具体可以包括：处理器40、存储装置41、输入装置42和输出装置43。该组件管理设备中处理器40的数量可以是一个或者多个，图8中以一个处理器40为例。该组件管理设备中存储装置41的数量可以是一个或者多个，图8中以一个存储装置41为例。该组件管理设备的处理器40、存储装置41、输入装置42以及输出装置43可以通过总线或者其他方式连接，图8中以通过总线连接为例。

存储装置41作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本发明任意实施例所述的组件管理方法和/或图像拼接方法对应的程序请求/模块(例如，组件管理系统的组件开发及发布平台31中包括的的模板生成模块310、组件获取模块311、组件发布模块312以及组件管理平台32)。存储装置41可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作装置、至少一个功能所需的应用程序；存储数据区可存储根据组件管理设备的使用所创建的数据等。此外，存储装置41可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储装置41可进一步包括相对于处理器40远程设置的存储器，这些远程存储器可以通过网络连接至组件管理设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

输入装置42可用于接收输入的数字或者字符信息，以及产生与组件管理设备的用户设置以及功能控制有关的键信号输入，还可以是用于获取图像的摄像头以及获取视频数据中音频的拾音组件管理设备。输出装置43可以包括显示屏等视频组件管理设备以及扬声器等音频组件管理设备。需要说明的是，输入装置42和输出装置43的具体组成可以根据实际情况设定。

处理器40通过运行存储在存储装置41中的软件程序、请求以及模块，从而执行组件管理设备的各种功能应用以及数据处理，即实现上述的组件管理方法。

具体的，实施例中，处理器40执行存储装置41中存储的一个或多个程序时，具体实现如下操作：根据获取的组件开发配置信息，生成待开发组件相应的组件开发模板；获得初始组件并存放于预创建的开发分支下，所述初始组件由开发者基于所述组件开发模板在所创建开发分支下开发形成；以对应所述开发分支的打包权限打包所述初始组件，并将打包后满足发布条件的目标组件发布到组件管理平台。

本发明实施例还提供一种计算机可读存储介质，该存储介质中的程序由组件管理设备的处理器执行时，使得组件管理设备能够执行如上述方法实施例所述的组件管理方法。示例性的，该组件管理方法包括：根据获取的组件开发配置信息，生成待开发组件相应的组件开发模板；获得初始组件并存放于预创建的开发分支下，所述初始组件由开发者基于所述组件开发模板在所创建开发分支下开发形成；以对应所述开发分支的打包权限打包所述初始组件，并将打包后满足发布条件的目标组件发布到组件管理平台。

需要说明的是，对于装置、组件管理设备、存储介质实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本发明可借助软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(RandomAccess Memory,RAM)、闪存(FLASH)、硬盘或光盘等，包括若干请求用以使得一台组件管理设备(可以是机器人，个人计算机，服务器，或者网络设备等)执行本发明任意实施例所述的组件管理方法和/或图像拼接方法。

值得注意的是，上述用户兴趣点信息的确定装置中，所包括的各个单元和模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本发明的保护范围。

注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。

Claims (14)

1.一种组件管理方法，其特征在于，包括：

根据获取的组件开发配置信息，生成待开发组件相应的组件开发模板，其中，所述组件开发配置信息由开发者通过给定的组件管理入口进行配置形成；

获得初始组件并存放于预创建的开发分支下，所述初始组件由开发者基于所述组件开发模板上开发形成；

以对应所述开发分支的打包权限打包所述初始组件，并将打包后满足发布条件的目标组件发布到组件管理平台。

2.根据权利要求1所述的方法，其特征在于，所述根据获取的组件开发配置信息，生成待开发组件相应的组件开发模板，包括：

获取所述开发者在组件开发配置窗口中编辑的组件开发配置信息，其中，所述组件开发配置窗口由所述开发者点击组件管理入口按钮后弹出；

根据所述组件开发配置信息中组件归属目录，确定所述待开发组件对应的功能类型；

将与所述功能类型匹配的空组件模板确定为所述待开发组件的组件开发模板。

3.根据权利于要求1所述的方法，其特征在于，以对应所述开发分支的打包权限打包所述初始组件，并将打包后满足发布条件的组件发布到组件管理平台，包括：

获取所述开发者在所给定打包配置界面中编辑的打包配置信息，其中，所述打包配置界面通过所述开发者对组件打包按钮的触发形成；

如果所述打包配置信息中的打包类型满足所述开发分支的打包权限，则按照所述打包类型打包所述初始组件并采用对应所述打包类型的版本命名规则进行版本命名，形成待发布版本组件，其中，所述开发分支的打包权限包括内测打包和测试打包；

按照所述开发分支对应的第一检验规则检验所述待发布版本组件，将满足所述第一检验规则的待发布组件作为目标组件发布到组件管理平台。

4.根据权利要求3所述的方法，其特征在于，所述按照所述打包类型打包所述初始组件并采用对应所述打包类型的版本命名规则进行版本命名，包括：

若所述打包类型为内测打包，则以所述内测打包对应的版本命名规则确定所述初始组件的内测版本命名，并编译打包形成内测版本组件；

若所述打包类型为测试打包，则以所述测试打包对应的版本命名规则确定所述初始组件的测试版本命名，并编译打包形成测试版本组件。

5.根据权利要求3所述的方法，其特征在于，所述按照所述开发分支对应的第一检验规则检验所述待发布版本组件，包括：

将所述待发布版本组件带入相关联项目进行功能验证；

若所述待发布版本组件通过功能验证，则当所述待发布版本组件为内测版本组件时，验证所述内测版本组件的组件依赖是否为展平依赖方式且内测版本命名中是否包括组件当前版本号和内测标记；或者，

当所述待发布版本组件为测试版本组件时，验证所述测试版本组件的组件依赖是否为展平依赖方式且测试版本命名中是否包括组件当前版本号和测试标记。

6.根据权利要求1所述的方法，其特征在于，还包括：

接收到问题反馈信息时，通过源码依赖替换策略修复所述开发分支下开发形成的初始组件，其中，所述问题反馈信息由组件审核者在验证出所述目标组件存在问题时形成并通过所述组件管理平台发送。

7.根据权利要求6所述的方法，其特征在于，所述通过源码依赖替换策略修复所述开发分支下开发形成的初始组件，包括：

查找所述初始组件中当前存在的压缩包文件；

针对每个压缩包文件，检测所述开发分支所属的项目工程下是否存在所述压缩包文件的源码路径；

若存在，则基于所述压缩包的源码路径获取所述压缩包文件的第一源码，并采用所述第一源码替换所述压缩包文件；否则，从代码仓库中拉取所述压缩包文件的第二源码，并采用所述第二源码替换所述压缩包文件；

将各所述压缩包文件源码替换完成后的初始组件记为待修复组件，以供所述开发者进行问题修复。

8.根据权利要求1所述的方法，其特征在于，在将打包后满足发布条件的目标组件发布到组件管理平台之后，还包括：

接收到组件验证成功信息时，控制在所述开发分支下形成的初始组件作为正式组件合并入预创建的主分支。

9.根据权利要求8所述的方法，其特征在于，所述主分支的打包权限包括正式打包；

相应的，在控制在所述开发分支下形成的初始组件作为正式组件合并入预创建的主分支之后，还包括：

在所获取打包配置信息中打包类型为正式打包时，以所述正式打包方式打包所述初始组件，并采用对应所述正式打包的版本命名规则进行版本命名，形成稳定版本组件；

当所述稳定版本组件满足所述主分支对应的第二检验规则时，将所述稳定版本组件发布到所述组件管理平台。

10.根据权利要求1所述的方法，其特征在于，还包括：

向所述组件管理平台发送组件列表展示请求，其中，所述组件列表展示请求通过权限用户在所给定操作界面上触发组件搜索按钮形成；

接收所述组件管理平台相对所述组件列表展示请求反馈的的已发布组件列表并展示，其中，所述已发布组件列表中包括至少一条稳定版本组件；

向所述组件管理平台发送组件详情展示请求，其中，所述组件详情展示请求由所述权限用户对所述已发布组件列表中任一条稳定版本组件触发时生成；

接收所述组件管理平台反馈的对应所述组件详情展示请求的组件详情列表并展示。

11.根据权利要求10所述的方法，其特征在于，所述组件详情列表中包括稳定版本组件的历史版本号、历史版本的修改描述以及历史版本的发布时间。

12.一种组件管理系统，其特征在于，包括：组件开发及发布平台和组件管理平台；

所述组件开发及发布平台，包括：

模板生成模块，用于根据获取的组件开发配置信息，生成待开发组件相应的组件开发模板；

组件获取模块，用于获得初始组件并存放于预创建的开发分支下，所述初始组件由开发者基于所述组件开发模板在所创建开发分支下开发形成；

组件发布模块，用于以对应所述开发分支的打包权限打包所述初始组件，并将打包后满足发布条件的目标组件发布到组件管理平台；

所述组件管理平台，用于接收所述组件开发及发布平台上传的目标组件，并在所述目标组件所对应开发分支的存储路径下存储所述目标组件。

13.一种组件管理设备，其特征在于，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序；

所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-11任一项所述的方法。

14.一种计算机存储介质，其特征在于，包括：该程序被处理器执行时实现如权利要求1-11任一项所述的方法。

Images