Server code management and release system and method

Abstract

The invention discloses a server code management and release system and method, and belongs to the technical field of software deployment. The system comprises a code submitting and capturing module used for monitoring a version control system submitting event and generating a to-be-released task; the pre-production testing module is used for carrying out automatic testing in the simulated production environment; the release control module provides a one-key release function based on permission and time strategy verification; the file monitoring and warning module is used for periodically checking the integrity of the production environment file and identifying illegal change warning; and the file operation module provides a file visual comparison and replacement function. According to the method, full-process automation from code submission, automatic testing, controlled release to continuous monitoring is realized. The method solves the problems that in the prior art, manual intervention of the deployment process is large, authority control is weak, effective file monitoring is lacked, release conflicts are prone to being generated, and rollback is difficult, and efficient, safe and controllable code deployment and operation and maintenance management are achieved.

Description

Technical Field

[0001] This invention relates to the field of computer software deployment and maintenance technology, specifically to a server code management and release system and method. Background Technology

[0002] In the field of software development and operations (DevOps), code deployment and version management are core aspects of ensuring the continuous and stable deployment of applications. As business systems become more complex and release frequencies accelerate, traditional or semi-automated code management and release processes are increasingly showing their limitations.

[0003] Currently, common code deployment and release solutions mainly rely on the following models:

[0004] Manual deployment: After developers complete code development and submit it through a version control system (such as Git or SVN), operations personnel must manually pull updates from the code repository, verify the changes one by one using file comparison tools (such as Beyond Compare), and then use file transfer tools such as FTP or SCP to overwrite the code on the production server. This process relies entirely on manual operation, which is not only inefficient and time-consuming, but also highly susceptible to human error leading to missing or incorrect file transfers or configuration errors, causing online incidents.

[0005] Automated builds and semi-automated releases based on Continuous Integration / Continuous Deployment (CI / CD) tools: Many teams use automation servers such as Jenkins and GitLab CI to automate code building, unit testing, and packaging. However, the critical step of "deploying to the production environment" often still requires manual review, manual triggering, or complex script configuration. Taking Jenkins as an example, as a powerful general-purpose automation platform, it has significant shortcomings: First, its system configuration, plugin management, and node maintenance usually need to be done through a web interface, making it difficult to achieve complete version control of "configuration as code," resulting in high costs for environment replication and migration; second, as a Java application that requires independent maintenance, Jenkins' server operation, backup, upgrades, and plugin compatibility handling bring additional technical burdens to the team; finally, its relatively complex Master / Agent architecture and workspace concepts present a high learning curve for beginners.

[0006] However, existing code management and release processes generally suffer from the following technical shortcomings:

[0007] (1) The deployment process is cumbersome and error-prone: It relies too much on manual intervention. From code retrieval and file comparison to uploading and deployment, the chain of steps is long. Manual operation at any link may introduce errors, making it difficult to guarantee deployment efficiency and reliability.

[0008] (2) Lack of refined control over publishing permissions and time: There is a lack of integrated permission verification mechanism that is combined with business processes, and it is also impossible to flexibly set the time window for publishing at the system level (such as only during off-peak business periods), which poses a risk of misoperation or non-compliant publishing.

[0009] (3) Lack of file security monitoring in the production environment: It is impossible to effectively monitor whether files on the production server have been modified unexpectedly (such as uploaded through non-standard processes, maliciously tampered with, etc.). The lack of automated file integrity verification and real-time alarm mechanisms makes it difficult to locate security risks and faults. Summary of the Invention

[0010] To address the shortcomings of existing technologies, this invention provides a server code management and deployment system and method that overcomes the deficiencies of existing technologies and solves problems such as excessive manual intervention in the deployment process, weak access control, lack of effective file monitoring, easy generation of deployment conflicts, and difficulty in rollback. It achieves efficient, secure, and controllable code deployment and operation and maintenance management.

[0011] To achieve the above objectives, the present invention provides the following technical solution:

[0012] A server code management and deployment system, comprising:

[0013] The code submission and capture module is used to communicate with the version control system, listen for code submission events, capture submitted metadata in real time, and generate a list of tasks to be released based on the metadata. The metadata includes at least the submitted version, submitter, submission time, and a list of changed files.

[0014] The pre-production testing module, connected to the code submission and capture module, is used to deploy the code in the list of tasks to be released to a pre-production server simulating a production environment for automated testing.

[0015] The release control module, connected to the pre-production testing module, is used to manage the tasks to be released that have passed the test, and provides a one-click release function based on user permission verification and release time policy control.

[0016] The file monitoring and alarm module is used to periodically perform integrity checks on files in the production server and send alarm information when unauthorized modifications are detected.

[0017] The file operation module provides functions for downloading, visually comparing, and selectively replacing files on the production server.

