Application program publishing method and device, equipment and medium

Abstract

The invention discloses an application program publishing method and device, equipment and a medium. The method comprises the following steps: determining a technical stack of an application program; determining a corresponding target plug-in according to the technology stack; judging whether the application program needs to be updated or not; if the application program needs to be updated, integrating the target plug-in into the application program, and determining an updated application program; the updated application program is released, automatic processing of plug-in integration is achieved, the target plug-in can be seamlessly integrated into the original application program, the updated application program version is generated, and the integration efficiency and the success rate are improved.

Description

Technical Field

[0001] This application belongs to the field of application management, and specifically relates to an application publishing method, apparatus, device, and medium. Background Technology

[0002] With the rapid development of software technology and the deepening of enterprise digital transformation, application development and deployment have become increasingly complex. In actual software development and operation, developers need to deal with a variety of different technology stacks, including but not limited to programming languages ​​such as Java, Python, Node.js, and Go, as well as various development frameworks such as Spring Boot, Django, Express, and Gin. Each technology stack has its specific development specifications, dependency management, and version update mechanisms.

[0003] In existing technologies, when an application needs to be updated, developers typically need to manually identify the technology stack used by the application and then find suitable update plugins or tools based on the characteristics of the technology stack. This process is not only time-consuming and labor-intensive but also prone to human error. Especially in enterprise applications, there are often a large number of applications built on different technology stacks, and manually processing them one by one is a huge workload and inefficient. Summary of the Invention

[0004] In view of the above problems, embodiments of the present invention are proposed to provide an application publishing method, apparatus, device and medium that overcomes or at least partially solves the problems of requiring manual identification of the technology stack and manual selection of plugins.

[0005] In a first aspect, embodiments of this application provide an application publishing method, the method comprising: Determine the application's technology stack; Determine the corresponding target plugin based on the technology stack; Determine whether the application needs to be updated; If the application needs to be updated, the target plugin will be integrated into the application, and the application to be updated will be determined. Release the updated application.

[0006] Optionally, determining the technology stack of the application includes: Obtain at least one of the following: code text characteristics of the application, development environment configuration information, and system information during the runtime of the application; The technology stack of the application is determined based on at least one of the code text features, the development environment configuration information, and the system information of the application runtime.

[0007] Optionally, determining the corresponding target plugin based on the technology stack includes: The target plugin is determined based on the preset mapping relationship between the technology stack and the plugin and the technology stack of the application. The download address of the target plugin is determined in the preset plugin library.

[0008] Optionally, determining whether the application needs to be updated includes: Obtain the version number information of the application's plugins and the version number information of the target plugin; Compare the version number information of the application's plugin with the version number information of the target plugin; If the comparison results are inconsistent, the application is determined to need an update.

[0009] Optionally, the application that publishes the update includes: Perform functional integrity verification and compatibility testing on the updated application; If the updated application passes the functional integrity check and the compatibility test, the updated application is released.

[0010] Optionally, the method further includes: after determining the target plugin, performing standardized encapsulation processing on the target plugin.

[0011] Optionally, determining the target plugin based on the preset mapping relationship between the technology stack and plugins and the technology stack of the application includes: Based on the preset mapping relationship between the technology stack and the plugins and the technology stack of the application, at least one candidate plugin is determined; Based on the application's technology stack, determine the plugin priority conditions and plugin compatibility conditions; Among the at least one candidate plugin, the plugin that meets the plugin priority condition and the plugin compatibility condition will be selected as the target plugin.

[0012] Secondly, embodiments of this application provide an apparatus corresponding to an application publishing method, the apparatus comprising: The technology stack determination module is used to determine the technology stack of the application. The target plugin determination module is used to determine the corresponding target plugin based on the technology stack. An update judgment module is used to determine whether the application needs to be updated; An integration module is used to integrate the target plugin into the application if the application needs to be updated, and to determine the application to be updated; The publishing module is used to publish the updated application.

[0013] Optionally, the technology stack determination module includes: The information acquisition submodule is used to acquire at least one of the following: code text features of the application, development environment configuration information, and system information during the runtime of the application. The application technology stack determination submodule is used to determine the technology stack of the application based on at least one of the code text characteristics, the development environment configuration information, and the system information of the application runtime.

[0014] Optionally, the target plugin determination module includes: The mapping determination submodule is used to determine the target plugin based on the preset mapping relationship between the technology stack and the plugin and the technology stack of the application. The download address determination submodule is used to determine the download address of the target plugin from a preset plugin library.

[0015] Optionally, the update determination module includes: The version number acquisition submodule is used to acquire the version number information of the application's plugins and the version number information of the target plugin; The version number comparison submodule is used to compare the version number information of the application's plugins with the version number information of the target plugin; The update determination submodule is used to determine if the comparison results are inconsistent, and to determine that the application needs to be updated.

[0016] Optionally, the publishing module includes: The verification and testing submodule is used to perform functional integrity verification and compatibility testing on the updated application. The program release submodule is used to release the updated application if the updated application passes the functional integrity verification and the compatibility test.

[0017] Optionally, the device further includes: The plugin encapsulation submodule is used to perform standardized encapsulation processing on the target plugin after the target plugin is determined.

