CN108196877B - 组件发布管理的方法和装置以及计算设备 - Google Patents

Abstract

本公开是关于一种组件发布管理的方法，包括：获取本地项目下存在更新的至少一个组件；针对所述本地项目的根目录以及所述至少一个组件中的每个组件，提示并接收更新日志的输入；以及逐一比较所述本地项目的根目录和每个组件与远程库中相应根目录和组件的版本信息，并将版本信息存在更新的项目和组件发布至所述远程库。根据本公开的实施例，能够实现发布集成项目和离散组件的灵活配置，可以减少项目开发时的空间占用，同时简化发布更新组件时的操作。

Description

组件发布管理的方法和装置以及计算设备

技术领域

本公开涉及互联网技术领域，尤其涉及一种组件发布管理的方法和装置以及计算设备。

背景技术

随着组件化开发的流行，越来越多的程序开发选择将整个项目划分为多个组件包，也就是将若干主题相同但功能独立的组件打包，先独立开发然后再整合应用到项目中。以将组件化应用于页面开发为例，可以先将网页页面分成许多组件，例如每个组件可以是网页中具有特定功能的部分，然后开发各个组件，最后将这些组件嵌套或者组合成一个页面。

由于在组件化开发中各组件的开发是独立进行，对于整个开发项目的测试以及上线后的更新维护而言，就需要对组件包进行合理的发布管理。目前大部分的组件包发布管理方案就是简单地将所有组件放在一个包中，无论是一个还是若干个组件被修改，这个包都会统一发布一个版本。这样一来，对于那些不会频繁更新的组件而言，每次发布都会产生不必要的打包发布，造成项目更新或维护中的反复下载。另一方面，如果把每个组件单独拆成一个项目，一套业务组件中的项目太多太分散，既难以维护也难以查找，从而也会产生很严重的弊端。

因此，如何对组件包进行有效的发布管理，从而既方便开发者独立开发组件，又使组件包对于前端项目来说更好用，一直是组件化开发中致力解决的问题。

发明内容

本公开的目的是提供一种组件发布管理的方法和装置以及计算设备，进而至少在一定程度上克服由于相关技术的限制和缺陷而导致的一个或者多个问题。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

根据本公开实施例的第一方面，提供一种组件发布管理的方法，包括：获取本地项目下存在更新的至少一个组件；针对所述本地项目的根目录以及所述至少一个组件中的每个组件，提示并接收更新日志的输入；以及逐一比较所述本地项目的根目录和每个组件与远程库中相应根目录和组件的版本信息，并将版本信息存在更新的项目和组件发布至所述远程库。

根据本公开实施例的第二方面，提供一种组件发布管理的装置，包括：预发布模块，设置为获取本地项目下存在更新的至少一个组件，针对所述本地项目的根目录以及所述至少一个组件中的每个组件，提示并接收更新日志的输入；以及发布模块，设置为逐一比较所述本地项目的根目录和每个组件与远程库中相应根目录和组件的版本信息，并将版本信息存在更新的项目和组件发布至所述远程库。

根据本公开实施例的第三方面，提供一种存储有计算机程序的存储介质，所述计算机程序在由计算设备的处理器运行时，使所述计算设备执行如以上任一实施例所述的方法。

根据本公开实施例的第四方面，提供一种计算设备，包括：处理器；存储器，存储有可由所述处理器执行的指令；其中所述处理器被配置为执行如以上任一实施例所述的方法。

根据本公开的实施例，能够实现发布集成项目和离散组件的灵活配置，可以减少项目开发时的空间占用，同时简化发布更新组件时的操作。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

图1为根据本公开一实施例组件发布管理的方法流程图。

图2为图1实施例中组件扫描步骤的实施例流程图；

图3为根据本公开一实施例的预发布流程图。

图4为根据本公开一实施例的发布流程图。

图5为根据本公开一实施例组件发布管理的装置示意框图。

图6为根据本公开另一实施例组件发布管理的装置示意框图。

图7为根据本公开一实施例的计算设备示意框图。

具体实施方式

下面将参考若干示例性实施方式来描述本发明的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本发明，而并非以任何方式限制本发明的范围。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

本领域技术人员知道，本发明的实施方式可以实现为一种系统、装置、设备、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。

根据本发明的实施方式，提出了一种组件发布管理的方法和装置以及介质和计算设备。

下面参考本发明的若干代表性实施方式，详细阐释本发明的原理和精神。