[0018] Preferably, the code submission and capture module includes:

[0019] Version control system interface submodule, used to support Git or SVN version control systems;

[0020] The code change monitoring submodule is used to monitor code commit events in real time;

[0021] The "To-be-Published List Generation" submodule is used to generate a structured list of tasks to be published based on the submission records.

[0022] Preferably, the publishing control module includes:

[0023] The permission verification submodule is used to verify whether the user who triggered the publish command has the publishing permission.

[0024] The time strategy management submodule is used to restrict publishing operations to be executed within a preset time period;

[0025] The one-click deployment execution submodule is used to automatically deploy code to the production server and record deployment logs;

[0026] The mutual exclusion release control submodule is used to prevent multiple release tasks from executing simultaneously through a task queue mechanism.

[0027] Preferably, the publishing control module further includes:

[0028] The review and release submodule is used to allow approved release operations outside of preset time periods;

[0029] The version rollback submodule is used to restore the code on the production server to a specified historical release version in the event of a release failure or problem.

[0030] Preferably, the file monitoring and alarm module includes:

[0031] The file hash comparison submodule is used to calculate the hash value of the production server file as the first fingerprint.

[0032] The baseline fingerprint library submodule is used to store the file hash values ​​calculated and saved based on the file content deployed to the production server after each successful release, which serve as the baseline fingerprint.

[0033] The comparison and analysis submodule is used to compare the first fingerprint with the corresponding benchmark fingerprint in the benchmark fingerprint database. If they do not match, it further verifies whether the change occurred within the maintenance window period recorded by the system. If not, it is determined to be an illegal change.

[0034] The Change Source Identification submodule is used to determine whether a file modification originated from a release operation within this system.

[0035] The alarm notification submodule is used to send alarm information to designated personnel when unauthorized modifications are detected.

[0036] Preferably, the verification triggering conditions of the file monitoring and alarm module include timed triggering and event triggering, wherein the event triggering is a verification triggered immediately after the release control module completes the release.

[0037] Preferably, the file operation module includes:

[0038] The file download submodule is used to download specified files from the production environment.

[0039] The file comparison and replacement submodule provides a visual interface to display file differences and supports one-click replacement.

[0040] This invention also discloses a server code management and deployment method, applied to the aforementioned system, the method comprising the following steps:

[0041] S10: Code Submission and Capture; Establish a connection with the version control system through the system interface and monitor the code repository's submission events in real time; When a submission event is captured, parse and record the submitted metadata, which includes at least: version identifier, submitter information, submission timestamp, and a list of changed file paths;

[0042] Based on the aforementioned metadata, a release task with a status of "pending testing" is automatically created and added to the list of tasks to be released.

[0043] S20: Pre-production testing; automatically deploy or synchronize the code and its dependencies corresponding to the release task to a separate pre-production server used to simulate the production environment; execute a pre-set automated test suite on the pre-production server to perform functional, compatibility or stability tests on the code;

[0044] If the test passes, the status of the release task is updated to "Test passed, awaiting release"; if the test fails, the status is updated to "Test failed" and an error log is recorded, and the process terminates.

[0045] S30: Release control and execution; Receives "one-click release" instructions for tasks that have passed the test in the graphical user interface; Verifies the user's permissions and current time policy when initiating the instruction; After successful verification, automatically executes the operation of synchronizing the code to the production server and updates the task status;

[0046] S40: Production Environment Monitoring and Alerts: Perform compliance checks on a specified set of files on the production server according to a preset time period or triggered by an event after each successful release;

[0047] The compliance verification includes: calculating the current hash value of the file and comparing it with the baseline hash value recorded by the system, which was generated by the most recent successful release;

[0048] If the comparison reveals an inconsistency, and the system determines that the change was not generated by the aforementioned release execution sub-step, an alarm event will be automatically generated, and alarm information will be sent to the preset responsible person through the integrated notification channel.

[0049] Preferably, in step S10, a mutual exclusion queue mechanism is used to handle concurrent requests: when the system is processing a code submission or release task, newly arriving submission events will be placed in a waiting queue and processed in order to avoid concurrent access conflicts to shared resources.

[0050] Preferably, S30 specifically includes:

[0051] S31: In the system's graphical user interface, display a list of release tasks with a status of "Test passed, awaiting release" to authorized users;

[0052] S32: Responds to a user's "one-click publish" command triggered by a task;

[0053] S33: Permission and Policy Verification: Verify the identity and permissions of the user who initiated the command, and determine whether the current system time conforms to the preset release time policy;

[0054] S34: Release Execution: If and only if both permissions and time policy are verified, the release operation is automatically executed to securely deploy the code corresponding to the task from the version repository or pre-production environment to the target location on the production server.