[0018] Optionally, the mapping determination submodule includes: The candidate plugin determination unit is used to determine at least one candidate plugin based on the preset mapping relationship between the technology stack and the plugin and the technology stack of the application. The plugin selection condition determination unit is used to determine plugin priority conditions and plugin compatibility conditions based on the technology stack of the application. The target plugin selection unit is used to select the plugin that meets the plugin priority condition and the plugin compatibility condition as the target plugin from the at least one candidate plugin.

[0019] Thirdly, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0020] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect.

[0021] In this embodiment, by determining the application's technology stack and then identifying the corresponding target plugin based on that stack, intelligent and automated plugin selection is achieved. This allows for precise matching of the most suitable update plugin to applications with different technology stacks, avoiding the complexity and uncertainty of manual plugin selection. By determining whether the application needs an update, and if so, integrating the target plugin into the application, the system intelligently identifies the application's update requirements, avoiding unnecessary update operations, saving system resources, and minimizing the impact on normal user experience. This automated plugin integration process seamlessly integrates the target plugin into the original application, generating an updated application version and improving integration efficiency and success rate. Attached Figure Description

[0022] Figure 1 This is a flowchart illustrating the steps of an embodiment of the application publishing method of the present invention; Figure 2 This is a flowchart illustrating a specific application of the application publishing method of the present invention. Figure 3 This is a schematic diagram of the application release management system according to an embodiment of the application release method of the present invention; Figure 4 This is a structural block diagram of an embodiment of the application publishing device of the present invention. Detailed Implementation

[0023] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0024] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0025] The application publishing method, apparatus, device, and medium provided in this application will be described in detail below with reference to the accompanying drawings and through specific embodiments and application scenarios.

[0026] Reference Figure 1 The flowchart illustrates the steps of an embodiment of the application publishing method of the present invention, which may specifically include the following steps: Step 101: Determine the technology stack of the application; In this step, the first step is to identify the technology stack used by the application to be released. The technology stack refers to a collection of technical components used in the application development process, which typically includes programming languages, development frameworks, runtime environments, third-party libraries, and other related technical elements.

[0027] For example, the technology stack of an application can be determined in several ways. One method is to perform static analysis on the application's source code, extracting key programming language terms, imported library names, annotation tags, and other characteristic information to infer the technology framework it uses. For instance, detecting a large number of Spring-related annotations and Maven build configuration files indicates that the application uses the Spring Boot technology stack.

[0028] Additionally, by parsing the application's build configuration file, information such as project dependencies, compiler version, and runtime environment can be extracted to help determine the technology stack composition. Simultaneously, dynamic information such as JVM parameters, container image tags, and operating system type can be collected from the application's runtime environment to further verify the accuracy of the technology stack.

[0029] In one example, suppose an application is an enterprise-level web service system with a typical Spring Boot project structure in its source code directory and corresponding dependencies declared in its build configuration file. The plugin management service module can accurately identify that the application's technology stack is a combination of Java and Spring Boot. By fusing information from multiple dimensions, the accuracy of technology stack identification can be effectively improved, avoiding potential misjudgments that might occur with a single identification method.

[0030] Step 102: Determine the corresponding target plugin based on the technology stack; After successfully identifying the application's technology stack, it's necessary to match it with suitable target plugins. Here, target plugins refer to pre-packaged software components with specific functions. For example, a technology stack classification database can be maintained, storing association information between different technology stack types and recommended plugins. By matching the application's technology stack characteristics with records in the database, the corresponding target plugins can be determined. In one example, a rule engine can be used to implement plugin matching, pre-setting a series of matching rules to automatically filter out plugins that meet the conditions based on the application's technology stack characteristics. In another example, a plugin recommendation model can be built based on machine learning algorithms, using historical data for training to predict the most suitable target plugin for the current technology stack.

[0031] Step 103: Determine whether the application needs to be updated; In this step, it's necessary to determine if an application update is necessary to avoid unnecessary resource consumption. For example, a timestamp comparison can be used to determine update requirements. Specifically, the application's last update time is recorded and compared to the target plugin's release time; if the target plugin's release time is more recent, the update process is triggered. In one example, a periodic check mechanism can be set up to automatically detect the existence of new plugin versions at preset time intervals, thus determining whether an update operation is needed. In another example, an event-driven approach can be used to determine update requirements; when a security vulnerability announcement or an important feature update is detected, the application update check process is immediately triggered.

[0032] In one implementation, the judgment logic is based on version number comparison. The specific process includes obtaining the version information of the current application plugin, either by reading the application's internal metadata file or by calling the plugin's API interface. Simultaneously, the version information of the target plugin is obtained, and its version identifier is extracted from the target plugin identified in the previous steps. Then, the two are compared numerically under semantic version number rules. If the current plugin version is found to be behind the target plugin version, the application is determined to need an update; otherwise, it is considered that no update is needed, and the process ends or enters a waiting period for the next check cycle.

[0033] It is worth noting that in certain special application scenarios, more flexible update strategies can also be adopted, such as time-driven updates, event-driven updates, or user behavior-driven updates.

[0034] Step 104: If the application needs to be updated, integrate the target plugin into the application and determine the application to be updated; Once it's confirmed that the application needs an update, a plugin integration operation must be performed to integrate the target plugin into the original application. For example, integration can be achieved through plugin injection, dynamically loading the target plugin's code module into a specified location within the application, creating a new application version. In one example, hot deployment technology can be used to complete the plugin integration and replacement without interrupting application operation. In another example, an incremental update package can be generated, containing only the code and configuration files that need to be changed. A differential algorithm is then used to calculate the minimum update set, which is then applied to the original application.