图1为根据本公开一实施例组件发布管理的方法流程图，如图所示，本实施例的方法包括以下步骤S101-S103。在一个实施例中，本实施例的方法可由安装有JavaScript开发或测试工具的设备(例如计算机)来执行。

在步骤S101中，获取本地项目下存在更新的至少一个组件。

在一个实施例中，本地项目包括按照特定功能划分的多个组件，每个组件独立进行开发，开发过程中通过组件中心发布各个组件的更新版本至远程库中，从而便于开发人员进行本地项目的整体测试或者关联组件的联合测试，最后这些通过测试的组件通过嵌套或者组合形成完整的项目(例如一个页面)。本实施例的方法可适用于上述开发过程中的组件发布管理。

在本步骤的实施例中，可通过遍历扫描的方式获取本地项目下存在更新的至少一个组件。至于本步骤之前进行的组件具体开发过程，并非本方案关注的内容，此处不再赘述。

在一个实施例中，本地项目下各组件的扫描流程如图2所述，包括以下步骤S201-S203。

在步骤S201中，根据提交记录分析本地项目中是否存在待提交的内容。

在一个实施例中，以JavaScript开发场景为例，可基于commit命令对应的提交记录确定本地项目中是否存在待提交的内容。如果基于上述提交记录确定本地项目中尚存在待提交的内容，则向用户(例如开发人员)显示需要先提交的提示。反之，如果基于上述提交记录确定本地项目中不存在待提交的内容，则进行后续步骤的处理。

在步骤S202中，在确定本地项目中不存在待提交的内容时，根据目录标签扫描本地项目下各组件是否存在更新。

在步骤S203中，基于扫描的结果获取本地项目下存在更新的至少一个组件。

这里的目录标签是指针对某一时间点的版本打上的标记，常用于应用程序开发场景中的版本发布。在一个实施例中，仍以JavaScript开发场景为例，当本地项目是基于Git进行管理时，上述目录标签的一个实施例可以是tag(标签)，相应地，本步骤可通过前次发布时的tag为起始点，利用Git命令获取到当前提交为止修改过的组件目录。这里的Git是目前互联网领域最常用的开源分布式版本控制系统之一，但本公开的实施例并不仅限于此，当使用其他类似Git的分布式版本控制系统来管理本地项目时，便可通过该系统提供的相应命令来获取上述修改过的组件目录。

在步骤S102中，针对本地项目的根目录以及上述至少一个组件中的每个组件，提示并接收更新日志的输入。

组件的更新通常发生在原组件出现错误或者需要优化的时候，更新前后的组件可以用版本号加以区分，而为了方便存放每个版本的修改记录，每个组件的目录下都会产生一个更新日志(CHANGELOG)文件。CHANGELOG需要由开发人员或维护人员手动添加，其中通常以版本号为时间轴记载各个版本的更新情况。CHANGELOG的一个示例可参见下表所示。

表1CHANGELOG示例

在现有技术的组件发布管理方案中，开发人员在更新多个组件后，需要手动切换逐个组件的目录，进行CHANGELOG和版本号的编辑。相比之下，本实施例的步骤S102中，针对本地项目的根目录以及上述至少一个组件中的每个组件，逐个显示输入CHANGELOG的提示，从而简化了开发人员的操作，同时还能够结合后续步骤实现组件更新的灵活配置。例如，即使组件实际上进行了更新，但如果经本步骤提示后未收到CHANGELOG的输入，则可以实现暂不发布此更新的组件，因为后续步骤比较版本信息时会得出不需要发布的判断结果。

此外，本步骤除针对每个组件目录输出编辑CHANGELOG的提示外，还针对整个项目的根目录输出同样的提示，从而结合后续步骤实现项目和组件更新的独立发布。

在步骤S103中，逐一比较本地项目的根目录和每个组件与远程库中相应根目录和组件的版本信息，并将版本信息存在更新的项目和组件发布至所述远程库。

上述步骤S101-S102可以视为组件的预发布，步骤S103则完成组件更新的正式发布。

相关技术中存在一种多包项目管理的方案(Lerna)，其专注于管理多包项目，每次可以只发布一个包，其他包的版本不会受到影响。然而，Lerna方案的问题在于其没有统一的展示平台，每个组件都必须到相应的子组件包中查看，并且每个子组件包的目录中都会存放完整的公共依赖包目录，会导致项目占用空间过大。