[0055] S35: Status Update and Log Recording: After the deployment is completed, update the task status to "Deployment Successful" or "Deployment Failed"; and generate a detailed deployment log, which includes the executor, execution time, list of deployed files, and operation results;

[0056] S36: Release Rollback: In response to a user's rollback command for a released task, the system automatically restores the code of the relevant files on the production server to the specified version state before the release, based on the version history, and generates the corresponding rollback log.

[0057] This invention provides a server code management and deployment system and method. It has the following beneficial effects:

[0058] By deeply integrating the code submission and capture module with the version control system, automatic detection and task creation of code submission events are achieved, replacing the traditional method of manually monitoring the code repository and manually creating release tasks. The automated deployment and testing of the pre-production testing module, along with the "one-click release" function of the release control module, construct an automated pipeline from code submission to production deployment. This effectively eliminates a series of tedious and error-prone intermediate steps such as manually pulling code, manually comparing, and manually uploading, shortening the deployment process from hours or even longer to minutes, greatly improving software delivery efficiency and significantly reducing the risk of production failures due to human error.

[0059] The system employs a two-factor authentication mechanism (DBM) and a time-based policy management submodule to implement release operations. Only authorized users can execute production releases within a preset security time window, fundamentally preventing unauthorized releases and arbitrary releases during high-risk periods, thus ensuring a rigorous and controllable release process. The mutual exclusion release control submodule ensures that the system processes only one core release task at a time, effectively resolving concurrency issues such as file overwriting and version conflicts that may arise from multiple users releasing simultaneously, guaranteeing the atomicity of release operations and the stability of the production environment.

[0060] The file monitoring and alerting module establishes a continuous and proactive monitoring mechanism for the integrity of files in the production environment through periodic file hash comparisons. This mechanism can sensitively detect any file changes that are not generated through the official release process of this system. Combined with change source identification and real-time alerting functions, this enables the operations team to respond quickly and handle security incidents in a timely manner before they cause substantial business impact, greatly enhancing the security protection level and compliance assurance capabilities of the production system.

[0061] By automatically recording structured metadata and operation logs at every stage, a complete audit trail is formed. Every release can be clearly traced back to "who, when, what code was released, and what the result was," providing a reliable basis for problem identification, responsibility allocation, and process review. This end-to-end visibility and traceability not only meets the stringent requirements of enterprise internal control and external compliance audits, Attached Figure Description

[0062] To more clearly illustrate the technical solutions in this invention or the prior art, the accompanying drawings used in the description of the prior art will be briefly introduced below.

[0063] Figure 1 System architecture module diagram of the present invention;

[0064] Figure 2 Flowchart of the method of this invention;

[0065] Figure 3 Document monitoring and alarm sub-flowchart in this invention;

[0066] Figure 4 Flowchart of the mutual exclusion queue mechanism in this invention;

[0067] Figure 5 The flowchart of the dual verification process of permissions and time policy in this invention. Detailed Implementation

[0068] To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings.

[0069] Example 1, as Figures 1 to 5 As shown, the server code management and deployment system provided by this invention is typically deployed on one or more dedicated application servers, which are connected to the following key external environments via a network:

[0070] Version control servers, such as GitLab and SVN servers, store project source code.

[0071] Pre-production servers: Hardware and software configurations that simulate the production environment as closely as possible, for use in automated testing before deployment.

[0072] Production server cluster: The online servers that ultimately provide services to the outside world.

[0073] SMS gateway / message push service: used to send alarm notifications.

[0074] The system software can be implemented based on a B / S architecture, with the backend developed using languages ​​such as PHP and the frontend providing a web management interface.

[0075] The system mainly includes a code submission and capture module, a pre-production testing module, a release control module, a file monitoring and alerting module, and a file operation module. Specifically:

[0076] The code submission and capture module communicates with the version control system, listens for code submission events, captures submitted metadata in real time, and generates a list of tasks to be released based on the metadata. The metadata includes at least the submitted version, submitter, submission time, and a list of changed files. Specifically, it includes:

[0077] Version control system interface submodule: This submodule actively retrieves commit events by calling Git's git hook (such as post-receive) or SVN's post-commit hook, or by periodically polling the repository API (such as the GitLab API). This submodule encapsulates the differences between different version control systems and provides a unified commit event data format.

[0078] The code change monitoring submodule is deployed internally to continuously monitor commit event messages received from the version control system interface submodules mentioned above. Once a commit event is captured, the commit data packet is immediately parsed to extract key metadata. This metadata includes at least: a unique version identifier for the commit (such as a Git commit ID or an SVN revision number), the committer's name / account, the commit timestamp, and a list of file paths added, modified, or deleted in this commit.