[0035] Step 105: Publish the updated application.

[0036] The final step is to officially release the updated application. For example, the update package can be distributed to a content delivery network (CDN), using multi-node synchronization to improve download efficiency and availability. One example is a canary release strategy, initially pushing the update to a subset of users and gradually expanding the release based on feedback. Another example is establishing a version rollback mechanism, continuously monitoring the application's running status after the update is released, and automatically reverting to the previous stable version when an anomaly is detected.

[0037] By identifying the application's technology stack and determining the corresponding target plugins based on that stack, intelligent and automated plugin selection is achieved. This allows for precise matching of the most suitable update plugins to applications with different technology stacks, avoiding the complexity and uncertainty of manual plugin selection. By determining whether the application needs an update, and if so, integrating the target plugin into the application, the system intelligently identifies the application's update requirements, avoiding unnecessary update operations, saving system resources, and minimizing the impact on normal user experience. This automated plugin integration process seamlessly integrates the target plugin into the original application, generating an updated application version and improving integration efficiency and success rate.

[0038] In one embodiment, step 101 may include the following sub-steps: Sub-step S11: Obtain at least one of the following: code text features of the application, development environment configuration information, and system information of the application at runtime; Static code analysis can be used to scan application source code files and extract their textual features. Static code analysis refers to the technique of obtaining program characteristics by analyzing the syntax structure, keyword usage, and comment markers of the source code without executing the program. These characteristics include, but are not limited to, the use of programming language keywords (such as "class" and "public" in Java), framework-specific annotation markers (such as "@RestController" and "@Service" in the Spring framework), and library import statements (such as the "import" statement in Python), among other code structure information.

[0039] In one example, the application's project configuration file can be read to obtain development environment configuration information. Here, a project configuration file refers to a text file used during software development to describe project build information, dependencies, environment settings, and so on. Common project configuration files include the pom.xml file (Maven build tool configuration file) and build.gradle file (Gradle build tool configuration file) for Java projects, and the package.json file (npm package management configuration file) for Node.js projects. These configuration files typically record development-related metadata such as project build tool information, dependency library lists, compilation parameter settings, and environment variable configurations.

[0040] In another example, system information during application runtime can be obtained through system monitoring interfaces or log collection tools, including but not limited to runtime environment data such as process memory usage, CPU utilization, thread pool status, virtual machine startup parameters, and operating system version. Here, system monitoring interfaces refer to program interfaces provided by the operating system or runtime environment for obtaining system status information, such as the / proc file system in Linux or the WMI interface in Windows; virtual machine startup parameters refer to configuration parameters specified by the Java Virtual Machine (JVM) or other language virtual machines at startup, such as heap memory size settings (-Xmx) and garbage collector selection (-XX:+UseG1GC).

[0041] Sub-step S12: Determine the technology stack of the application based on at least one of the code text features, the development environment configuration information, and the system information of the application runtime.

[0042] Feature matching algorithms can be used to compare the acquired code text features with a pre-defined technology stack feature library, and the most matching technology stack type can be identified by calculating a similarity score. Feature matching algorithms refer to computational methods that classify and identify technologies by comparing the similarity between the features of the object to be identified and the features of known samples. Commonly used algorithms include cosine similarity calculation, Euclidean distance calculation, and edit distance algorithm. The technology stack feature library refers to a pre-established dataset containing typical features of various technology stacks; each technology stack has a corresponding feature vector or feature rule in the feature library.

[0043] In one example, a multi-dimensional information fusion mechanism can be established to analyze and process different types of information separately, and then combine the analysis results from each dimension to determine the final technical stack identification result through a voting mechanism or weighted calculation. Here, multi-dimensional information fusion refers to the technical means of comprehensively processing analysis results from different information sources or different types, thereby improving identification accuracy by integrating information from multiple dimensions; the voting mechanism refers to the decision-making method of statistically analyzing multiple identification results and selecting the identification result with the most votes as the final result.

[0044] In another example, a rule-based reasoning engine can be used. This engine pre-defines a series of rules for identifying technology stacks. Based on the acquired information features, each rule condition is matched. When a specific rule is met, the corresponding technology stack combination can be determined. Here, a rule-based reasoning engine refers to a software system that performs logical reasoning and decision-making based on a predefined set of rules, using if-then conditional statements to automate decisions. Technology stack identification rules refer to conditions derived manually or through machine learning to determine the type of technology stack. For example, "If the code contains the @RestController annotation and the pom.xml file contains the spring-boot-starter-web dependency, then it is determined to be a Spring Boot technology stack."

[0045] By acquiring at least one of the application's code text features, development environment configuration information, and runtime system information, and determining the application's technology stack based on this multi-dimensional information, the accuracy and reliability of technology stack identification can be significantly improved. This avoids the misjudgment problems that may exist with a single information source, and greatly improves the identification accuracy through mutual verification and supplementation of multi-source information.