相比之下，本实施例的步骤S103中，除了每个组件单独发布子组件包之外，还会通过组件中心发布用于展示项目整体的项目包。这样一来，通过组件中心对所有组件包进行集中展示，只需保留组件中心的一个公共依赖包目录，大大减少了项目开发时的空间占用，同时还可以实现开发目录和发布目录的区分。

另一方面，本实施例的步骤S103通过比较本地项目下根目录和每个组件与远程库中相应根目录和组件的版本信息来决定是否进行组件和项目的正式发布，除了能够避免发布没有升级版本的组件之外，还可以实现组件更新发布的灵活配置。正如步骤S102中所述，开发人员可以选择暂时不发布一些不必要的组件更新，这时只需不进行CHANGELOG的编辑即可。在另一个实施例中，本步骤在实施时也可以是针对根目录和更新组件目录输出是否进行发布的提示，由开发人员手动选择是否执行正式发布，此时则始终进行CHANGELOG的编辑。由此可见，步骤S103存在多种实施例，本公开并不仅限于此。

根据本公开的实施例，能够实现发布集成项目和离散组件的灵活配置，可以减少项目开发时的空间占用，同时简化发布更新组件时的操作。

图3为根据本公开一实施例的预发布流程图，对应于上述图1实施例中步骤S101-S102的一个具体实施例。如图所示，本实施例的预发布流程包括以下步骤S301-S310。

在步骤S301中，根据提交记录分析本地项目中是否存在待提交的内容，若是则输出需要先提交的提示并结束流程，否则转步骤S302。

在步骤S302中，根据目录标签扫描本地项目下各组件是否存在内容更新，若是则转步骤S303，否则输出没有更新内容的提示并转步骤S308。

以JavaScript的开发场景为例，步骤S302扫描本地项目下更新的组件可基于上次发布时的tag标签为起始点，利用Git命令获取到当前提交为止修改过的组件目录。

在步骤S303中，基于扫描的结果获取本地项目下存在内容更新的至少一个组件。

在步骤S304中，切换至上述至少一个组件中的一个组件目录进行处理。

在步骤S305中，显示输入更新日志和版本信息的提示。

在一个实施例中，步骤S305可通过命令行的形式来提示用户输入CHANGELOG内容，包括版本信息和修改日志。

在步骤S306中，根据接收的输入修改当前组件的更新日志和版本信息。

除更新CHANGELOG内容外，在一个实施例中，还可通过执行npm version命令来更改版本号。

在步骤S307中，确定上述至少一个组件是否均处理完毕，若是则转步骤S308，否则转步骤S304。

在步骤S308中，切换至本地项目的根目录。

在步骤S309中，显示输入更新日志和版本信息的提示。

在一个实施例中，步骤S309也可通过命令行的形式来提示用户输入CHANGELOG内容，包括版本信息和修改日志。

在步骤S310中，根据接收的输入修改本地项目的更新日志和版本信息。

除更新根目录下的CHANGELOG内容外，在一个实施例中，同样还可通过执行npmversion命令来更改版本号。

图4为根据本公开一实施例的发布流程图，对应于上述图1实施例中步骤S103的一个具体实施例。如图所示，本实施例的预发布流程包括以下步骤S401-S410。

在步骤S401中，根据提交记录分析本地项目中是否存在待提交的内容，若是则输出需要先提交的提示并结束流程，否则转步骤S402。

在步骤S402中，扫描本地项目下各组件版本信息是否存在更新，若是则转步骤S403，否则输出没有版本更新的提示并转步骤S407。

通过与远程库上相应组件的版本信息进行比较，步骤S402逐一扫描本地项目下各个组件的版本信息是否存在更新。例如，当本地组件的版本号大于远程库中已发布的组件版本号时，可判断该组件存在版本更新。

在步骤S403中，基于扫描的结果获取本地项目下存在版本更新的组件集合。

在步骤S404中，切换至上述组件集合中的一个组件目录进行处理。

在步骤S405中，执行发布操作。

在步骤S406中，确定上述组件集合是否均处理完毕，若是则转步骤S407，否则转步骤S404。

在步骤S407中，切换至本地项目的根目录并判断根目录下的版本信息是否存在更新，若是则转步骤S408，否则输出没有版本更新的提示并结束流程。

通过与远程库中相应根目录下的版本信息进行比较，步骤S407判断本地项目的版本信息是否存在更新。例如，当本地项目的版本号大于远程库已发布项目的版本号时，可判断该项目的版本信息存在更新。

