Windows multi-project CI / CD automatic centralized management and control system and method based on local service

Abstract

The embodiment of the invention provides a Windows multi-project CI / CD automatic centralized management and control system and method based on local service, the system comprises a Web front end and at least two Windows servers, each server runs a local automatic service program, and no central management node exists. And the Web front end is used for a user to select a target server and a project and send an operation instruction, and directly communicates with a local automatic service program of each server. A local automation service program automatically discovers and registers local multiple projects, maintains metadata, and locally executes automation operation based on the metadata. According to the system, a single-point fault is avoided through a decentralized architecture, and the usability and the reliability are improved. According to the scheme, efficient, isolated and safe automatic operation and maintenance of multiple projects in the Windows native environment are achieved, deployment is simple, and execution efficiency is high.

Description

Technical Field

[0001] This invention relates to the fields of software engineering and automated operation and maintenance technology, and in particular to a Windows multi-project CI / CD automated centralized management and control system and method based on local services. Background Technology

[0002] The mainstream continuous integration / continuous deployment (CI / CD) toolchains in the current software engineering and automated operations and maintenance fields, such as Jenkins, GitLab continuous integration, and GitHub Actions, are primarily designed for Linux and Unix-like operating systems. When running on the Windows platform, these tools exhibit significant compatibility issues. Although some tools claim to support Windows environments, their underlying implementations still heavily rely on Bash scripts, secure shell protocol remote execution, or portable operating system interface-compatible environments, making them difficult to implement in real-world enterprise production environments.

[0003] The common practices in existing technologies are reflected in the following aspects: First, regarding automation capabilities, most continuous integration and continuous deployment tools use Linux primitives by default, such as shell scripts and system daemon service control mechanisms. This approach prevents direct manipulation of Windows-specific system resources, such as Windows services, the registry, newer file system permissions, and event logs. Even attempts to wrap these tools with PowerShell often fail due to inconsistent execution contexts, complex permission models, or character encoding issues.

[0004] Secondly, in terms of script logic construction, it typically relies on Windows' native batch scripts. These script files lack modern structured programming capabilities, do not support functions, exception handling, and modular design, and are difficult to parse JSON data, initiate Hypertext Transfer Protocol requests, or connect to databases. This makes building complex and robust automated pipelines extremely difficult, severely limiting the reliability and scalability of the process.

[0005] Furthermore, in terms of remote management mechanisms, traditional systems generally rely on the Secure Shell protocol for remote command distribution and control. However, the Windows operating system does not natively support this protocol. Although it can be installed through open-source implementations, it requires additional configuration, and its permission model is inconsistent with Linux systems. In addition, Windows' native PowerShell remote processing, Windows Management Specification, and other remote mechanisms are often restricted by enterprise group policies, firewall settings, or network isolation, exhibiting poor stability and high deployment and maintenance costs in intranet environments.

[0006] Furthermore, in terms of system architecture design, existing solutions typically rely on a central management node, such as the Jenkins master node or the Ansible controller, to issue commands to multiple target machines. This centralized architecture not only introduces the risk of single point of failure but also requires maintaining complex network connectivity, cross-node authentication systems, and state synchronization mechanisms, making it difficult to adapt to intranet environments with strict network isolation or limited resources.

[0007] Finally, in terms of management granularity, when dealing with scenarios where multiple independent business projects are deployed on a single server, such as the coexistence of multiple test projects common in manufacturing execution systems or financial back-office services, traditional scripts or general-purpose tools cannot provide unified status display, configuration modification, or one-click deployment functions at the project level. Operations or testing personnel must manually distinguish the paths, service names, ports, and other information of different projects, which is highly prone to cross-project errors and lacks a centralized and unified monitoring interface.

[0008] In summary, the current technological landscape lacks a lightweight, decentralized, fully Windows-native-capabilities-based, single-machine, multi-project isolated management solution for continuous integration and continuous deployment automation that eliminates the need for a central coordination node. This results in a large number of enterprises still heavily relying on manual maintenance for their Windows servers, leading to inefficiencies, high rates of human error, and long software testing and verification cycles. Summary of the Invention

[0009] In view of this, it is necessary to provide a Windows multi-project CI / CD automated centralized management and control system and method based on local services to solve the above-mentioned problems of the prior art.

[0010] To address the aforementioned problems, in a first aspect, embodiments of the present invention provide a Windows multi-project CI / CD automated centralized management and control system based on local services, comprising: The web front-end allows users to select a target Windows server and a target project on the target Windows server, and sends operation instructions for the target project to the target Windows server. At least two Windows servers, each running a local automated service program; The local automation service program is used to automatically discover and register multiple projects on the Windows server and maintain metadata for each project; and to receive operation instructions sent by the Web frontend and, based on the metadata of the target project, execute automated operations related to the target project locally on the Windows server. The web front-end communicates directly with the local automation service program on each of the Windows servers, and the system does not contain a central management node.

[0011] Furthermore, the local automation service program is an independent executable file in EXE format, running on the Windows server as a Windows service or a resident process, and providing a RESTful API for expressing state transfer to the outside world. The local automation service program automatically discovers and registers multiple projects on the Windows server by scanning preset directories or reading configuration files, and maintains the metadata of each project; wherein, the metadata includes project name, main process name, configuration path, service name and database connection string; The local automation service program performs automated operations on the local Windows server by calling system resources based on the metadata of the target project, without relying on remote calls or external proxy services.

