Module calling method and system of software automation pipeline system

Abstract

The invention belongs to the technical field of computer software. The invention provides a module calling method and system of a software automation pipeline system, a task manager calls a task created according to a template and sends a task creation instruction to a StackStorm platform, and the StackStorm platform feeds back a task creation completion instruction to the task manager; when the task starts automatically, the task manager inquires tools used by the template from the tool manager, and the tool manager sends the inquired tools to the task manager; the task manager pulls the resources and stores the pulled resources to the resource manager and the tool manager, and the tool manager sends the inquired tools and parameters sent by the task manager to the adapter to execute adaptation; the adapter returns an execution result to the task manager, and the task manager stores the execution result into the resource manager; according to the method, rapid and accurate module calling during automatic task execution is realized, and the operation efficiency of a software automation assembly line system is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of computer software, and in particular to a module calling method and system of a software automation pipeline system. Background Art

[0002] The statements in this section merely provide background art related to the present invention and do not necessarily constitute prior art.

[0003] The software automation pipeline system provides a development platform that allows the software development process to be fixed and constrained in the form of a production line, changing the project development process driven by the traditional project manager to the process-driven project development. The system integrates a large number of third-party tools through a reasonable architecture, automates repetitive labor in traditional development, such as compilation, unit testing, deployment, etc., and standardizes processes such as process approval.

[0004] A software automation pipeline system usually includes multiple modules, which can call each other. In previous technologies, when a predetermined event is triggered, each module calls other modules by direct calling. The module that issues the calling action is called the event source, and the called module is called the receiver. This direct calling method makes the coupling between the event source and the receiver high, which is not conducive to software upgrades, and the response speed of the entire call is slow. Summary of the invention

[0005] In order to address the deficiencies in the prior art, the present invention provides a module calling method and system for a software automation pipeline system, which combines a task manager, a StackStorm platform, a resource manager, a tool manager and an adapter, and cooperates with each other to achieve fast and accurate module calling during automatic task execution, thereby improving the operating efficiency of the software automation pipeline system and facilitating the upgrade of the software system.

[0006] In order to achieve the above object, the present invention adopts the following technical solution:

[0007] In a first aspect, the present invention provides a module calling method for a software automation pipeline system.

[0008] A module calling method of a software automation pipeline system, wherein the software automation pipeline system comprises: a task manager, a StackStorm platform, a resource manager, a tool manager and an adapter, and the calling method comprises the following process:

[0009] The task manager calls to create a task based on the template and sends the task creation instruction to the StackStorm platform. The StackStorm platform then feeds back the task creation completion instruction to the task manager.

[0010] The task starts automatically, the task manager queries the tool manager for the tools used in the template, and the tool manager sends the queried tools to the task manager;

[0011] The task manager pulls resources and stores them in the resource manager and tool manager. The tool manager sends the queried tools and parameters sent by the task manager to the adapter for adaptation.

[0012] The adapter returns the execution result directly to the task manager, and the task manager stores the execution result in the resource manager;

[0013] The task manager sends a task completion instruction to the StackStorm platform. After the StackStorm platform completes the specified action, it switches the task status and feeds back to the task manager; or, the task manager sends a task close instruction to the StackStorm platform. After the StackStorm platform completes the specified action, it switches the task status and feeds back to the task manager.

[0014] As a further limitation of the first aspect of the present invention, the task manager includes:

[0015] All tasks are considered as an AOV directed graph. Each node in the AOV directed graph is a task. The dependency between tasks is represented by edges. If task A has an edge pointing to task B, it means that task B depends on task A. If there are two edges pointing to B, (A, B) and (C, B), then A and C must be completed before B can be started.

[0016] The dependency between tasks is defined as a task template group. The task template group consists of multiple task templates and the relationships between them. When creating an iteration of a project, the task template group is specified, and the AOV directed graph of the task is dynamically created based on the task template group.

[0017] Tasks are created dynamically based on the task template group. Tasks will only be truly created when the conditions for task execution are met. Only tasks that are truly created have visualization functions.