[0046] In one embodiment, step 102 may include the following sub-steps: Sub-step S21: Determine the target plugin based on the preset mapping relationship between the technology stack and the plugin and the technology stack of the application. A pre-established mapping table of technology stacks and plugins can be queried. This table records the correspondence between various technology stack types and their recommended plugins. By matching the identified application technology stack with the records in the mapping table, the suitable target plugins for that technology stack can be determined. This pre-established mapping relationship refers to a standardized lookup table or database established during the system design phase, where each technology stack entry is associated with the identification information of one or more recommended plugins. For example, the Java technology stack can be mapped to a Java update plugin, and the Spring Boot technology stack can be mapped to a dedicated Spring Boot version management plugin.

[0047] In one example, a key-value pair query can be used, where the application's technology stack is used as the query key to find the corresponding plugin value in a mapping database, thereby quickly locating the target plugin. In another example, when a technology stack corresponds to multiple candidate plugins, the most suitable plugin can be selected as the target plugin based on preset priority rules or a scoring mechanism.

[0048] Sub-step S22: Determine the download address of the target plugin in the preset plugin library.

[0049] A plugin repository can be maintained within the system, storing the installation package files of various plugins and their corresponding network access addresses. By querying the target plugin record in the repository, the download address information of that plugin can be obtained. This default plugin repository refers to a centralized storage area within the system that stores and manages various plugin resources; it can be a local file system, a network storage server, or a cloud object storage service. The plugin repository not only stores the plugin's binary files but also maintains the plugin's metadata information, including version number, release date, download address, and dependencies.

[0050] In one example, the plugin library employs a distributed storage architecture, distributing plugin files across multiple server nodes and providing highly available download services through load balancing technology. In another example, the plugin library supports version management, storing different versions of the same plugin in the library and distinguishing them using version identifiers to ensure accurate retrieval of the download address for a specific version of the plugin.

[0051] By establishing a pre-defined mapping between technology stacks and plugins, and directly querying matching target plugins based on the application's technology stack, plugin selection can be automated and standardized, avoiding the complexity and uncertainty of manual plugin screening. Using a pre-defined plugin library to uniformly manage plugin resources and maintaining accurate download address information for each plugin ensures the reliability and security of plugin acquisition, preventing security risks caused by plugins from unknown sources.

[0052] Sub-step S21 may include the following sub-steps: Sub-step S211: Based on the preset mapping relationship between the technology stack and the plugin and the technology stack of the application, determine at least one candidate plugin; You can retrieve a list of all available plugins associated with your application's technology stack by querying a pre-defined database of technology stack and plugin mappings. Since a technology stack may correspond to multiple plugins with similar functionality but different versions, the query results typically include multiple candidate plugins. These candidate plugins refer to all optional plugins that meet the technology stack requirements in the initial screening stage. These plugins functionally meet the application's basic needs, but may differ in terms of version, performance, and compatibility.

[0053] In one example, a fuzzy matching algorithm can be used to not only find plugins that match exactly, but also identify partially matching plugins as alternatives, thereby expanding the range of candidate plugins. In another example, plugins can be filtered based on their category tags, including plugins with the same functional tags but different implementations in the candidate range, providing more options for the subsequent optimization process.

[0054] Sub-step S212: Determine plugin priority conditions and plugin compatibility conditions based on the technology stack of the application. Based on the application's technology stack characteristics, its specific requirements for plugins can be analyzed, thereby formulating corresponding priority evaluation criteria and compatibility verification rules. Plugin priority conditions here refer to the evaluation criteria used to assess and rank the importance of candidate plugins, typically including factors such as the plugin's version age, functional completeness, performance, and user feedback. Plugin compatibility conditions refer to the environmental requirements and technical specifications that a plugin must meet to function properly, including compatibility with existing application components, dependencies on the runtime environment, and system resource usage limits.

[0055] In one example, a multi-dimensional evaluation model can be established, quantifying metrics such as plugin version number, release date, download count, and user ratings into priority scores, while parameters such as plugin dependency library versions, memory usage, and CPU requirements are used as compatibility check items. In another example, a dynamic weighting mechanism can be employed, automatically adjusting the weight ratios of various evaluation criteria based on the characteristics of different technology stacks. For instance, enterprise applications prioritize stability, thus giving higher weight to version maturity; while applications in the development phase prioritize functional completeness, thus giving higher weight to new feature support.

[0056] Sub-step S213: Among the at least one candidate plugins, the plugin that meets the plugin priority condition and the plugin compatibility condition is selected as the target plugin.

[0057] All candidate plugins can be comprehensively evaluated, and the most suitable target plugin can be determined through a dual screening process of priority scoring and compatibility verification.

[0058] In one example, a tiered screening strategy can be employed. First, compatibility filtering is performed to exclude plugins that do not meet basic operational requirements. Then, among the compatible plugins, they are sorted by priority score, and the plugin with the highest score is selected as the target plugin. In another example, a threshold-based decision mechanism can be set. Only when all evaluation metrics of a candidate plugin reach a preset threshold can it be selected as the target plugin, thus ensuring that the selected plugins have sufficient quality and reliability.

[0059] By identifying multiple candidate plugins before making a final selection, the limitations of choosing a single plugin can be avoided, providing applications with a wider range of plugin options and improving the flexibility and adaptability of plugin matching. The dual evaluation mechanism, employing both plugin priority and compatibility criteria, ensures that the selected target plugins meet functional requirements and possess good operational stability, effectively reducing the risk of plugin incompatibility or poor performance.