[0012] Furthermore, the operation flow of the web front-end adopts a two-level dynamic routing mechanism: The first level responds to the user's selection of the target Windows server, retrieves and displays the project list from the target Windows server's local automation service program; The second level responds to the user's selection of a target project from the project list, and all subsequent application programming interface (API) requests sent by the web frontend to the target Windows server automatically carry the identifier of the target project; The web front-end is also used to display the running status panel of the selected target project, which includes service status, listening port, last deployment time, current version number, CPU usage and memory usage.

[0013] Furthermore, the local automated service program includes: The security control module is used to control access to received API requests by verifying access tokens, checking IP address whitelists, and enabling HTTPS; where the token is an encrypted string used for authentication.

[0014] Furthermore, the local automated service program also includes: The log auditing and statistics module is used to record operation logs related to the target project and store the operation logs in the local file system; the operation logs include timestamps, operator IP, target server, target project, operation type, input parameters, and execution results.

[0015] Furthermore, the local automated service program also includes: The RESTful API layer is used to receive requests from the web frontend and return responses; The project metadata manager is used to establish and maintain the mapping relationship between project identifiers and at least one of the following resources: process name, service name, configuration file path, and database connection string. A configuration file parsing engine is used to perform structured parsing and field-level modification of the configuration files of the target project.

[0016] Furthermore, the local automated service program also includes: A database client is used to connect to the database bound to the project and perform the following operations: query the schema version of the database corresponding to the target project, execute the database migration script in a predefined order, execute data definition language (DDL) or data manipulation language (DML) operations in a database transaction, and perform rollback when the operation fails. The process manager is used to manage the main process of the target project according to the project isolation principle. It supports identification and matching by process name, startup parameters or associated Windows services, and has the function of automatic process crash detection and restart.

[0017] Furthermore, the local automated service program also includes: The Windows API adapter is used to operate on Windows native resources associated with the target project by calling the Windows native API or system command-line tools. The operations include starting and stopping Windows services, reading and writing registry keys, and querying event logs. The notification push module is used to push structured information, including server address, project name, operation type, and operation result, to a specified external communication platform via a Webhook after the automated operation task is completed; wherein, the Webhook is an event-triggered notification push interface.

[0018] Secondly, embodiments of the present invention provide a Windows multi-project CI / CD automated centralized management and control method based on local services, including: In response to the user's selection of a target Windows server and a target project on the target Windows server in the web front end, an operation command for the target project is sent to the target Windows server; The operation instructions sent by the web frontend are received by a local automation service program deployed on at least two Windows servers; The local automation service program performs automated operations related to the target project on the local Windows server based on the metadata of the target project it maintains. The web front-end communicates directly with the local automation service program on each of the Windows servers, and the system does not contain a central management node.

[0019] Furthermore, the web front-end implements the issuance of operation commands through a two-level dynamic routing mechanism, specifically including: The first level responds to the user's selection of the target Windows server, and retrieves and displays the project list from the local automation service program of the target Windows server; The second level responds to the user's selection of a target project from the project list; Subsequently, all application programming interface (API) requests sent by the web frontend to the target Windows server automatically carry the identifier of the target project.

[0020] The Windows multi-project CI / CD automated centralized management and control system and method based on local services provided by this invention have the following advantages compared with the prior art: (1) This invention adopts a decentralized architecture, deploying a local automated service program independently on each target Windows server. The system does not contain a central management node. The service program runs in the form of an independent executable file (EXE) and communicates directly with the front end through a RESTful API, thereby avoiding the single point of failure risk of traditional centralized solutions and improving the overall availability and reliability of the system. Even if some servers are offline, it will not affect the normal operation of other nodes.

[0021] (2) The local automated service program of the present invention is a single executable file, which does not require the installation of external components such as Python runtime, thus achieving extremely simple deployment and zero external dependencies. All automated operations are completed by directly calling system resources on the target server, eliminating cross-node communication overhead, enabling front-end commands to directly connect to the target service and obtain the lowest latency response, resulting in high execution efficiency, and is particularly suitable for network isolation or resource-constrained intranet environments.

[0022] (3) The local automated service program integrates advanced modules such as automatic project discovery, metadata management, configuration file parsing engine, database client, and process manager. It can modify configuration file fields at the specified project level, perform transactional database migration, and achieve process-level self-healing management, thus providing more accurate, secure, and rollback-capable intelligent operation and maintenance capabilities than traditional batch processing or PowerShell scripts. It is a powerful program.

[0023] (4) The system of the present invention achieves clear isolation and centralized visual management of multiple projects on a single machine through project metadata binding and a two-level dynamic routing mechanism. The front end can uniformly display the real-time running status of each project on multiple servers, and testers can perform self-service deployment, verification and rollback operations without waiting for operation and maintenance intervention, which improves operation security, accelerates the test feedback loop, and reduces the learning cost for users.

[0024] (5) The local automated service program supports configuring access tokens, IP whitelists, and HTTPS encrypted communication. All operations are recorded in detailed audit logs and can be traced back to specific projects. The service only listens on the internal network and does not need to open high-risk remote ports such as RDP or SSH. Thus, while providing centralized management capabilities, it achieves controllable secure access and operational compliance, effectively preventing unauthorized access. Attached Figure Description