[0018] As a further limitation of the first aspect of the present invention, based on the AOV directed graph in the task template group, it is analyzed whether the templates in the task template group have dependencies, and then the task is created based on the information in the task template. After the task is created, resources are prepared for the task according to the definition in the task template. After the task manager calls the resource manager to prepare the resources, if an automatic task is encountered, the tool manager is called to execute the tool according to the tool specified by the task. If it is a manual task, wait for the task to be manually started.

[0019] As a further limitation of the first aspect of the present invention, the software automated pipeline system is a multi-layer AOV directed graph, in which the top layer is the relationship between top-level activities and activities, and a template group is used to describe the AOV directed graph of activities. Through task templates and task visualization processing, the completion status, time, personnel information, and input and output information of the tasks are visualized.

[0020] As a further limitation of the first aspect of the present invention, the resource manager centrally manages input data, intermediate data and output data. When a tool is called, the resource manager automatically places the resource in the specified directory through the resource ID and target location, thereby automatically acquiring the resource based on the resource ID. After generating the result, the tool submits the data to the resource manager.

[0021] As a further limitation of the first aspect of the present invention, in the software automation pipeline system, microservice deployment of business includes:

[0022] Microservices register with Nacos when they start. Multiple instances of the same microservice can be started, and Nacos performs load balancing according to the configured load balancing strategy. SpringCloud's Gateway is used to integrate microservices, provide a unified Web API for the front end, and implement permission verification for microservices.

[0023] As a further limitation of the first aspect of the present invention, in the database, a user creates a project, and an execution is created under the project. One project corresponds to one execution, and the project table and the execution table are in a one-to-one relationship. Under the execution, a template group is selected according to the function, and multiple templates are selected under the template group. The execution and the template group are in a one-to-one relationship, and the template group and the template are in a one-to-many relationship.

[0024] Add multiple template parameters to the template as required, and bind multiple template parameters to multiple tool parameters. The relationship between templates and template parameters is one-to-many, and the relationship between template parameters and tool parameters is many-to-many.

[0025] One template creates multiple tasks. A task selects the tool to be called. One tool adds multiple tool parameters. There is a one-to-many relationship between templates and tasks, a many-to-many relationship between tasks and tools, and a one-to-many relationship between tools and tool parameters.

[0026] In a second aspect, the present invention provides a module calling system for a software automation pipeline system.

[0027] A module calling system for a software automation pipeline system, including a task manager, a StackStorm platform, a resource manager, a tool manager and an adapter;

[0028] The task manager calls to create a task based on the template and sends the task creation instruction to the StackStorm platform. The StackStorm platform then feeds back the task creation completion instruction to the task manager.

[0029] The task starts automatically, the task manager queries the tool manager for the tools used in the template, and the tool manager sends the queried tools to the task manager;

[0030] The task manager pulls resources and stores them in the resource manager and tool manager. The tool manager sends the queried tools and parameters sent by the task manager to the adapter for adaptation.

[0031] The adapter returns the execution result directly to the task manager, and the task manager stores the execution result in the resource manager;

[0032] The task manager sends a task completion instruction to the StackStorm platform. After the StackStorm platform completes the specified action, it switches the task status and feeds back to the task manager; or, the task manager sends a task close instruction to the StackStorm platform. After the StackStorm platform completes the specified action, it switches the task status and feeds back to the task manager.

[0033] As a further limitation of the second aspect of the present invention, the task manager includes:

[0034] All tasks are considered as an AOV directed graph. Each node in the AOV directed graph is a task. The dependency between tasks is represented by edges. If task A has an edge pointing to task B, it means that task B depends on task A. If there are two edges pointing to B, (A, B) and (C, B), then A and C must be completed before B can be started.

[0035] The dependency between tasks is defined as a task template group. The task template group consists of multiple task templates and the relationships between them. When creating an iteration of a project, the task template group is specified, and the AOV directed graph of the task is dynamically created based on the task template group.

[0036] Dynamically create tasks based on the task template group. Tasks will only be created when the task execution conditions are met. Only tasks that are actually created have visualization functions.