[0079] The module for generating the list of tasks to be published takes the parsed metadata and combines it with pre-configured project information (such as project name and corresponding production server path) according to a predefined structure, and encapsulates it to generate a new record for tasks to be published in the system database. This record is initially marked as "Pending Testing" and contains all extracted metadata fields, thus being displayed in the system's list of tasks to be published.

[0080] The pre-production testing module, connected to the code submission and capture module, is used to deploy code from the list of tasks to be released to a pre-production server simulating a production environment for automated testing; its implementation includes:

[0081] 1) The system maintains an independent pre-production server cluster, whose operating system, middleware, database version and network topology are kept as consistent as possible with the production environment to simulate real online operating conditions.

[0082] 2) When the status of a task to be released is "Pending Testing", the scheduler of this module will trigger the deployment process. For example, using tools such as Ansible or Kubernetes, the code version corresponding to the task is pulled from the repository and deployed to the pre-production server along with its dependent environment.

[0083] 3) After deployment, the pre-set test scripts for the project will be automatically triggered. These scripts may include unit tests, API interface tests, integration tests of core business processes, etc., with the aim of finding obvious code errors (such as compilation errors, HTTP 500 internal server errors, interruptions in core business processes, etc.).

[0084] 4) Test results are automatically sent back to the system to update the task status. If the test passes, the task status is updated to "Test passed, pending release"; if the test fails, the status is updated to "Test failed", a detailed error log is recorded, the process is terminated, and the submitter is notified.

[0085] The release control module, connected to the pre-production testing module, manages release tasks that have passed testing and provides a one-click release function based on user permission verification and release time policy control; specifically, it includes:

[0086] The permission verification submodule integrates with the enterprise's unified identity authentication system (such as LDAP) or maintains an independent role and permission table. When a user clicks the "One-Click Publish" button on the front-end interface, this submodule verifies whether the currently logged-in user's identity exists in the list of user groups or roles with "Publish Permissions". If the user lacks permission, the request is intercepted, and an "Insufficient Permissions" message is returned to the front-end.

[0087] The Time Policy Management submodule provides a configuration interface that allows administrators to set permitted publishing "time windows" for different projects or globally. For example, it can be configured as "Monday to Thursday, 13:00 to 16:00". When a publishing command is triggered outside of a permitted time period, this submodule checks whether the server's current time is within any valid time window. If not, publishing is blocked and a message is displayed: "Publishing is not allowed at the current time."

[0088] The mutual exclusion release control submodule implements a simple global release task queue to ensure the atomicity of release operations and avoid file conflicts caused by concurrent releases.

[0089] A global deployment task queue is maintained in the system background. Whether it's task creation after code commit capture or execution of a "one-click deploy" command, a global lock must be acquired first. When a deployment task begins execution, a global lock is acquired or the task is set to an "in progress" state. During this period, any deployment operations triggered by other users will enter the waiting queue or receive a "task is already being deployed, please wait" message, until the previous task completes and releases resources. This ensures that only one core task (commit processing or deployment execution) is modifying system state or manipulating production environment files at any given time, thus preventing concurrency conflicts.

[0090] The one-click deployment execution submodule: Once permissions and time policies are verified and the execution lock is acquired, this submodule initiates the deployment process. Its core function is to call deployment scripts (such as Ansible Playbooks or Shell scripts) or connect to the production server via SSH to accurately obtain the file content of the corresponding version, execute code synchronization commands (such as rsync or git pull), and accurately overwrite the tested code from the repository or pre-production environment to the target directory on the production server. The synchronization process can use an incremental approach to improve efficiency. Key operations throughout the process (such as connection information, file transfer lists, start and end times) are captured in real time and recorded in the deployment log.

[0091] The Release Review and Rollback submodule provides a "Review Release" channel for situations requiring release outside the designated time window, such as urgent fixes. When a user triggers a release outside the permitted time period, the system generates a review request and notifies an administrator with approval authority. Release can proceed only after administrator approval. Furthermore, the system archives file snapshots (or reverse operation scripts) of all successfully released versions. When a rollback is needed, the user can select the target historical version on the interface; this submodule will automatically perform the restore operation and log the rollback.

[0092] The file monitoring and alarm module is used to periodically perform integrity checks on files in the production server and send alarm information when unauthorized modifications are detected; specifically, it includes:

[0093] Baseline fingerprint database submodule: After each successful deployment via the one-click release execution submodule, this submodule immediately iterates through the updated files on the production server, calculates the hash value of each file using a hash algorithm (such as SHA-256), and stores the mapping relationship of [file path, hash value, release time] as a baseline fingerprint in a dedicated database, forming the baseline fingerprint database.