[0025] Figure 1 Architecture diagram of the Windows multi-project CI / CD automated centralized management and control system based on local services provided by the present invention; Figure 2 This is a schematic diagram of the two-level dynamic routing mechanism for the Web front-end provided by the present invention; Figure 3 This is a diagram of the internal functional modules of the local automation service program provided by the present invention; Figure 4 A flowchart of the Windows multi-project CI / CD automated centralized management and control method based on local services provided by the present invention. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0027] The naming or numbering of steps in the embodiments of the present invention does not mean that the steps in the method flow must be executed in the time / logical order indicated by the naming or numbering. The execution order of the named or numbered process steps can be changed according to the technical purpose to be achieved, as long as the same or similar technical effect can be achieved.

[0028] Figure 1 This invention provides an architecture diagram of a Windows multi-project CI / CD automated centralized management and control system based on local services; see reference. Figure 1 The Windows multi-project CI (Continuous Integration) / CD (Continuous Deployment) automated centralized management and control system based on local services provided by this invention includes: The web front-end allows users to select a target Windows server and a target project on the target Windows server, and sends operation instructions for the target project to the target Windows server. At least two Windows servers, each running a local automated service program; The local automation service program is used to automatically discover and register multiple projects on the Windows server and maintain metadata for each project; and to receive operation instructions sent by the Web frontend and, based on the metadata of the target project, execute automated operations related to the target project locally on the Windows server. The web front-end communicates directly with the local automation service program on each of the Windows servers, and the system does not contain a central management node.

[0029] It should be noted that current mainstream CI / CD toolchains are designed around Linux-like operating systems and rely on Bash scripts and remote protocols on Windows platforms. This compatibility issue makes it difficult to implement in enterprise environments. Existing solutions mostly adopt a centralized architecture, which is prone to single points of failure. At the same time, they cannot manage multiple projects on a single server at the project level, making operations susceptible to interference.

[0030] Therefore, the present invention aims to provide a Windows multi-project CI / CD automated centralized management and control system based on local services, realizing decentralized, automated process management and control in the native Windows environment.

[0031] Reference Figure 1The web frontend provides users with a centralized interface. Three example servers are ServerA, ServerB, and ServerC. Each server runs an independent "local automation service" process. Each server's local automation service manages multiple independent projects. For example, ServerA manages Project1 and Project2; ServerB also manages Project1 and Project2, demonstrating that different servers can deploy the same projects to form a cluster; ServerC manages Project3 and Project4, showcasing the flexibility of project deployment. The web frontend communicates directly with the local automation service on each server through specific network addresses, such as different ports on 192.168.1.10. The diagram clearly marks "no central management node," intuitively illustrating the core characteristic of decentralization. There are no connecting lines between the servers and their local services, indicating that they are independent and do not communicate with each other.

[0032] Specifically, the web frontend serves as the interaction entry point for users to perform operations. Users select a target Windows server through the web frontend, then choose the target project from the project list corresponding to that server. The web frontend then sends operation instructions for that target project to the local automation service program on the target Windows server.

[0033] On each Windows server requiring automated management, deploy a separate local automation service program. Once started, this program runs continuously as a background service or a persistent process. Each local automation service program automatically executes a project discovery process upon startup. This process can be achieved by scanning specific directories on the server or reading a predefined project configuration file. The service program registers each discovered independent business unit as a "project" and creates and maintains a set of metadata for each project. This metadata uniquely identifies the project and describes its key resources, typically including the project name, main execution process name, configuration file storage path, associated Windows service name, and database connection string.

[0034] The local automation service program on the target Windows server receives operation instructions from the web frontend through its network interface. The service program parses the instructions and, based on the identifier of the target project associated with the instructions, retrieves the specific resource information of the project from the metadata maintained locally. Subsequently, the service program, entirely on its local Windows server, invokes operating system privileges, command-line tools, or scripts to execute the specific automation tasks related to that project.

[0035] Throughout the process, the web frontend establishes direct peer-to-peer network communication with the local automation service program on each Windows server. All command issuance, status inquiries, and result returns are completed within this direct channel. There is no central management server node in the system for centralized scheduling, coordination, or relaying tasks.

[0036] This invention achieves a fundamental technological improvement by deploying independent local automated service programs on each Windows server and adopting a decentralized architecture with direct front-end connections. The system completely eliminates dependence on a central management node, removes single points of failure, and significantly improves overall availability. Deployment is extremely simple, requiring only the distribution of a single executable file without complex external dependencies. All operations are executed locally on the target server, resulting in rapid response and no network overhead. Simultaneously, through automatic project discovery and metadata management, the system achieves clear identification and strict isolation of single-machine, multi-project scenarios, effectively preventing accidental operations and ensuring security. This "direct front-end connection + local execution + project isolation" technical solution provides both a centralized management experience across multiple machines and projects and retains the technical advantages of completely independent operation of each server and strict isolation of project resources. It improves the automation efficiency, reliability, and security of CI continuous integration and CD continuous deployment in the Windows environment.