[0037] According to the AOV directed graph in the task template group, analyze whether the templates in the task template group have dependencies, and then create a task based on the information in the task template. After the task is created, prepare resources for the task according to the definition in the task template. After the task manager calls the resource manager to prepare the resources, if it is an automatic task, call the tool manager to execute the tool according to the tool specified in the task. If it is a manual task, wait for the task to be started manually.

[0038] As a further limitation of the second aspect of the present invention, in the database, a user creates a project, and an execution is created under the project. One project corresponds to one execution, and the project table and the execution table are in a one-to-one relationship. Under the execution, a template group is selected according to the function, and multiple templates are selected under the template group. The execution and the template group are in a one-to-one relationship, and the template group and the template are in a one-to-many relationship.

[0039] Add multiple template parameters to the template as required, and bind multiple template parameters to multiple tool parameters. The relationship between templates and template parameters is one-to-many, and the relationship between template parameters and tool parameters is many-to-many.

[0040] One template creates multiple tasks. A task selects the tool to be called. One tool adds multiple tool parameters. There is a one-to-many relationship between templates and tasks, a many-to-many relationship between tasks and tools, and a one-to-many relationship between tools and tool parameters.

[0041] Compared with the prior art, the present invention has the following beneficial effects:

[0042] 1. The present invention combines the task manager, StackStorm platform, resource manager, tool manager and adapter, and cooperates with each other to achieve fast and accurate module calling during automatic task execution, improve the operating efficiency of the software automation pipeline system, and facilitate the upgrade of the software system.

[0043] 2. Only when the conditions for task execution are met will the task be actually created and visible to the user. This ensures that the tasks visible to the user can be done at the moment. This requires the system to dynamically create tasks based on the task template group, thereby achieving fast and accurate assembly line operations.

[0044] 3. The present invention analyzes whether the templates in the task template group have dependencies based on the AOV directed graph in the task template group, and then creates a task based on the information in the task template. After the task is created, resources are prepared for the task based on the definition in the task template, thereby improving the efficiency and accuracy of resource allocation.

[0045] Advantages of additional aspects of the present invention will be given in part in the following description, and in part will become obvious from the following description, or will be learned through practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] The accompanying drawings in the specification, which constitute a part of the present invention, are used to provide a further understanding of the present invention. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute improper limitations on the present invention.

[0047] Figure 1 The overall schematic diagram of the software automation pipeline system provided by the present invention;

[0048] Figure 2 A hierarchical schematic diagram of the software automation pipeline system provided by the present invention;

[0049] Figure 3 A schematic diagram of a flow chart of a module calling method of a software automation pipeline system provided by the present invention;

[0050] Figure 4 The system template ER diagram provided by the present invention;

[0051] Figure 5 The user ER diagram provided by the present invention. DETAILED DESCRIPTION

[0052] The present invention will be further described below in conjunction with the accompanying drawings and embodiments.

[0053] It should be noted that the following detailed descriptions are exemplary and are intended to provide further explanation of the present invention. Unless otherwise specified, all technical and scientific terms used herein have the same meanings as those commonly understood by those skilled in the art to which the present invention belongs.

[0054] In the absence of conflict, the embodiments of the present invention and the features of the embodiments may be combined with each other.

[0055] Embodiment 1:

[0056] This implementation method proposes a module calling method of a software automation pipeline system. The software automation pipeline system of this implementation method provides a development platform, such as Figure 1 and Figure 2As shown, the software development process can be fixed and constrained in the form of a production line, changing the transition from the project development process driven by the traditional project manager to the process-driven project development. The system integrates a large number of third-party tools through a reasonable architecture, automates repetitive labor in traditional development, such as compilation, unit testing, deployment, and other behaviors, and standardizes processes such as process approval. The system has a layered structure as a whole, which can be roughly divided into the interface layer, service layer, and storage layer. The interface layer provides an interactive interface for users, allowing the system to display data, allowing users to operate data, and allowing users to complete a series of tasks such as code editing, compilation, and debugging in the interface. The service layer contains a large number of microservices, mainly including: basic support, task management, tool management, storage management, and open APIs for tools and other systems.