[0060] In one embodiment, step 103 may include the following sub-steps: Sub-step S31: Obtain the version number information of the application's plugin and the version number information of the target plugin; The version number information of the plugins currently used by the application can be obtained by reading the application's internal metadata file or by calling the plugin management interface. Simultaneously, the version number identifier can be obtained by querying the target plugin's attribute information. Here, version number information refers to a string or numeric sequence used to identify the software or plugin version, typically employing semantic versioning specifications and including components such as major version number, minor version number, and revision number. For example, "1.2.3" indicates a major version number of 1, a minor version number of 2, and a revision number of 3.

[0061] In one example, version number information can be extracted by parsing the plugin's configuration file or manifest file. These files typically contain basic attribute descriptions of the plugin, with the version number being a required core field. In another example, a query request can be sent to the plugin management system via an application programming interface (API) call to obtain detailed version information for a specified plugin, including metadata such as the current version, latest version, and release date.

[0062] Sub-step S32: Compare the version number information of the application's plugin with the version number information of the target plugin; Semantic version number comparison algorithms can be used to compare the current plugin version number with the target plugin version number digit by digit to determine if there are any differences. In one example, a standardized version number comparison function can be used, comparing the major version number first, then the minor version number, and finally the revision number. A difference is determined when any digit is unequal. In another example, a version range matching mechanism can be used, which not only determines if the version numbers are exactly the same but also identifies version compatibility relationships, such as whether the target version falls within the upgrade range of the current version.

[0063] Sub-step S33: If the comparison results are inconsistent, it is determined that the application needs to be updated.

[0064] When a difference is detected between the current plugin version number and the target plugin version number, the system will trigger an update judgment flag, indicating that the application needs to perform a version upgrade operation.

[0065] In one example, detailed update policy rules can be set, which can not only judge based on version number differences, but also combine version type (such as major updates, feature updates, bug fixes) to decide whether to perform an update operation. In another example, a version update log tracking mechanism can be established to record the results of each version comparison and the basis for update decisions, which will facilitate subsequent auditing and problem tracing.

[0066] By automatically obtaining and accurately comparing the current plugin version number and the target plugin version number, the system automates and intelligently determines update requirements, avoiding the tedious process and potential errors of manually checking version information. A standardized version number comparison mechanism ensures the accuracy and consistency of version difference assessments, preventing misjudgments caused by inconsistent version number formats or non-standard comparison logic.

[0067] In one embodiment, step 105 may further include the following sub-steps: Sub-step S41: Perform functional integrity verification and compatibility testing on the updated application. After the updated application is built, a series of quality verification tests can be performed, including functional integrity verification and compatibility testing, to ensure that the updated application can run normally and does not introduce new problems. Functional integrity verification refers to the testing process that verifies whether the core functions of the application still work correctly after the update, including but not limited to business logic verification, API call testing, and data processing accuracy checks. Compatibility testing refers to the testing process that verifies whether the application can run stably under different operating environments and configuration conditions, including operating system compatibility, browser compatibility, hardware compatibility, and third-party component compatibility.

[0068] In one example, an automated testing framework can be used to execute a pre-defined set of test cases, simulating user operations and system calls to verify whether the application's various functions behave as expected. In another example, a multi-environment testing mechanism can be established to deploy the updated application under different operating systems, hardware configurations, and network environments, verifying its performance in various real-world usage scenarios.

[0069] Sub-step S42: If the updated application passes the functional integrity check and the compatibility test, the updated application is released.

[0070] Once the updated application successfully passes all preset quality verification tests, the system will perform the formal release operation, pushing the updated application to the production environment or distribution platform for user use. In one example, a phased release strategy can be adopted, first deploying the tested updated application to a pre-release environment for small-scale verification, and then gradually expanding the release scope after confirming it is error-free. In another example, a release approval process can be established, allowing the final release operation only when the test report shows that all key indicators meet preset standards, ensuring controllable release quality.

[0071] By performing functional integrity checks and compatibility tests before application release, defective updates can be effectively prevented from being deployed to the production environment, reducing the risk of system failures and user complaints. The use of automated quality verification mechanisms ensures that each update release undergoes a rigorous quality control process, improving the stability and reliability of the application.

[0072] In one embodiment, the method may further include the following: After identifying the target plugin, the target plugin is subjected to standardized encapsulation processing.

[0073] After successfully identifying the target plugin, it can be standardized and packaged to conform to predefined plugin specifications and interface standards, facilitating subsequent integration and use. Standardized packaging refers to the process of reorganizing and repackaging the plugin according to a unified format and specifications, including but not limited to interface standardization, configuration file standardization, dependency management, and security checks. Standardized packaging eliminates differences between plugins from different sources, ensuring consistent usage and behavior.

[0074] In one example, the plugin's interface can be uniformly encapsulated, converting the original diverse calling methods into a standardized API interface, allowing applications with different technology stacks to invoke plugin functionality in the same way. In another example, the plugin's configuration parameters can be standardized, consolidating configuration items scattered in different locations into a unified configuration file and providing standard configuration reading and modification interfaces, simplifying plugin configuration management. In yet another example, plugin security can be enhanced, including code signature verification, malicious code scanning, and access control settings, ensuring the encapsulated plugin has higher security and trustworthiness.