[0037] In some embodiments of this application, the local automation service program is an independent executable file in EXE format, which runs on the Windows server as a Windows service or a resident process, and provides a RESTful API (Representative State Transmission Application Programming Interface) to the outside world. The local automation service program automatically discovers and registers multiple projects on the Windows server by scanning preset directories or reading configuration files, and maintains the metadata of each project; wherein, the metadata includes project name, main process name, configuration path, service name and database connection string; The local automation service program performs automated operations on the local Windows server by calling system resources based on the metadata of the target project, without relying on remote calls or external proxy services.

[0038] Specifically, the local automation service program is packaged as a standalone executable (EXE) file and deployed to each target Windows server. This program starts and runs continuously as a Windows service or a persistent process, while listening on the local network port and providing a standardized RESTful API for communication with the web frontend for commands and results.

[0039] Once the local automated service program starts, it immediately executes the automatic project discovery process. This process is implemented in two ways: first, by actively scanning specific directories pre-defined in the server's file system, such as the Projects folder under the C drive; and second, by reading a specific configuration file pre-installed on the server, such as a file named projects.yaml. Through at least one of these methods, the program can identify all business projects on the local machine that need to be managed and register them one by one into its internal management list.

[0040] For each successfully discovered and registered project, the local automation service program creates and maintains a unique set of metadata. This metadata serves as a blueprint for the program to understand and operate the project, and its key fields typically include the project name, the name of the project's main process, the path to its configuration file, the name of the associated Windows service, and the connection string required to connect to its dedicated database. This information is persistently stored, forming a mapping between project identifiers and specific system resources.

[0041] When the web frontend sends an operation command for a specific target project to the service program via a RESTful API, the service program receives and parses the command. Then, based on the target project identifier specified in the command, it retrieves the detailed resource information corresponding to that project from the metadata system maintained locally. All subsequent automated operations are executed directly on the local machine by calling Windows operating system resources, command-line tools, or scripts, based on this metadata. The entire execution chain is completed entirely within a single Windows server, without involving any form of cross-machine remote procedure calls, and without relying on any external proxy services or middleware for relay or coordination.

[0042] In this embodiment, the local automated service program runs as an independent executable (EXE) file and communicates directly with the front-end via a RESTful API. This avoids the single point of failure risk of traditional centralized solutions, improving the overall availability and reliability of the system. Even if some servers go offline, it does not affect the normal operation of other nodes. The program automatically discovers and manages multiple projects by scanning or reading configurations, and uses maintained metadata to achieve precise location and isolation of operations, ensuring the security and specificity of operations. All instructions are executed directly on the receiving server with high privileges, achieving low latency and high reliability, as well as deep and lossless access to native Windows resources. This provides an efficient, stable, and secure underlying support solution for automated operation and maintenance in complex multi-project scenarios under Windows.

[0043] In some embodiments of this application, the operation flow of the Web front-end adopts a two-level dynamic routing mechanism: The first level responds to the user's selection of the target Windows server, retrieves and displays the project list from the target Windows server's local automation service program; The second level responds to the user's selection of a target project from the project list, and all subsequent application programming interface (API) requests sent by the web frontend to the target Windows server automatically carry the identifier of the target project; The web front-end is also used to display the running status panel of the selected target project, which includes service status, listening port, last deployment time, current version number, CPU usage and memory usage.

[0044] Traditional operation and maintenance tools often suffer from cluttered interfaces and are prone to misoperation when managing complex scenarios involving multiple servers, each with multiple projects deployed on them. To address this issue, this invention employs a two-level dynamic routing mechanism on the web front-end to achieve precise server and project selection, resolving the problems of chaotic multi-project management and accidental operation.

[0045] Specifically, operations and testing personnel access the system through a unified web front-end interface. This front-end has a built-in configurable list of Windows servers, which maintains connection information for each managed server, including its Internet Protocol address (IP address), port number, alias, and other details.

[0046] When users interact with the system, a strict two-level dynamic routing process must be followed. The first level involves user selection: from a list of servers provided on the front-end interface, the user selects a target Windows server, such as the server with the address 192.168.1.10, via a drop-down menu. Upon receiving this selection instruction, the web front-end immediately sends a request to the local automation service program corresponding to the selected server to retrieve a list of all registered projects on that server. This list may include, for example, the MES core system, warehouse management system adapters, and reporting engines. This list is then dynamically loaded and displayed to the user.

[0047] The second level of selection then occurs, where the user selects a target project from the previously retrieved project list, such as the MES core system. Once this selection is complete, the web frontend enters "project context mode." In this mode, the frontend's internal logic records the currently selected target server address and target project identifier. Subsequently, any API request triggered by the user on the interface—whether to view status, modify configuration, or execute deployment—will automatically include the target project identifier in the request and send the request directly to the local automated service program corresponding to the previously selected target server address.

[0048] In addition, after the user selects a target project, the web front-end will display a real-time running status panel for that project in a fixed area of ​​the interface. This panel continuously queries data from the target server's local services, dynamically updating and displaying several key operational metrics. These metrics typically include the status of the service corresponding to the project (running, stopped, or abnormal), the network port number it is listening on, the timestamp of the most recent successful deployment, the currently running software version number, and visual information such as CPU and memory resource usage.