[0057] The system also integrates GitLab to complete source code management and the StackStorm platform to complete the integration of third-party tools that are not integrated in the system. The system allows for the simultaneous support of internal tool management and the reuse of existing tools in the StackStorm platform. Therefore, the system supports both internal tool management and the integration of StackStorm platform tools.

[0058] More specifically, this implementation uses a task manager, a StackStorm platform, a resource manager, a tool manager, and an adapter to implement the calling method, such as Figure 3 As shown, the following process is included:

[0059] The task manager calls to create a task based on the template and sends the task creation instruction to the StackStorm platform. The StackStorm platform then feeds back the task creation completion instruction to the task manager.

[0060] The task starts automatically, the task manager queries the tool manager for the tools used in the template, and the tool manager sends the queried tools to the task manager;

[0061] The task manager pulls resources and stores them in the resource manager and tool manager. The tool manager sends the queried tools and parameters sent by the task manager to the adapter for adaptation.

[0062] The adapter returns the execution result directly to the task manager, and the task manager stores the execution result in the resource manager;

[0063] The task manager sends a task completion instruction to the StackStorm platform. After the StackStorm platform completes the specified action, it switches the task status and feeds back to the task manager; or, the task manager sends a task close instruction to the StackStorm platform. After the StackStorm platform completes the specified action, it switches the task status and feeds back to the task manager.

[0064] In this implementation, the task manager is the core of the system scheduling. The system regards all tasks as an AOV directed graph. Each node in the graph is a task. The dependency between tasks is represented by edges. If task A has an edge pointing to task B, it means that task B depends on task A. If there are two edges pointing to B, (A, B) and (C, B), then A and C need to be completed before B can be started.

[0065] In order to reuse the process, the dependencies between tasks are defined as task template groups. Task template groups are composed of multiple task templates and the relationships between task templates. When creating an iteration of a project, you can specify a task template group. The system will dynamically create an AOV directed graph of tasks based on the task template group.

[0066] In order to realize pipeline operation, the system stipulates that only when the conditions for task execution are met, the task will be actually created and visible to users. This ensures that the tasks visible to users are currently available. This requires the system to dynamically create tasks based on the task template group.

[0067] At the beginning of an iteration, the system will analyze whether the templates in the task template group have dependencies based on the AOV directed graph in the task template group, and then create a task based on the information in the task template. After the task is created, resources will be prepared for the task according to the definition in the task template, such as source code required for compilation tasks. After the task manager calls the resource manager to prepare the resources, if it is an automatic task, it calls the tool manager to execute the tool according to the tool specified by the task. If it is a manual task, it waits for the task to be started manually.

[0068] In this implementation, the tool manager provides tool management and invocation. Specifically, a tool is a type of entity managed by the system, which allows users to register multiple tools on the platform. The tool adapter is used as a microservice, and the name of the microservice can be configured to the system through configuration; when the tool is online, the tool will be registered with Nacos; when the tool is used, the tool manager will query the corresponding tool in Nacos and call the tool according to the adapter interface.

[0069] In this implementation, the tool manager provides a set of interface standards through which tools can complete tool integration. When integrating third-party tools, the third-party tool format should be converted into the platform tool format, and the adapter is used to complete this conversion operation.

[0070] In this implementation, the adapter calling process is the process of integrating the adapter into the system as a third-party tool. The process is as follows:

[0071] (1) Get the ssh address of the tool based on toolId, that is, copy the resource to the address of the tool;

[0072] (2) Get the template input according to the execution id and template id, which corresponds to the output resource of the previous template (a resource array storageList);

[0073] (3) Copy the acquired resources to the local tool, i.e., resource migration: traverse the resource array storageList, use the fetchById function in StorageServiceImpl, and find the corresponding resources in the app_storage table through storageId;