[0075] Reference Figure 2 The flowchart illustrates a specific application process of an embodiment of the application publishing method of the present invention, which is as follows: Based on the aforementioned embodiments, and using the core technologies such as technology stack identification, plugin matching, and version comparison, a full lifecycle management system covering plugin building, application creation, and plugin integration has been further constructed.

[0076] As mentioned above, sub-steps S11-S12 enable accurate identification of the application technology stack, sub-steps S21-S22 and S211-S213 enable intelligent matching and optimization of target plugins, sub-steps S31-S33 enable automatic judgment of update requirements, sub-steps S41-S42 ensure quality control of update releases, and after the target plugins are identified, standardized encapsulation is performed to improve the universality and security of the plugins.

[0077] In this embodiment, the aforementioned technical steps are organically integrated into a complete business process. Specifically, during the plugin construction phase, based on the configuration information of the application technology stack, the system searches for pre-built plugin projects corresponding to the technology stack in the plugin management service module. For example, for an application using the Spring Boot technology stack, the system will search for pre-built Spring Boot plugin projects. Then, the system downloads the plugin project and implements standardized encapsulation of functions such as version checking and version installation through coding. After the standardized encapsulation of the version update plugin is packaged, it is managed uniformly by the platform's plugin management service module. The specific process of the plugin construction phase includes: performing a technology stack selection operation through the plugin construction tool; performing a plugin project creation operation; integrating the version update service based on the plugin project code and implementing version checking and update functions; packaging the plugin and uploading it to the plugin management library, using the plugin package download address as input information for the next stage; and finally, ending the plugin construction phase process.

[0078] In the implementation of the application management service module, applications are categorized according to their operating platform, including server-side applications, client-side applications, and web applications. For each application category, a corresponding technology stack is preset; for example, client-side applications include Android, iOS, and Harmony technology stacks. During the application creation phase, the technology stack information for the applications to be managed is configured. For instance, if a server-side application based on the Java technology stack needs to be created, it is configured as a server-side application → Java technology stack → Spring Boot framework. The specific process of the application creation phase includes: setting the platform information for the business application's operation through the application version release platform; setting the business application's development technology stack information; using the plugin package download address as input, performing operations to associate plugin package information; performing the application release operation, using the plugin package download address as input for the next stage; and finally, ending the application creation phase process.

[0079] After standardizing and adapting the version update functionality for different technology stacks through the aforementioned two stages, the plugin integration stage allows users to locate and download the corresponding update plugin for their business application's technology stack from the plugin management service module. This enables the business application to quickly and non-intrusively integrate the version update functionality. The specific process of the plugin integration stage includes: downloading the plugin via the plugin package download address; integrating the downloaded plugin into the business application project through coding; packaging and building the plugin-integrated business application; and finally, concluding the plugin integration stage.

[0080] This embodiment organically combines the aforementioned technical features to form a complete technical chain from intelligent plug-in construction and precise application configuration to seamless plug-in integration. It not only fully leverages the advantages of each individual technical innovation but also achieves the overall synergistic effect of the technical solution, further enhancing the automation and intelligence of application version management.

[0081] Reference Figure 3 The diagram illustrates a program release management system according to an embodiment of the application release method of the present invention, specifically including: Based on the aforementioned embodiments, the entire application version release process is divided into three relatively independent stages according to business logic and functional responsibilities: version building stage, version release stage, and version update stage, thereby realizing modular management and flexible configuration of the release process.

[0082] As mentioned above, sub-steps S11-S12 enable accurate identification of the application technology stack, sub-steps S21-S22 and S211-S213 enable intelligent matching and optimization of target plugins, sub-steps S31-S33 enable automatic judgment of update requirements, sub-steps S41-S42 ensure quality control of update releases, and after the target plugins are identified, standardized encapsulation is performed to improve the universality and security of the plugins.

[0083] In this embodiment, the aforementioned technical features are organically integrated into a phased release management system. Specifically, the version build phase is primarily responsible for compiling and packaging the application. In this phase, the application is built using an application packaging tool corresponding to the corresponding technology stack, generating an executable application package. For example, for Android client applications, professional packaging tools such as bundletool can be used for building. The generated application package is then uploaded to a file server for storage and management. After the build is complete, the system determines whether to perform an application version release operation. If no release is selected, the version build process ends; if release is selected, the accessible address of the application files is used as input information for executing the next phase (version release phase).

[0084] The version release phase primarily handles application version registration and approval management. During this phase, the application is created through the application version release platform, and basic application information is entered. Next, a branch is created, and branch-related information is entered. Then, a version is created, and version information and the application package download address are entered. After completing the basic information entry, the version release approval process is executed. Upon approval, the system confirms whether to officially release the version. If the user chooses not to release, the version release process ends; if the user chooses to release, the latest version information is used as input for the next phase (version update phase).

[0085] The version update phase is primarily responsible for detecting and pushing updates to the terminal application. In this phase, the application version update plugin first retrieves the current terminal application's version information and outputs it. Then, it inputs the terminal application version information and the latest version information, performing a version check. The system determines if the current terminal application is the latest version; if so, the version update process ends; otherwise, it continues with subsequent operations. Next, it determines whether to perform a forced update. If a forced update is selected, it executes a sub-process of downloading and installing the update package and restarting the application; if a non-forced update is selected, the version update phase ends directly.