[0049] Figure 2 This is a schematic diagram of the two-level dynamic routing mechanism for the Web front-end provided by the present invention. Figure 2 This demonstrates the complete user flow from selecting a server to initiating a request for a specific project. As shown in the figure, the user first selects a target server (e.g., ServerA, address 192.168.1.10) in the first-level operation. The web frontend then requests and loads a list of all projects managed by the server's local automation service. Next, in the second-level operation, the user selects a specific target project from this list (e.g., Project1:MES-Core). After this selection, the web frontend enters "project context mode." From then on, all API requests sent to this server will automatically embed the target project's identifier in their Uniform Resource Locator (URL), in the format http: / / 192.168.1.10:8080 / api / project / MES-Core / ... This mechanism ensures precise routing and strict isolation of operations, eliminating the need for users to manually specify project information in each request, thus significantly improving the accuracy, security, and convenience of the operation.

[0050] The system of this invention achieves clear isolation and centralized visual management of multiple projects on a single machine through project metadata binding and a two-level dynamic routing mechanism. The front end can uniformly display the real-time running status of each project on multiple servers, enabling testers to perform self-service deployment, verification, and rollback operations without waiting for maintenance intervention. This improves operational security, accelerates the test feedback loop, and reduces the learning cost for users.

[0051] Figure 3 This is a diagram of the internal functional modules of the local automation service program provided by the present invention, with reference to... Figure 3 In some embodiments of this application, the local automated service program includes: The security control module is used to control access to received API requests by verifying access tokens, checking IP address whitelists, and enabling HTTPS; where the token is an encrypted string used for authentication.

[0052] Specifically, the local automation service program includes a security control module, which is activated when the service program starts. This module performs pre-security checks on all incoming application programming interface (API) requests and provides a variety of configurable security mechanisms. System administrators can enable one or more combinations of these mechanisms according to their actual security needs.

[0053] The first security mechanism is authentication based on access tokens. An access token is an encrypted string generated by the system and distributed to authorized clients. It serves as authentication credentials, and clients must provide this token when making requests. Administrators can pre-set one or more valid tokens in the configuration file of the local automated service program. When the web frontend or other clients make API requests to this service program, they must include a valid token in the request header or parameters. The security control module extracts the token from the request and compares it with locally stored valid tokens. Only when the token is valid and matches will the request be allowed to proceed to subsequent business processing logic.

[0054] The second security mechanism is access control based on IP address whitelists. An IP address whitelist is a pre-configured list of authorized Internet Protocol (IP) addresses; only access requests originating from IP addresses on this list are accepted. Administrators can pre-configure a list of allowed IP addresses. When the security control module receives an API request, it resolves the source IP address of the requesting client and checks if that address is in the whitelist. The request is only accepted and processed if the source IP address is explicitly authorized.

[0055] The third security mechanism is to enable the HTTPS (Hypertext Transfer Protocol) to encrypt the communication link. Administrators can configure the local automated service program to load a specific digital certificate, which can be built into the program or retrieved from the Windows system's certificate store. With HTTPS enabled, all network communication between the service program and the web frontend will be encrypted using the TLS protocol, effectively preventing data from being eavesdropped on or tampered with during transmission.

[0056] Furthermore, as the foundation of security auditing, regardless of whether the API request ultimately passes security verification, the local automated service program ensures that each log entry contains clear project context information, such as the target server address and the target project identifier, when recording operation logs, thereby enabling accurate traceability of all operational behaviors.

[0057] In this embodiment, the local automated service program supports configuring access tokens, IP whitelists, and HTTPS encrypted communication. All operations are logged in detail and traceable to specific projects. The service only listens on the internal network and does not require opening high-risk remote ports such as RDP or SSH. This provides centralized management capabilities while achieving controllable secure access and operational compliance, effectively preventing unauthorized access.

[0058] In some embodiments of this application, reference is made to Figure 3 The local automation service program also includes: The log auditing and statistics module is used to record operation logs related to the target project and store the operation logs in the local file system; the operation logs include timestamps, operator IP, target server, target project, operation type, input parameters, and execution results.

[0059] Specifically, the local automation service program includes a log auditing and statistics module. Whenever the local automation service program receives an application programming interface (API) request from the web frontend and begins to execute an automated operation for the target project, the log auditing and statistics module simultaneously starts the logging process.

[0060] The log auditing and statistics module assembles all key information related to this operation into a complete log record according to a fixed format. This recorded information ensures comprehensive traceability of the entire operation, including at least: the precise timestamp of the operation, the IP address of the user client initiating the operation, the identifier of the Windows server targeted by the operation, the name of the target project, the specific type of operation (e.g., deployment or restart), the parameters input during the operation, and whether the operation was successful or failed. Any detailed error information generated during the operation execution is also captured and recorded.

[0061] All generated log entries are appended to a pre-defined log file on the local file system of the Windows server where the local automation service program resides. Each node's logs are stored independently, achieving distributed retention of operation records.

[0062] Furthermore, after the automated operation task is completed, the log auditing and statistics module will trigger a notification push process. The log auditing and statistics module will call pre-configured Webhook addresses. These Webhook addresses typically correspond to group robots on collaboration platforms such as DingTalk and WeChat Work. The Webhook is an event-triggered notification push interface used in this system to notify external instant messaging platforms of the operation results.