[0074] (4) Call the fetch function to get the corresponding resource type type, then compare the resource type. If it is a string, return it directly; if it is a git type, first determine whether localPath is empty. If it is empty, it means that there is no such repository and the repository needs to be cloned. If it is not empty, it only needs to be pulled; if it is a file type, copy the file to the tool path;

[0075] (5) Get the resource again, call the queryParamValue function to get the input parameter list and script required to call the tool, call the start interface of the tool management through FeignClient, and then call the corresponding tool.

[0076] In this implementation, the resource storage implements the centralized management of input data, intermediate data, and output data in the system. The core value of the resource storage lies in data migration in addition to data storage. When the system calls a tool, it needs to provide data support for the tool. At this time, the resource storage automatically places the resource in the specified directory through the resource ID and the target location, realizing the automatic acquisition of resources according to the ID. After the tool generates the result, it submits the data to the storage service. The resource storage in this implementation supports several data types such as code base, files, and folders.

[0077] In this implementation, the StackStorm platform is an event-driven automation system. In the software system, there are multiple tools, each of which can generate events and complete actions. The software uses rule files to implement the binding between events and actions. Events and actions are not limited to the same task. For example, when an event is triggered after a tool is executed, this event can trigger the start of other tools.

[0078] In this implementation, the entire pipeline system can be viewed as a multi-layer AOV directed graph, with the top layer consisting of the top-level activities and the relationships between activities. The system uses template groups to describe the AOV directed graph of "activities"; because the tasks of the system are dynamically generated, simply visualizing the tasks cannot present the entire process. Combining task templates and tasks can reveal which tasks have been started (some have not yet been created), and visualize the completion status, time, personnel information, and input and output information of the tasks.

[0079] This implementation also provides the function of achievement library management. The achievement library includes the management of controlled libraries and product libraries. The achievement in the system is actually a screening and classification management of resource libraries. A large number of intermediate resources will be generated during the development process. Many of these resources are useless to managers. Therefore, by marking the resources, useful resources can be managed in the form of achievement libraries, providing users with a management interface.

[0080] For the storage of results, different types of results are stored in different ways. Specifically, if a task is a compilation task, a git code library is obtained after the task is completed by calling the compilation tool. The results of the task are stored in the resource table as a data type of code library.

[0081] In view of the system's later requirements for load capacity and concurrency as well as the needs for subsequent product upgrades and iterations, we chose to use the SpringCloud family bucket to implement microservice deployment of the business.

[0082] In this implementation, it is preferred to use open source Nacos as the service registration and dynamic configuration distribution. When the microservice is started, it will register the service with Nacos. The same microservice can start multiple instances, and Nacos will balance the load according to the configured load balancing strategy. In addition, Nacos provides a Web management platform that allows users to write microservice configurations (application.yml) on the platform and distribute them dynamically. Unified configuration management is achieved, and Nacos supports distributed deployment, avoiding the hidden dangers caused by single point failures.

[0083] In this implementation, preferably, the Gateway provided by SpringCloud is used to implement the service integration of microservices, provide a unified Web API for the front end, and implement permission verification for microservices. Gateway also exists in the entire architecture as a microservice, that is, it also supports multiple instances and supports distributed architecture.

[0084] In this implementation, preferably, the verification mechanism adopts the Jwt mechanism, which stores information in the Token through encryption and signature algorithms, so as to facilitate asynchronous calls without Session on the front end.

[0085] In this implementation, preferably, cross-service calls are implemented using Feign, which is a lightweight cross-server call framework. The communication carrier is a Web request, and the transmitted data is generally in JSON format. FastJson is selected for JSON serialization.

[0086] In this implementation, preferably, the planned tasks use Quartz, which is an open source, lightweight, full-featured, enterprise-level scheduling framework that can help developers implement functions such as scheduled tasks, calendar-based tasks, and asynchronous tasks.

[0087] In this implementation, preferably, MySQL is used as the database. MySQL is an open source and free database management system that is secure and controllable. Redis is used as the cache service. Redis is mainly used in this system to cache and accelerate data, such as information related to task activity diagrams. RabbitMQ is used as the message queue, and ElasticSearch is used for full-text retrieval.