[0086] It's worth noting that flexible implementation methods are provided during the version building phase. For scenarios lacking continuous integration / continuous deployment (CI / CD) capabilities, manual building and application version uploading can be achieved through local tools. In scenarios with CI / CD capabilities, the platform can integrate the CI / CD process via webhooks to automate building and deployment.

[0087] Furthermore, by configuring the application build configuration items in the application management service module, the version build methods for the above-mentioned different scenarios can be progressively switched and kept compatible, enabling the entire system to adapt to different development stages from traditional manual build to modern automated build, thereby improving the system's adaptability and scalability.

[0088] This embodiment organically integrates the aforementioned technical features into a phased release management system, which not only fully leverages the advantages of each individual technological innovation but also achieves the overall synergistic effect of the technical solution, further enhancing the flexibility, reliability, and maintainability of application version management.

[0089] In another embodiment, based on the foregoing embodiments, the present invention also provides a role-based application version release approval scheme. This scheme achieves flexible and standardized management of the release approval process by pre-setting different project roles and dynamically configuring the approval process based on those roles.

[0090] In this embodiment, the role management service module presets different functional roles such as project manager, test manager, and development manager. Based on these preset roles, the approval workflow service module can dynamically define the approval workflow to adapt to role-based approval processes in different scenarios. For example, in a test environment application release scenario, the approval workflow can only set the test manager and development manager as the approval subjects; while in a production environment application release scenario, the approval workflow can set the project manager, test manager, and development manager as the approval subjects.

[0091] Based on the above role management and approval process configuration, the application version release process specifically includes the following steps: The project manager requests the project management service module to create the project; the project management service module returns a record of successfully added project for the project manager to view; the development manager requests the project management service module to view the record of added project; the project management service module returns the record for the development manager to view; the development manager requests the application management service module to create the application; after the application management service module successfully adds the application, it requests the branch management service module to initialize the default branch; the branch management service module returns a message indicating that the default branch has been successfully created; the application management module returns a message indicating that the application has been successfully added to the development manager.

[0092] If the default branch does not meet the requirements, the development lead can request the branch management service module to create a custom branch. After the custom branch is successfully created, the branch management service module returns a message indicating that the custom branch has been successfully added to the development lead. Subsequently, the development lead requests the application management service module to retrieve the application record; the application management service module returns the application record to the development lead. The development lead then requests the project management service module to associate the application; the project management service module returns a message indicating that the application has been successfully associated to the development lead.

[0093] The project manager requests the workflow approval service module to create a version release approval workflow task; the workflow approval service module returns a message indicating successful creation of the approval task to the project manager and triggers the approval process; the workflow approval service module sends an application version release notification to the project manager; after receiving the application version release notification, the project manager confirms the application version release information, requests the version management service module to create version information and upload the update package; the application version management service module returns a message indicating successful version creation to the development manager.

[0094] The development lead requests confirmation of the version release from the version management service module; the version management service module returns a version release success message to the development lead, and the workflow approval service module receives the version release success message and notifies the project manager that the version release was successful; the version management service module pushes version information to the version update plugin; the version update plugin performs a version check; if the version update plugin detects that the pushed version information is new version information, it requests the version management service module to download the new version package; the version management service module returns the new version package; the version update plugin installs the new version package and completes the update.

[0095] This embodiment achieves standardized management of the application version release process through standardized role definitions and dynamic approval process configuration.

[0096] By identifying the application's technology stack and determining the corresponding target plugins based on that stack, intelligent and automated plugin selection is achieved. This allows for precise matching of the most suitable update plugins to applications with different technology stacks, avoiding the complexity and uncertainty of manual plugin selection. By determining whether the application needs an update, and if so, integrating the target plugin into the application, the system intelligently identifies the application's update requirements, avoiding unnecessary update operations, saving system resources, and minimizing the impact on normal user experience. This automated plugin integration process seamlessly integrates the target plugin into the original application, generating an updated application version and improving integration efficiency and success rate.

[0097] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0098] Reference Figure 4 The diagram illustrates a structural block diagram of an embodiment of the application publishing device of the present invention, which may specifically include the following modules: Technology stack determination module 201 is used to determine the technology stack of the application. The target plugin determination module 202 is used to determine the corresponding target plugin based on the technology stack. The update judgment module 203 is used to determine whether the application needs to be updated; Integration module 204 is used to integrate the target plugin into the application if the application needs to be updated, and to determine the application to be updated; The publishing module 205 is used to publish the updated application.

[0099] In one embodiment, the technology stack determination module includes: The information acquisition submodule is used to acquire at least one of the following: code text features of the application, development environment configuration information, and system information during the runtime of the application. The application technology stack determination submodule is used to determine the technology stack of the application based on at least one of the code text characteristics, the development environment configuration information, and the system information of the application runtime.

[0100] In one embodiment, the target plugin determination module includes: The mapping determination submodule is used to determine the target plugin based on the preset mapping relationship between the technology stack and the plugin and the technology stack of the application. The download address determination submodule is used to determine the download address of the target plugin from a preset plugin library.

[0101] In one embodiment, the update determination module includes: The version number acquisition submodule is used to acquire the version number information of the application's plugins and the version number information of the target plugin; The version number comparison submodule is used to compare the version number information of the application's plugins with the version number information of the target plugin; The update determination submodule is used to determine if the comparison results are inconsistent, and to determine that the application needs to be updated.