[0063] The log auditing and statistics module encapsulates the core results of this operation according to a predefined structured message template, generating a structured notification message, such as: "The engineering MES core system on server 192.168.1.10 has been successfully upgraded to version 2.3.1, the service has been restarted, and port 9090 is listening normally." Subsequently, this structured notification message is proactively pushed to the specified Webhook address via an HTTP request, thus delivering it to relevant operations or testing personnel groups in real time.

[0064] This embodiment integrates log auditing and notification modules to build complete observability and real-time response capabilities for the system. Distributed logging ensures that every operation has a detailed, tamper-proof, local archive, covering all elements of the operation, providing a reliable data foundation for security auditing, fault tracing, and accountability.

[0065] In some embodiments of this application, reference is made to Figure 3 The local automation service program also includes: The RESTful API layer is used to receive requests from the web frontend and return responses; The project metadata manager is used to establish and maintain the mapping relationship between project identifiers and at least one of the following resources: process name, service name, configuration file path, and database connection string. A configuration file parsing engine is used to perform structured parsing and field-level modification of the configuration files of the target project.

[0066] The RESTful API layer is a network interface layer implemented using the RESTful architectural style of the Representational State Transfer Application Programming Interface. It is responsible for receiving and parsing external requests in a standardized manner and returning processing results. The project metadata manager is the core module responsible for collecting, storing, and managing data describing the attributes of each project and their correspondence with underlying system resources. The configuration file parsing engine is a dedicated processing module capable of reading, parsing, and modifying various structured configuration file formats, and accurately locating specific configuration items for modification.

[0067] Specifically, the RESTful API layer acts as the sole network communication portal for the local automation service program, continuously listening on the configured network port. When the web frontend initiates a request, such as a deployment command for a specific project, the RESTful API layer is responsible for receiving the HTTP or HTTPS request, performing standard parsing, validation, and routing. It converts the parameters in the request into a format recognizable by its internal processing logic, and after the internal business logic is executed, it encapsulates the execution result into a standard HTTP response and returns it to the web frontend.

[0068] The project metadata manager begins operating during the initialization phase of the local automation service program. It automatically discovers all projects that need to be managed on the local machine by scanning the pre-defined project root directories on the server or reading a specific project manifest configuration file. For each discovered project, the manager extracts or matches its key characteristics using rules and creates a metadata record. The core of this record is establishing a mapping between the project's unique identifier and various resources within the actual system. These resources include at least one or more of the following: the project's main process name, the associated Windows service name, the storage path of the main configuration file, and the database connection string.

[0069] When it's necessary to modify the configuration of a target project, such as updating a database connection address, the engine kicks in. The configuration file parsing engine first locates the specific configuration file for that project based on the path provided by the project's metadata manager. The engine has built-in parsing capabilities for various common configuration file formats, including JavaScript Object Notation (JSON), Extensible Markup Language (XML), INI, and Properties. It can understand the structured syntax of the configuration file, thus safely reading its content and precisely locating the specific field that needs modification, such as a field named `database.connection`, and then replacing its value with the new value. The entire process does not rely on error-prone full-text searches or regular expression matching, ensuring the accuracy of the modifications and the integrity of the configuration file format.

[0070] This embodiment upgrades the local automation service program from a passive command executor to a proactive engineering awareness and intelligent operation engine by internally integrating a RESTful API layer, a project metadata manager, and a configuration file parsing engine. The standardized API interface enables reliable communication with the front end; the metadata manager constructs a digital blueprint of the project, achieving a precise mapping from physical resources to logical concepts; and the configuration file parsing engine provides semantic-based precise manipulation capabilities.

[0071] In some embodiments of this application, reference is made to Figure 3 The local automation service program also includes: A database client is used to connect to the database bound to the project and perform the following operations: query the schema version of the database corresponding to the target project; execute database migration scripts in a predefined order; execute Data Definition Language (DDL) or Data Manipulation Language (DML) operations within a database transaction and perform rollbacks if operations fail. The database schema version refers to a specific state identifier describing the database structure, including the definitions of objects such as tables, views, and indexes; it is typically managed using version numbers to support incremental changes. Database migration scripts are a sequence of Structured Query Language (SQL) scripts used to upgrade or roll back the database schema from one version to another. Data Definition Language (DDL) is used to define and modify the database structure, such as creating tables; Data Manipulation Language (DML) is used to manipulate data in the database, such as inserting and updating records.

[0072] The process manager is used to manage the main process of a target project according to the project isolation principle. It supports identification and matching by process name, startup parameters, or associated Windows services, and has automatic process crash detection and restart functions. The project isolation principle means that in management operations, actions such as starting, stopping, and monitoring the main process of a certain project are strictly limited to the scope of that project and will not affect the processes of other projects on the same server.

[0073] Specifically, when the automation task involves a database bound to the target project, the database client is invoked. It first establishes a connection with a database management system such as Microsoft SQL Server or MySQL based on the database connection string maintained in the project metadata. During database version upgrades, the database client performs a series of rigorous operations: first, it queries the current database schema version number; then, following a predefined upgrade order, it retrieves and executes the corresponding incremental migration script files sequentially, such as the script from version 1 to version 2; all these Data Definition Language (DDL) or Data Manipulation Language (DML) operations are executed within a single database transaction to ensure atomicity—that is, the entire migration process either succeeds completely or automatically rolls back to the state before execution if any step fails, thus absolutely guaranteeing data consistency. Execution details are returned as a log.