[0088] In this implementation, the logical structure of the database is displayed using an ER diagram to illustrate the relationships and dependencies between data elements, such as Figure 4 As shown, it is the system template ER diagram, which contains multiple entities. Because there are too many entities, only entities and relationships are reflected in this ER diagram, and attributes are omitted. In the database of this implementation method, users create projects, and create executions under projects. One project corresponds to one execution, so the project table and the execution table are in a one-to-one relationship; under the execution, you can select a template group according to the function, and select multiple templates under the template group, so the execution and the template group are in a one-to-one relationship, and the template group and the template are in a one-to-many relationship; multiple template parameters can be added to the template according to the needs, and multiple template parameters are bound to multiple tool parameters, so the template and template parameters are in a one-to-many relationship, and the template parameters and tool parameters are in a many-to-many relationship; one template can create multiple tasks, and the task selects the tool to be called, and one tool adds multiple tool parameters, so the template and the task are in a one-to-many relationship, the task and the tool are in a many-to-many relationship, and the tool and the tool parameter are in a one-to-many relationship.

[0089] Figure 5 This is a user ER diagram. This ER diagram contains eleven entities, which mainly represent the relationship between users, roles, departments, menus, and positions. In this system, one role corresponds to multiple users, and roles are associated with projects, departments, and menus. Therefore, there is a one-to-many relationship between the role information table and the user information table, and a many-to-many relationship between roles and project roles. A role can belong to multiple departments, and a department can have multiple roles, so there is a many-to-many relationship between roles and departments. Similarly, there is a many-to-many relationship between roles and menus, and a many-to-many relationship between the user information table and the position table.

[0090] The physical structure of the database is presented in specific tables to achieve specific data storage and management. The project table stores basic information about the project and implements project management. Based on the project table (Table 1), other auxiliary tables are created, such as the execution table (Table 2) and the task template group table (Table 3).

[0091] Table 1: Project table.

[0092]

[0093]

[0094] Table 2: Execution table

[0095]

[0096]

[0097] Table 3: Task template group table

[0098]

[0099] In this implementation, the process of task template group management includes: creating a new template group, creating a template under the current template group. Task templates can be plural tasks, singular tasks, and task subgroups. To create plural task templates, you need to add script content to the front script. If you create a template subgroup, you need to select other template groups and then add some basic information about the template. The template group represents a process, which is connected in series through the dependency relationship between templates. Therefore, when creating a template, if you need to connect it in series with other templates, you need to add template dependencies.

[0100] Add input resources: A template can call multiple tools. The variables that need to be input have been set when the tool is designed and created. Therefore, if a template wants to add a tool, it must add input resources for use when the tool is executed. There are two types of input resources. One is manual input. After creating a task according to the template, start the task and then select specific variables. The other is to select the input and output variables of other templates in the same template group and bind them directly.

[0101] Add tool: When adding a tool, select the tool you want to use, and the system will automatically display the input variable name of the tool. Then you can directly set the variables in the template input resource after the tool variable name;

[0102] Add output resources: Just like adding input resources, you can first define the variable name, and then set the variable corresponding to the variable name. The difference from input resources is that input resources can choose manual input and input and output of other templates, while output resources can choose manual input and tool output.

[0103] In this implementation, the system interfaces are also designed, including: login interface, project management interface, execution management interface, user management interface, task management interface, template management interface, template group management interface, requirement management interface, adapter interface, task log management interface, test management interface, template dependency management interface, task comment management interface, test step management interface, bug management interface, tool management interface and template resource query interface.

[0104] Among them, the external interfaces are the requirement management interface, adapter interface, test step management interface and bug management interface; the internal interfaces are the project management interface, execution management interface, user management interface, task management interface, template management interface, template group management interface, task log management interface, test management interface, template dependency management interface, task comment management interface, tool management interface and template resource query interface.