在步骤S408中，将本地项目打包发布在远程库。

需要说明的是，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。另外，也易于理解的是，这些步骤可以是例如在多个模块/进程/线程中同步或异步执行。

本示例实施方式中进一步提供了一种组件发布管理的装置。

图5为根据本公开一实施例组件发布管理的装置示意框图。如图5所示，该装置可包括但不限于：预发布模块51和发布模块52。

预发布模块51设置为获取本地项目下存在更新的至少一个组件，针对所述、、本地项目的根目录以及所述至少一个组件中的每个组件，提示并接收更新日志的输入。

发布模块52设置为逐一比较本地项目的根目录和每个组件与远程库中相应根目录和组件的版本信息，并将版本信息存在更新的项目和组件发布至所述远程库。

图6为根据本公开另一实施例组件发布管理的装置示意框图。如图6所示，在图5所示实施例的基础上，该装置的预发布模块51包括第一提交分析单元511、标签扫描单元512、第一更新获取单元513、组件目录单元514、输入提示单元515、输入修改单元516以及第一根目录单元517；发布模块52包括第二提交分析单元521、版本扫描单元522、第二更新获取单元523、发布操作单元524以及第二根目录单元525。

第一提交分析单元511设置为根据提交记录分析所述本地项目中是否存在待提交的内容。

标签扫描单元512设置为在确定本地项目中不存在待提交的内容时，根据目录标签扫描本地项目下各组件是否存在更新。在一个实施例中，标签扫描单元512基于前次发布时的标签tag为起始点扫描修改过的组件目录。

第一更新获取单元513设置为基于所述扫描的结果获取本地项目下存在更新的至少一个组件。

组件目录单元514设置为切换至至少一个组件中的一个组件目录进行处理，并且在输入修改单元516完成一个组件目录的处理后切换至至少一个组件中的下一个组件目录进行处理，直至所述至少一个组件均处理完毕。

输入提示单元515设置为显示输入更新日志和版本信息的提示；

输入修改单元516设置为根据接收的输入修改当前组件的更新日志和版本信息。

第一根目录单元517设置为切换至本地项目的根目录，由输入提示单元515显示输入更新日志和版本信息的提示，进而输入修改单元516根据接收的输入修改本地项目的更新日志和版本信息。

第二提交分析单元521设置为根据提交记录分析所述本地项目中是否存在待提交的内容。

版本扫描单元522设置为在确定所述本地项目中不存在待提交的内容时，扫描本地项目下每个组件的版本信息并与远程库中相应组件的版本信息进行比对。

第二更新获取单元523设置为基于版本扫描单元522的比对结果获取所述本地项目下版本信息存在更新的组件集合。

发布操作单元524设置为遍历所述组件集合中的每个组件目录分别执行发布操作。

第二根目录单元525设置为在所述组件集合中每个组件目录的发布操作完成时，或者在基于版本扫描单元522的比对结果确定所述本地项目下所有组件的版本信息不存在更新时，切换至本地项目的根目录。由版本扫描单元522比较本地项目的根目录与远程库中相应根目录下的版本信息，进而发布操作单元524在确定本地项目根目录下的版本信息存在更新时，将本地项目打包发布在远程库。

根据本公开实施例的组件发布管理的装置，能够实现发布集成项目和离散组件的灵活配置，可以减少项目开发时的空间占用，同时简化发布更新组件时的操作。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。作为模块或单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本公开方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

通过以上实施方式的描述，本领域的技术人员易于理解，上文描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。

例如，在一个示例实施方式中，还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时可以实现上述任意一个实施例中所述方法的步骤。所述方法的具体步骤可参考前述实施例中的详细描述，此处不再赘述。所述计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

在另一个示例实施方式中，还提供一种计算设备，该计算设备可以是手机、平板电脑等移动终端，也可以是台式计算机、服务器等终端设备，本示例实施方式中对此不作限制。图7示出根据本公开示例实施方式中一种计算设备70的示意图。例如，计算设备70可以被提供为一移动终端。参照图7，设备70包括处理组件71，其进一步包括一个或多个处理器，以及由存储器72所代表的存储器资源，用于存储可由处理组件71的执行的指令，例如应用程序。存储器72中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件71被配置为执行指令，以执行上述组件发布管理的方法。该方法的步骤可参考前述方法实施例中的详细描述，此处不再赘述。