[0074] The process manager is responsible for the full lifecycle management of the main process of the target project, adhering to the principle of project isolation. When a target project needs to be started or stopped, the process manager accurately identifies the unique main process corresponding to that project in the operating system based on the process name recorded in the project metadata, specific startup parameters, or associated Windows service names. It can monitor the running status of the process and execute start or stop commands. The process manager has automatic process crash detection capabilities. Through periodic heartbeat checks or abnormal exit monitoring, once it detects that the main process of the target project has unexpectedly terminated, it can immediately and automatically restart the process, thereby achieving project-level application self-healing and ensuring continuous service availability.

[0075] This embodiment enhances the operational depth and reliability of local automated service programs at both the data persistence and application runtime layers by integrating a transactional database client and an intelligent process manager. The database client, through versioning and transactional mechanisms, ensures the security, controllability, and traceability of database change operations, completely avoiding the risk of data inconsistency due to upgrade failures. The process manager, through precise process identification and isolation management, combined with crash detection and automatic restart capabilities, achieves autonomous high availability assurance for application processes.

[0076] In some embodiments of this application, reference is made to Figure 3 The local automation service program also includes: The Windows API adapter is used to manipulate Windows native resources associated with the target project by calling Windows native APIs or system command-line tools. These operations include starting and stopping Windows services, reading and writing registry entries, and querying event logs. The Windows API adapter is a series of predefined function interfaces provided by the Microsoft Windows operating system for applications to call to access underlying system functions and resources.

[0077] The notification push module is used to push structured information, including server address, project name, operation type and operation result, to a designated external communication platform via a Webhook after the automated operation task is completed.

[0078] Specifically, when an automated task requires management of Windows native resources associated with the target project, the Windows API adapter is activated. Acting as a bridge between the local automation service and the Windows operating system, it performs a series of in-depth operations by directly calling Windows native application programming interface (API) functions or executing encapsulated system command-line tools. These operations include: starting or stopping Windows services bound to the project based on the service name specified in the project metadata; accessing a dedicated registry key path reserved for the project to read or write configuration values ​​to dynamically adjust application behavior; and querying specific event log records generated by the target project process in the Windows event log for fault diagnosis or behavior auditing. All operations are executed locally on the target server with high privileges, without any remote protocol intervention.

[0079] After a local automation service completes an automated task, regardless of success or failure, the notification push module is triggered. The core responsibility of the notification push module is to proactively notify users of the operation result. First, the module extracts key information from the task execution context, including the target server address, the target project name, the type of operation performed, and the final result. Then, it encapsulates this information according to a predefined structured message template, organizing it into a concise and clear notification message. Finally, the notification push module sends a Hypertext Transfer Protocol (HTTP) POST request to a pre-configured external Uniform Resource Locator (URL), essentially invoking a Webhook, to push this structured notification message. This URL typically corresponds to an internal instant messaging platform used by the enterprise, enabling real-time delivery of the message to relevant teams or personnel.

[0080] Figure 4 The flowchart of the Windows multi-project CI / CD automated centralized management and control method based on local services provided by the present invention is shown below. Figure 4 The method includes: In response to the user's selection of a target Windows server and a target project on the target Windows server in the web front end, an operation command for the target project is sent to the target Windows server; The operation instructions sent by the web frontend are received by a local automation service program deployed on at least two Windows servers; The local automation service program performs automated operations related to the target project on the local Windows server based on the metadata of the target project it maintains. The web front-end communicates directly with the local automation service program on each of the Windows servers, and the system does not contain a central management node.

[0081] Specifically, users interact through a unified web front-end interface. The front-end responds to the user's successive selections of the target Windows server and the target project on that server, and then generates and sends an operation command for that specific target project directly to the target Windows server.

[0082] Next, the local automation service deployed on the target Windows server receives the operation instructions from the front end through its exposed RESTful API (Representative State Delivery Application Programming Interface). This local automation service is a smart agent that exists as a standalone executable (EXE) file and runs locally as a background service.

[0083] Then, the local automation service program parses and executes the instruction based on its internally maintained project metadata. The metadata establishes a mapping between the target project identifier and specific system resources. All automated operations, including invoking system commands, modifying configuration files, or managing processes, are performed locally on the target Windows server, without relying on any remote procedure calls or external agents.

[0084] The execution of this method relies on a decentralized communication architecture. The web frontend establishes a direct peer-to-peer network connection with the local automation service program on each Windows server in the network. Both the instruction stream and the status information stream are transmitted in this direct connection channel, and the entire execution process of the method does not require scheduling or relay by any central management node.

[0085] Furthermore, the web front-end implements the issuance of operation commands through a two-level dynamic routing mechanism, specifically including: The first level responds to the user's selection of the target Windows server, and retrieves and displays the project list from the local automation service program of the target Windows server; The second level responds to the user's selection of a target project from the project list; Subsequently, all application programming interface (API) requests sent by the web frontend to the target Windows server automatically carry the identifier of the target project.