[0105] The login interface is designed as follows: when a user logs in to the system, the system will perform two parts of verification, one is verification code verification, and the other is user authority verification. Verification code verification process: the login page displays a random verification code, and the user enters the verification code. If the verification code is correct, the verification is passed. Otherwise, the verification code needs to be re-entered until the verification code is correct. The verification code is implemented by saving the verification code value on the server through the session. The verification code information is carried when the front end is submitted, and the server verifies and clears it.

[0106] The process of user authority verification: (1) The user enters the username and password to log in, and the background verifies the username and password. If the verification is successful, a token is returned to the front end. The token is generated by TokenService using the better-performing ThreadLocalRandom to generate a random UUID, and then the sessionId (i.e., UUID) is used as the key and the user login information loginUser is saved in redis. The token validity period is refreshed and a token (i.e., JwtToken) containing the sessionId is generated; (2) After the front end receives the token, it sends a request with the token to access the corresponding interface; (3) After the interface receives the request, it uses the token for identity authentication to determine whether the user has the authority to access the interface; (4) If the user has the authority, the interface will return the corresponding data to the front end; if not, the interface will return a status code of 401 or 403 to the front end, indicating that the user has no access.

[0107] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, the present invention may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A module calling method for a software automation pipeline system, characterized in that: The software automation pipeline system includes: a task manager, a StackStorm platform, a resource manager, a tool manager and an adapter. The calling method includes the following process: The task manager calls to create a task based on the template and sends the task creation instruction to the StackStorm platform. The StackStorm platform then feeds back the task creation completion instruction to the task manager. The task starts automatically, the task manager queries the tool manager for the tools used in the template, and the tool manager sends the queried tools to the task manager; The task manager pulls resources and stores them in the resource manager and tool manager. The tool manager sends the queried tools and parameters sent by the task manager to the adapter for adaptation. The adapter returns the execution result directly to the task manager, and the task manager stores the execution result in the resource manager; The task manager sends a task completion instruction to the StackStorm platform. After the StackStorm platform completes the specified action, it switches the task status and feeds back to the task manager; or, the task manager sends a task close instruction to the StackStorm platform. After the StackStorm platform completes the specified action, it switches the task status and feeds back to the task manager.

2. The module calling method of the software automation pipeline system according to claim 1, characterized in that: Task Manager includes: All tasks are considered as an AOV directed graph. Each node in the AOV directed graph is a task. The dependency between tasks is represented by edges. If task A has an edge pointing to task B, it means that task B depends on task A. If there are two edges pointing to B, (A, B) and (C, B), then A and C must be completed before B can be started. The dependency between tasks is defined as a task template group. The task template group consists of multiple task templates and the relationships between them. When creating an iteration of a project, the task template group is specified, and the AOV directed graph of the task is dynamically created based on the task template group. Tasks are created dynamically based on the task template group. Tasks will only be truly created when the conditions for task execution are met. Only tasks that are truly created have visualization functions.

3. The module calling method of the software automation pipeline system according to claim 2, characterized in that: According to the AOV directed graph in the task template group, analyze whether the templates in the task template group have dependencies, and then create a task based on the information in the task template. After the task is created, prepare resources for the task according to the definition in the task template. After the task manager calls the resource manager to prepare the resources, if it is an automatic task, call the tool manager to execute the tool according to the tool specified in the task. If it is a manual task, wait for the task to be started manually.

4. The module calling method of the software automation pipeline system according to any one of claims 1 to 3, characterized in that: The software automation pipeline system is a multi-layer AOV directed graph. The top layer is the relationship between the top-level activities and activities. The template group is used to describe the AOV directed graph of the activities. Through the visualization of task templates and tasks, the completion status, time, personnel information and input and output information of the tasks are visualized.

5. The module calling method of the software automation pipeline system according to any one of claims 1 to 3, characterized in that: The resource manager centrally manages input data, intermediate data, and output data. When a tool is called, the resource manager automatically places the resource in the specified directory based on the resource ID and target location, thereby automatically acquiring resources based on the resource ID. After generating the results, the tool submits the data to the resource manager.