[0094] The file hash comparison submodule sets up a scheduled task (e.g., executed every 15 minutes) to traverse the list of monitored files on the production server and calculate their current hash value (called the first fingerprint). Then, it compares the first fingerprint with the baseline fingerprint of the corresponding path in the baseline fingerprint database.

[0095] The comparison and analysis submodule compares the calculated current hash value with the latest baseline hash value of the file in the baseline fingerprint database.

[0096] Change Source Identification Submodule: To improve accuracy, the judgment logic is as follows: a) If the hash values ​​are inconsistent, check whether the last modification time of the file falls within a very short tolerance period after a "system-recorded successful release time point", or whether it is within the "system maintenance window" pre-configured by the administrator. b) If neither of these conditions is met, the change is determined to be an "unauthorized modification".

[0097] Alarm notification submodule: Once an illegal change is determined, the system immediately reads the contact information of the person in charge of the project from the configuration and calls the integrated messaging service API (such as Alibaba Cloud SMS, WeChat Work robot, email server) to send an alarm message containing details such as server IP, file path, and change time according to the preset recipient list.

[0098] The file manipulation module provides functions for downloading, visually comparing, and selectively replacing files from the production server. Specifically, it includes:

[0099] The file download submodule allows authorized users to browse the production server's directory tree on the front-end interface, select a specified production server and file path, and initiate a download request. The system backend proxies this request and securely transmits the file stream to the user's browser.

[0100] The file comparison and replacement submodule allows users to select a local file and a file on a production server, or select the same file from two different releases, and compare it with any historical version in the repository (such as the previous production version). The system uses a difference comparison algorithm (such as diff) to visually display the differences in the text files (line-level additions, deletions, and modifications) in a highlighted format on the interface. For cases requiring replacement, users can confirm the differences and then securely upload and replace the corresponding file on the production server with the specific version or the locally modified file through the interface. This replacement operation is also subject to access control and is logged.

[0101] This invention achieves automatic detection and task creation of code submission events through deep integration of the code submission and capture module with the version control system, replacing the traditional method of manually monitoring the code repository and manually creating release tasks. The automated deployment and testing of the pre-production testing module, along with the "one-click release" function of the release control module, constructs an automated pipeline from code submission to production deployment. This effectively eliminates a series of tedious and error-prone intermediate steps such as manually pulling code, manually comparing, and manually uploading, shortening the deployment process from hours or even longer to minutes, greatly improving software delivery efficiency and significantly reducing the risk of production failures due to human error.

[0102] The system employs a two-factor authentication mechanism (DBAM) and a time-based policy management submodule to implement release operations. Only authorized users can execute production releases within a pre-defined security time window, fundamentally preventing unauthorized releases and arbitrary releases during high-risk periods (such as peak business hours or nighttime), ensuring a rigorous and controllable release process. The mutual exclusion release control submodule ensures that the system processes only one core release task at a time, effectively resolving concurrency issues such as file overwriting and version conflicts that may arise from multiple users releasing simultaneously, thus guaranteeing the atomicity of release operations and the stability of the production environment.

[0103] The file monitoring and alerting module establishes a continuous and proactive monitoring mechanism for the integrity of files in the production environment through periodic file hash comparisons. This mechanism can sensitively detect any file changes (including accidental operations and malicious tampering) that are not part of the official release process of this system. Combined with change source identification and real-time alerting functions, this enables the operations team to respond quickly and handle security incidents in a timely manner before they cause substantial business impact, greatly enhancing the security protection level and compliance assurance capabilities of the production system.

[0104] By automatically recording structured metadata and operation logs at each stage (commit, test, release, rollback), a complete audit trail is formed. Every release can be clearly traced back to "who, when, what code was released, and what the result was," providing a reliable basis for problem localization, responsibility allocation, and process review.

[0105] Example 2, as Figures 2 to 5 As shown, the present invention also discloses a server code management and deployment method, applied to the above-mentioned system, the method comprising the following steps:

[0106] S10: Code submission and capture; specifically includes:

[0107] S11: Event Trigger: After developers complete the modifications to the user login logic locally, they execute Git commands or similar SVN commit commands to push the code to the remote repository.

[0108] S12: On the version control server, the pre-configured post-receive hook is activated. This hook script encapsulates the core metadata of this commit (including but not limited to: repository URL, branch name, unique commit version ID generated by this push, commit author information, commit timestamp, and a list of changed file paths calculated by git diff or svn diff) into a JSON-formatted HTTP request and sends it to the dedicated API endpoint provided by the code commit and capture module of this invention.

[0109] S13: Data Parsing and Task Creation: The code change monitoring submodule receives and verifies the request. Upon successful verification, it parses the JSON data and extracts structured information. The release list generation submodule inserts a new record into the release task table of the system database based on the parsing results. Record fields include: Task ID (system-generated unique ID), Submission Version ID, Submitter, Submission Time, List of Changed Files (stored as an array), and Task Status (initially set to "Pending Testing").