计算设备70还可以包括一个电源组件73被配置为执行计算设备70的电源管理，一个有线或无线网络接口74被配置为将计算设备70连接到网络，和一个输入输出(I/O)接口75。计算设备70可以操作基于存储在存储器72的操作系统，例如Android、IOS或类似。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由所附的权利要求指出。

虽然已参照几个典型实施例描述了本公开，但应当理解，所用的术语是说明和示例性、而非限制性的术语。由于本公开能够以多种形式具体实施而不脱离申请的精神或实质，所以应当理解，上述实施例不限于任何前述的细节，而应在随附权利要求所限定的精神和范围内广泛地解释，因此落入权利要求或其等效范围内的全部变化和改型都应为随附权利要求所涵盖。

Claims (9)

1.一种组件发布管理的方法，包括：

获取本地项目下存在更新的至少一个组件；

针对所述本地项目的根目录以及所述至少一个组件中的每个组件，提示并接收更新日志的输入；以及

逐一比较所述本地项目的根目录和每个组件与远程库中相应根目录和组件的版本信息，并将版本信息存在更新的项目和组件发布至所述远程库，

其中，所述提示并接收更新日志的输入包括：

切换至所述至少一个组件中的一个组件目录进行处理；

显示输入更新日志和版本信息的提示；

根据接收的输入修改当前组件的更新日志和版本信息；以及

切换至所述至少一个组件中的下一个组件目录进行处理，直至所述至少一个组件均处理完毕。

2.如权利要求1所述的方法，其中，所述获取本地项目下存在更新的至少一个组件包括：

根据提交记录分析所述本地项目中是否存在待提交的内容；

在确定所述本地项目中不存在待提交的内容时，根据目录标签扫描所述本地项目下各组件是否存在更新；以及

基于所述扫描的结果获取所述本地项目下存在更新的至少一个组件。

3.如权利要求2所述的方法，其中，所述根据目录标签扫描所述本地项目下各组件是否存在更新包括：

基于前次发布时的标签tag为起始点扫描修改过的组件目录。

4.如权利要求1所述的方法，其中，所述提示并接收更新日志的输入还包括：

切换至所述本地项目的根目录；

显示输入更新日志和版本信息的提示；以及

根据接收的输入修改所述本地项目的更新日志和版本信息。

5.如权利要求1所述的方法，其中，所述将版本信息存在更新的项目和组件发布至远程库包括：

根据提交记录分析所述本地项目中是否存在待提交的内容；

在确定所述本地项目中不存在待提交的内容时，扫描所述本地项目下每个组件的版本信息并与所述远程库中相应组件的版本信息进行比对；

基于所述比对的结果获取所述本地项目下版本信息存在更新的组件集合；以及

遍历所述组件集合中的每个组件目录分别执行发布操作。

6.如权利要求5所述的方法，其中，所述将版本信息存在更新的项目和组件发布至远程库还包括：

在所述组件集合中每个组件目录的发布操作完成时，或者在基于所述比对的结果确定所述本地项目下所有组件的版本信息不存在更新时，切换至所述本地项目的根目录；

比较所述本地项目的根目录与所述远程库中相应根目录下的版本信息；以及

在确定所述本地项目根目录下的版本信息存在更新时，将所述本地项目打包发布在所述远程库。

7.一种组件发布管理的装置，包括：

预发布模块，设置为获取本地项目下存在更新的至少一个组件，针对所述本地项目的根目录以及所述至少一个组件中的每个组件，提示并接收更新日志的输入；以及

发布模块，设置为逐一比较所述本地项目的根目录和每个组件与远程库中相应根目录和组件的版本信息，并将版本信息存在更新的项目和组件发布至所述远程库，

其中，所述预发布模块包括：

输入提示单元，设置为显示输入更新日志和版本信息的提示；

输入修改单元，设置为根据接收的输入修改当前组件的更新日志和版本信息；及

组件目录单元，设置为切换至所述至少一个组件中的一个组件目录进行处理，并且在所述输入修改单元完成一个组件目录的处理后切换至所述至少一个组件中的下一个组件目录进行处理，直至所述至少一个组件均处理完毕。

8.一种存储有计算机程序的存储介质，所述计算机程序在由计算设备的处理器运行时，使所述计算设备执行如权利要求1-6中任一项所述的方法。

9.一种计算设备，包括：

处理器；

存储器，存储有可由所述处理器执行的指令；

其中所述处理器被配置为执行如权利要求1-6中任一项所述的方法。