6. The module calling method of the software automation pipeline system according to any one of claims 1 to 3, characterized in that: In the software automation pipeline system, the microservice deployment of the business is carried out, including: Microservices register with Nacos when they start. Multiple instances of the same microservice can be started, and Nacos performs load balancing according to the configured load balancing strategy. SpringCloud's Gateway is used to integrate microservices, provide a unified Web API for the front end, and implement permission verification for microservices.

7. The module calling method of the software automation pipeline system according to any one of claims 1 to 3, characterized in that: In the database, users create projects, and create executions under projects. One project corresponds to one execution. The project table and the execution table are in a one-to-one relationship. Under the execution, a template group is selected according to the function, and multiple templates are selected under the template group. The execution and the template group are in a one-to-one relationship, and the template group and the template are in a one-to-many relationship. Add multiple template parameters to the template as required, and bind multiple template parameters to multiple tool parameters. The relationship between templates and template parameters is one-to-many, and the relationship between template parameters and tool parameters is many-to-many. One template creates multiple tasks. A task selects the tool to be called. One tool adds multiple tool parameters. There is a one-to-many relationship between templates and tasks, a many-to-many relationship between tasks and tools, and a one-to-many relationship between tools and tool parameters.

8. A module calling system of a software automation pipeline system, characterized in that: Includes Task Manager, StackStorm Platform, Resource Manager, Tool Manager, and Adapters; The task manager calls to create a task based on the template and sends the task creation instruction to the StackStorm platform. The StackStorm platform then feeds back the task creation completion instruction to the task manager. The task starts automatically, the task manager queries the tool manager for the tools used in the template, and the tool manager sends the queried tools to the task manager; The task manager pulls resources and stores them in the resource manager and tool manager. The tool manager sends the queried tools and parameters sent by the task manager to the adapter for adaptation. The adapter returns the execution result directly to the task manager, and the task manager stores the execution result in the resource manager; The task manager sends a task completion instruction to the StackStorm platform. After the StackStorm platform completes the specified action, it switches the task status and feeds back to the task manager; or, the task manager sends a task close instruction to the StackStorm platform. After the StackStorm platform completes the specified action, it switches the task status and feeds back to the task manager.

9. The module calling system of the software automation pipeline system according to claim 8, characterized in that: Task Manager includes: All tasks are considered as an AOV directed graph. Each node in the AOV directed graph is a task. The dependency between tasks is represented by edges. If task A has an edge pointing to task B, it means that task B depends on task A. If there are two edges pointing to B, (A, B) and (C, B), then A and C must be completed before B can be started. The dependency between tasks is defined as a task template group. The task template group consists of multiple task templates and the relationships between them. When creating an iteration of a project, the task template group is specified, and the AOV directed graph of the task is dynamically created based on the task template group. Dynamically create tasks based on the task template group. Tasks will only be created when the task execution conditions are met. Only tasks that are actually created have visualization functions. According to the AOV directed graph in the task template group, analyze whether the templates in the task template group have dependencies, and then create a task based on the information in the task template. After the task is created, prepare resources for the task according to the definition in the task template. After the task manager calls the resource manager to prepare the resources, if it is an automatic task, call the tool manager to execute the tool according to the tool specified in the task. If it is a manual task, wait for the task to be started manually.

10. The module calling system of the software automation pipeline system according to claim 8 or 9, characterized in that: In the database, users create projects, and create executions under projects. One project corresponds to one execution. The project table and the execution table are in a one-to-one relationship. Under the execution, a template group is selected according to the function, and multiple templates are selected under the template group. The execution and the template group are in a one-to-one relationship, and the template group and the template are in a one-to-many relationship. Add multiple template parameters to the template as required, and bind multiple template parameters to multiple tool parameters. The relationship between templates and template parameters is one-to-many, and the relationship between template parameters and tool parameters is many-to-many. One template creates multiple tasks. A task selects the tool to be called. One tool adds multiple tool parameters. There is a one-to-many relationship between templates and tasks, a many-to-many relationship between tasks and tools, and a one-to-many relationship between tools and tool parameters.

Images