[0110] S14: Concurrency Control Processing (Key Feature): During step 3, the system checks a global "processing lock." If the lock is already held (indicating the system is processing the previous submission or publication task), the current submission request is temporarily stored in a memory or persistent queue, and a "received, queued" response is immediately returned to the hook. Only after the current task finishes processing and releases the lock will the next request in the queue be retrieved and processed. This mechanism ensures the serialization of task generation, avoiding concurrent conflicts at the source.

[0111] Step S20: Automated testing and verification in the pre-production environment;

[0112] This step serves as a "safety gate" for production releases, ensuring code quality. Specifically, it includes:

[0113] S21: Task Scheduling: The system's background task scheduler periodically scans the published task table for records with a status of "Pending Test".

[0114] S22: Environment Deployment: For the acquired tasks, the pre-production testing module initiates the deployment process:

[0115] Based on the commit version ID in the task, execute `git checkout <commit version ID>` or `svn update -r <version number>` in the corresponding project directory on the pre-production server to obtain the exact version of the code. Execute the project-defined build commands (such as `mvn package`, `npm run build`) to generate deployable application artifacts. Deploy the artifacts to the runtime environment of the pre-production server.

[0116] S23: Automated Test Execution: Once the environment is ready, the automated test suite associated with this project is automatically triggered. Tests include:

[0117] Service health check: Call the application's health check interface to confirm that the service has started successfully.

[0118] API interface testing: Verify whether the input and output of the core business interfaces meet expectations.

[0119] Core process integration testing: Simulate key user operation paths to verify the integrity of the business process.

[0120] S24: Result Feedback and Status Transition: The testing framework sends test results (success / failure, pass rate, error logs) back to the system. If all preset test cases pass, the system updates the task status to "Test passed, awaiting release." If any test case fails, the status is updated to "Test failed," and detailed error logs are associated with the task record. The process terminates here, and the system automatically notifies the task submitter and relevant test manager via email or instant messaging.

[0121] S30: Release control and execution;

[0122] This step is a core control point in the process, ensuring the security and compliance of the release operation. Specifically, it includes:

[0123] S31: Operations personnel with publishing privileges log in to the system's web management backend. On the "Publish Console" page, the system clearly displays a list of all publishing tasks with a status of "Test passed, awaiting release," including information such as version, submitter, submission time, and change summary.

[0124] S32: The operations and maintenance personnel select the target task and click the corresponding "One-click Release" command;

[0125] S33: Permission and Policy Verification: The permission verification submodule intercepts the publish request, extracts the user's identity information for the current session, queries the permission database, and confirms whether the user's role (e.g., "Publish Administrator") has publish permissions for the current project or environment. The time policy management submodule performs verification simultaneously, querying the publish time policy table configured for this production environment. Assuming the policy is "09:00-12:00, 14:00-18:00 on weekdays," if the current time is Tuesday 15:30, the verification passes; if it is Friday 22:00 or a non-working day, the verification fails. If any verification fails, the system immediately displays a clear message on the front end (e.g., "Insufficient permissions" or "Publishing is not allowed at the current time") and prevents the publish process from continuing.

[0126] S34: Release Execution: After the release is completed, update the task status to "Release Successful" or "Release Failed"; and generate a detailed release log, which includes the executor, execution time, list of deployed files, and operation results.

[0127] Once both checks pass, the execution submodule takes over the process with a single click. Based on the list of changed files in the task, it creates a temporary workspace on the production server and precisely exports the corresponding version's file content from the version control repository.

[0128] Atomic operation design is employed: tools such as rsync are typically used to synchronize changed files to the target directory on the production server, and the original files are backed up before being overwritten. For services that require restarting, a post-deployment hook script can be configured to automatically execute the graceful restart command.

[0129] S35: Status Update and Log Recording: After the deployment action is completed, the system updates the task status to "Deployment Successful". At the same time, a detailed deployment log is generated in the deployment log table, recording the task ID, publisher, deployment time, target server, list of deployed files, and a summary of the operation results.

[0130] S36: Release Rollback Support: This is an optional recovery step. If serious problems are discovered through monitoring or user feedback after release, operations personnel can find the corresponding "Release Successful" record on the release history page and click the "Rollback" button. The system will automatically identify the list of files covered by this release and the location of their backup files, perform a quick recovery operation, and generate a rollback log record.

[0131] S40: Continuous production environment document monitoring and intelligent alerts:

[0132] This step constitutes a safety loop in the process, providing continuous protection. Specifically, it includes:

[0133] S41: Baseline Fingerprint Establishment: After successful release in step S34, the event trigger of the file monitoring and alarm module is immediately invoked. It calculates the hash value (e.g., SHA-256) of all production environment files updated in this release, and stores [absolute file path, hash value] as the new baseline fingerprint in the baseline fingerprint database table, and marks the corresponding release record ID.

[0134] S42: Periodic Compliance Verification: The system is configured with a scheduled task that runs every 15 minutes. During task execution: The file hash comparison submodule remotely connects to the production server, traverses all monitored application directories, and calculates the current hash value (first fingerprint) of each monitored file. The comparison analysis submodule compares the first fingerprint with the latest baseline fingerprint of that file in the baseline fingerprint database.

[0135] S43: Intelligent Change Recognition and Alarm Decision-Making

[0136] Scenario A: Hash consistency. Process ends, no action taken.

[0137] Scenario B: Hash Inconsistency: The Change Source Identification submodule initiates analysis: It queries the release log table to check if the file's last modification time is immediately following a recorded successful release time (e.g., within 5 minutes). If so, it is determined to be an authorized change. If not, it further checks the system maintenance calendar to confirm if it is currently within a pre-announced maintenance window. If so, it is determined to be a planned change. If none of the above applies, it is ultimately determined to be an "unauthorized / illegal change".

[0138] S44: Alarm Information Generation and Push: Once an illegal change is determined, the system immediately records the event in the alarm log table and calls the alarm notification submodule to push the alarm notification, which includes key information such as server address, file path, and detection time, to the pre-set operation and maintenance personnel or security team in real time.

[0139] The entire process begins in step S10 and continues until step S40, establishing continuous monitoring of the production environment. New code commits will trigger step S10 again, initiating a new round of automated processes, thereby achieving a continuous, secure, and controllable cycle of software delivery.

[0140] This invention integrates the previously discrete, manually sequential submission, testing, and deployment stages into a seamless, automated pipeline. This end-to-end automation significantly improves deployment efficiency and accuracy. The entire release process is reduced from hours to minutes, allowing for a marked increase in deployment frequency. Simultaneously, automation minimizes risks introduced by human error, missed steps, or incorrect execution order, fundamentally ensuring the consistency and repeatability of each release and significantly improving deployment success rates.

[0141] By constructing a multi-layered security defense, the controllability and compliance of the release process are strengthened, significantly reducing the risks of unauthorized releases, configuration drift, and operational repudiation. This makes release activities knowable, controllable, and auditable, greatly improving the security level of production change management.

[0142] By establishing continuous and proactive monitoring capabilities, real-time awareness and rapid response to security threats are achieved. This enables the rapid detection of file tampering caused by operational errors, malicious intrusions, or unknown vulnerabilities, significantly reducing the average detection time. This allows security teams to intervene before attacks spread or impact business operations, improving the overall resilience and security level of the system.

[0143] When an online failure occurs, it can quickly pinpoint whether the issue stems from a release (by tracing logs) and provide visual comparisons to aid analysis. If a rollback is necessary, it can be executed extremely quickly, minimizing the average recovery time, ensuring the continuity of core business operations, and reducing losses caused by the failure.

[0144] The present invention, through the method described in Embodiment 2, not only achieves automation, security hardening, or monitoring enhancement in individual technologies, but more importantly, it organically connects and deeply integrates these technologies to form a systematic engineering solution. It comprehensively improves the integrated capabilities of software development and operation from multiple dimensions such as efficiency, security, reliability, maintainability, and collaboration, providing practical and effective technical support for resolving the core contradiction between the rapid iteration of modern internet services and the stable and secure operation of systems.

[0145] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. 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. Such 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 server code management and deployment system, characterized in that: include: The code submission and capture module is used to communicate with the version control system, listen for code submission events, capture submitted metadata in real time, and generate a list of tasks to be released based on the metadata. The metadata includes at least the submitted version, submitter, submission time, and a list of changed files. The pre-production testing module, connected to the code submission and capture module, is used to deploy the code in the list of tasks to be released to a pre-production server simulating a production environment for automated testing. The release control module, connected to the pre-production testing module, is used to manage the tasks to be released that have passed the test, and provides a one-click release function based on user permission verification and release time policy control. The file monitoring and alarm module is used to periodically perform integrity checks on files in the production server and send alarm information when unauthorized modifications are detected. The file operation module provides functions for downloading, visually comparing, and selectively replacing files on the production server.

2. The server code management and deployment system according to claim 1, characterized in that: The code submission and capture module includes: Version control system interface submodule, used to support Git or SVN version control systems; The code change monitoring submodule is used to monitor code commit events in real time; The "To-be-Published List Generation" submodule is used to generate a structured list of tasks to be published based on the submission records.