[0102] In one embodiment, the publishing module includes: The verification and testing submodule is used to perform functional integrity verification and compatibility testing on the updated application. The program release submodule is used to release the updated application if the updated application passes the functional integrity verification and the compatibility test.

[0103] In one embodiment, the device further includes: The plugin encapsulation submodule is used to perform standardized encapsulation processing on the target plugin after the target plugin is determined.

[0104] In one embodiment, the mapping determination submodule includes: The candidate plugin determination unit is used to determine at least one candidate plugin based on the preset mapping relationship between the technology stack and the plugin and the technology stack of the application. The plugin selection condition determination unit is used to determine plugin priority conditions and plugin compatibility conditions based on the technology stack of the application. The target plugin selection unit is used to select the plugin that meets the plugin priority condition and the plugin compatibility condition as the target plugin from the at least one candidate plugin.

[0105] The device corresponding to the application publishing method in this application embodiment can be a device, or a component, integrated circuit, or chip in a terminal. The device can be a mobile electronic device or a non-mobile electronic device. For example, a mobile electronic device can be a mobile phone, tablet computer, laptop computer, PDA, in-vehicle electronic device, wearable device, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc. A non-mobile electronic device can be a server, network attached storage (NAS), personal computer (PC), television (TV), ATM, or self-service machine, etc. This application embodiment does not impose specific limitations.

[0106] The device corresponding to the application publishing method in this application embodiment can be a device with an operating system. This operating system can be Android, iOS, or other possible operating systems; this application embodiment does not specifically limit the specific operating system used.

[0107] The apparatus corresponding to the application publishing method provided in this application embodiment can achieve... Figures 1 to 3 The various processes implemented by the device corresponding to the application publishing method in the method embodiment will not be described again here to avoid repetition.

[0108] By identifying the application's technology stack and determining the corresponding target plugins based on that stack, intelligent and automated plugin selection is achieved. This allows for precise matching of the most suitable update plugins to applications with different technology stacks, avoiding the complexity and uncertainty of manual plugin selection. By determining whether the application needs an update, and if so, integrating the target plugin into the application, the system intelligently identifies the application's update requirements, avoiding unnecessary update operations, saving system resources, and minimizing the impact on normal user experience. This automated plugin integration process seamlessly integrates the target plugin into the original application, generating an updated application version and improving integration efficiency and success rate.

[0109] This invention also provides an electronic device, including: a processor, a memory, and a computer program stored in the memory and capable of running on the processor. When the computer program is executed by the processor, it implements the various processes of the above-described application publishing method embodiment and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0110] This invention also provides a readable storage medium on which a computer program is stored. When the computer program is executed by a processor, it implements the various processes of the above-described application deployment method embodiment and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0111] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0112] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0113] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0114] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. An application publishing method, characterized in that, The method includes: Determine the application's technology stack; Determine the corresponding target plugin based on the technology stack; Determine whether the application needs to be updated; If the application needs to be updated, the target plugin will be integrated into the application, and the application to be updated will be determined. Release the updated application.

2. The application publishing method according to claim 1, characterized in that, The technology stack of the determined application includes: Obtain at least one of the following: code text characteristics of the application, development environment configuration information, and system information during the runtime of the application; The technology stack of the application is determined based on at least one of the code text features, the development environment configuration information, and the system information of the application runtime.

3. The application publishing method according to claim 1, characterized in that, The step of determining the corresponding target plugin based on the technology stack includes: The target plugin is determined based on the preset mapping relationship between the technology stack and the plugin and the technology stack of the application. The download address of the target plugin is determined in the preset plugin library.

4. The application publishing method according to claim 1, characterized in that, The step of determining whether the application needs to be updated includes: Obtain the version number information of the application's plugins and the version number information of the target plugin; Compare the version number information of the application's plugin with the version number information of the target plugin; If the comparison results are inconsistent, the application is determined to need an update.

5. The application publishing method according to claim 1, characterized in that, The application that releases the update includes: Perform functional integrity verification and compatibility testing on the updated application; If the updated application passes the functional integrity check and the compatibility test, the updated application shall be released.

6. The application publishing method according to claim 1, characterized in that, The method further includes: after determining the target plugin, performing standardized encapsulation processing on the target plugin.

7. The application publishing method according to claim 3, characterized in that, The step of determining the target plugin based on the preset mapping relationship between the technology stack and plugins and the technology stack of the application includes: Based on the preset mapping relationship between the technology stack and the plugins and the technology stack of the application, at least one candidate plugin is determined; Based on the application's technology stack, determine the plugin priority conditions and plugin compatibility conditions; Among the at least one candidate plugin, the plugin that meets the plugin priority condition and the plugin compatibility condition will be selected as the target plugin.

8. An apparatus corresponding to an application publishing method, characterized in that, The device includes: The technology stack determination module is used to determine the technology stack of the application. The target plugin determination module is used to determine the corresponding target plugin based on the technology stack. An update judgment module is used to determine whether the application needs to be updated; An integration module is used to integrate the target plugin into the application if the application needs to be updated, and to determine the application to be updated; The publishing module is used to publish the updated application.

9. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the application deployment method as described in claims 1-7.

10. A readable storage medium, characterized in that, The program or instructions are stored on the readable storage medium, and when executed by a processor, the program or instructions implement the steps of the application deployment method as described in claims 1-7.

Images