[0086] The Windows multi-project CI / CD automated centralized management and control method based on local services provided by this invention is executed by the Windows multi-project CI / CD automated centralized management and control system based on local services provided in the foregoing embodiments. The Windows multi-project CI / CD automated centralized management and control system based on local services has been described in detail in the foregoing embodiments, and the Windows multi-project CI / CD automated centralized management and control method based on local services will not be described in detail in this embodiment.

[0087] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the appended claims.

[0088] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A Windows multi-project CI / CD automated centralized management and control system based on local services, characterized in that, include: The web front-end allows users to select a target Windows server and a target project on the target Windows server, and sends operation instructions for the target project to the target Windows server. At least two Windows servers, each running a local automated service program; The local automation service program is used to automatically discover and register multiple projects on the Windows server and maintain metadata for each project. And for receiving operation instructions sent by the Web frontend, and for executing automated operations related to the target project locally on the Windows server based on the target project's metadata; The web front-end communicates directly with the local automation service program on each of the Windows servers, and the system does not contain a central management node.

2. The Windows multi-project CI / CD automated centralized management and control system based on local services according to claim 1, characterized in that, The local automation service program is an independent executable file in EXE format, which runs on the Windows server as a Windows service or a resident process, and provides a RESTful API for expressing state. The local automation service program automatically discovers and registers multiple projects on the Windows server by scanning preset directories or reading configuration files, and maintains the metadata of each project; wherein, the metadata includes project name, main process name, configuration path, service name and database connection string; The local automation service program performs automated operations on the local Windows server by calling system resources based on the metadata of the target project, without relying on remote calls or external proxy services.

3. The Windows multi-project CI / CD automated centralized management and control system based on local services according to claim 1, characterized in that, The operation process of the Web front-end adopts a two-level dynamic routing mechanism: The first level responds to the user's selection of the target Windows server, retrieves and displays the project list from the target Windows server's local automation service program; The second level responds to the user's selection of a target project from the project list, and all subsequent application programming interface (API) requests sent by the web frontend to the target Windows server automatically carry the identifier of the target project; The web front-end is also used to display the running status panel of the selected target project, which includes service status, listening port, last deployment time, current version number, CPU usage and memory usage.

4. The Windows multi-project CI / CD automated centralized management and control system based on local services according to claim 1, characterized in that, The local automated service program includes: The security control module is used to control access to received API requests by verifying access tokens, checking IP address whitelists, and enabling HTTPS; where the token is an encrypted string used for authentication.

5. The Windows multi-project CI / CD automated centralized management and control system based on local services according to claim 4, characterized in that, The local automation service program also includes: The log auditing and statistics module is used to record operation logs related to the target project and store the operation logs in the local file system; the operation logs include timestamps, operator IP, target server, target project, operation type, input parameters, and execution results.

6. The Windows multi-project CI / CD automated centralized management and control system based on local services according to claim 5, characterized in that, The local automation service program also includes: The RESTful API layer is used to receive requests from the web frontend and return responses; The project metadata manager is used to establish and maintain the mapping relationship between project identifiers and at least one of the following resources: process name, service name, configuration file path, and database connection string. A configuration file parsing engine is used to perform structured parsing and field-level modification of the configuration files of the target project.

7. The Windows multi-project CI / CD automated centralized management and control system based on local services according to claim 6, characterized in that, The local automation service program also includes: A database client is used to connect to the database bound to the project and perform the following operations: query the schema version of the database corresponding to the target project, execute the database migration script in a predefined order, execute data definition language (DDL) or data manipulation language (DML) operations in a database transaction, and perform rollback when the operation fails. The process manager is used to manage the main process of the target project according to the project isolation principle. It supports identification and matching by process name, startup parameters or associated Windows services, and has the function of automatic process crash detection and restart.

8. The Windows multi-project CI / CD automated centralized management and control system based on local services according to claim 7, characterized in that, The local automation service program also includes: The Windows API adapter is used to operate on Windows native resources associated with the target project by calling the Windows native API or system command-line tools. The operations include starting and stopping Windows services, reading and writing registry keys, and querying event logs. The notification push module is used to push structured information, including server address, project name, operation type, and operation result, to a specified external communication platform via a Webhook after the automated operation task is completed; wherein, the Webhook is an event-triggered notification push interface.

9. A Windows multi-project CI / CD automated centralized management and control method based on local services, applied to the Windows multi-project CI / CD automated centralized management and control system based on local services as described in any one of claims 1-8, characterized in that, The method includes: In response to the user's selection of a target Windows server and a target project on the target Windows server in the web front end, an operation command for the target project is sent to the target Windows server; The operation instructions sent by the web frontend are received by a local automation service program deployed on at least two Windows servers; The local automation service program performs automated operations related to the target project on the local Windows server based on the metadata of the target project it maintains. The web front-end communicates directly with the local automation service program on each of the Windows servers, and the system does not contain a central management node.

10. The Windows multi-project CI / CD automated centralized management and control method based on local services according to claim 9, characterized in that, The web frontend uses a two-level dynamic routing mechanism to issue operation commands, specifically including: The first level responds to the user's selection of the target Windows server, and retrieves and displays the project list from the local automation service program of the target Windows server; The second level responds to the user's selection of a target project from the project list; Subsequently, all application programming interface (API) requests sent by the web frontend to the target Windows server automatically carry the identifier of the target project.

Images