3. The server code management and deployment system according to claim 1, characterized in that: The release control module includes: The permission verification submodule is used to verify whether the user who triggered the publish command has the publishing permission. The time strategy management submodule is used to restrict publishing operations to be executed within a preset time period; The one-click deployment execution submodule is used to automatically deploy code to the production server and record deployment logs; The mutual exclusion release control submodule is used to prevent multiple release tasks from executing simultaneously through a task queue mechanism.

4. The server code management and deployment system according to claim 1, characterized in that: The release control module also includes: The review and release submodule is used to allow approved release operations outside of preset time periods; The version rollback submodule is used to restore the code on the production server to a specified historical release version in the event of a release failure or problem.

5. A server code management and deployment system according to claim 1, characterized in that: The file monitoring and alarm module includes: The file hash comparison submodule is used to calculate the hash value of the production server file as the first fingerprint. The baseline fingerprint library submodule is used to store the file hash values ​​calculated and saved based on the file content deployed to the production server after each successful release, which serve as the baseline fingerprint. The comparison and analysis submodule is used to compare the first fingerprint with the corresponding benchmark fingerprint in the benchmark fingerprint database. If they do not match, it further verifies whether the change occurred within the maintenance window period recorded by the system. If not, it is determined to be an illegal change. The Change Source Identification submodule is used to determine whether a file modification originated from a release operation within this system. The alarm notification submodule is used to send alarm information to designated personnel when unauthorized modifications are detected.

6. The server code management and deployment system according to claim 1, characterized in that: The verification triggering conditions of the file monitoring and alarm module include timed triggering and event triggering. The event triggering is a verification triggered immediately after the release control module completes the release.

7. A server code management and deployment system according to claim 1, characterized in that: The file operation module includes: The file download submodule is used to download specified files from the production environment. The file comparison and replacement submodule provides a visual interface to display file differences and supports one-click replacement.

8. A method for server code management and deployment, characterized in that: Applied to the system as described in any one of claims 1-7, the method comprises the following steps: S10: Code Submission and Capture; Establish a connection with the version control system through the system interface and monitor the code repository's submission events in real time; When a submission event is captured, parse and record the submitted metadata, which includes at least: version identifier, submitter information, submission timestamp, and a list of changed file paths; Based on the aforementioned metadata, a release task with a status of "pending testing" is automatically created and added to the list of tasks to be released. S20: Pre-production testing; automatically deploy or synchronize the code and its dependencies corresponding to the release task to a separate pre-production server used to simulate the production environment; execute a pre-set automated test suite on the pre-production server to perform functional, compatibility, or stability tests on the code; If the test passes, the status of the release task is updated to "Test passed, awaiting release"; if the test fails, the status is updated to "Test failed" and an error log is recorded, and the process terminates. S30: Release control and execution; Receives "one-click release" instructions for tasks that have passed the test in the graphical user interface; Verifies the user's permissions and current time policy when initiating the instruction; After successful verification, automatically executes the operation of synchronizing the code to the production server and updates the task status; S40: Production Environment Monitoring and Alerts: Perform compliance checks on a specified set of files on the production server according to a preset time period or triggered by an event after each successful release; The compliance verification includes: calculating the current hash value of the file and comparing it with the baseline hash value recorded by the system, which was generated by the most recent successful release; If the comparison reveals an inconsistency, and the system determines that the change was not generated by the aforementioned release execution sub-step, an alarm event will be automatically generated, and alarm information will be sent to the preset responsible person through the integrated notification channel.

9. The server code management and deployment method according to claim 8, characterized in that: In step S10, a mutual exclusion queue mechanism is used to handle concurrent requests: when the system is processing a code submission or release task, newly arriving submission events will be placed in a waiting queue and processed in order to avoid concurrent access conflicts to shared resources.

10. The server code management and deployment method according to claim 8, characterized in that: S30 specifically includes: S31: In the system's graphical user interface, display a list of release tasks with the status "Test passed, awaiting release" to authorized users; S32: Responds to a user's "one-click publish" command triggered for a specific task; S33: Permission and Policy Verification: Verify the identity and permissions of the user who initiated the command, and determine whether the current system time conforms to the preset release time policy; S34: Release Execution: If and only if both permissions and time policy are verified, the release operation is automatically executed to securely deploy the code corresponding to the task from the version repository or pre-production environment to the target location on the production server. S35: Status Update and Log Recording: After the deployment is completed, update the task status to "Deployment Successful" or "Deployment Failed"; and generate a detailed deployment log, which includes the executor, execution time, list of deployed files, and operation results; S36: Release Rollback: In response to a user's rollback command for a released task, the system automatically restores the code of the relevant files on the production server to the specified version state before the release, based on the version history, and generates the corresponding rollback log.

Images