Production line construction method and system for version automatic marking

Abstract

The invention discloses an assembly line construction method and system for version automatic marking, and the method comprises the steps: completing information collection and writing by an automatic deployment tool according to a self-defined metadata structure, monitoring code submission through Webhook, and transmitting a trigger signal; the continuous integration server pulls the latest submitted code from the code warehouse and executes construction operation; after the construction is passed, constructing an application mirror image, and pushing the application mirror image to a specified mirror image warehouse; and the automatic deployment tool pulls the application mirror image of the corresponding version from the mirror image warehouse, and starts the application in the target environment to complete the automatic deployment of the project. According to the method, the correlation tracing efficiency of the code version information and the construction product is improved, the manual recording and maintenance cost is reduced, and the reliability and maintainability of automatic deployment are improved.

Description

Technical Field

[0001] This invention belongs to the field of continuous integration and deployment in software development, and specifically relates to a pipeline construction method and system for automated version marking. Background Technology

[0002] In the context of widespread adoption of cloud-native and microservice architectures, software delivery faces several challenges: First, version drift is becoming increasingly prominent. Traditional tagging methods lead to inconsistent versions across multiple environments, and in containerized scenarios, images and source code versions become disconnected, resulting in low rollback accuracy. Second, source tracing is inefficient. Fault localization in production environments requires multiple steps, including log analysis and build record retrieval, which is time-consuming and inaccurate. Against this backdrop, the software delivery process urgently needs a lightweight solution that can automatically solidify versions during the build phase and enable rapid source tracing of code versions to address the version governance challenges brought about by the high-frequency delivery in the cloud-native era. Summary of the Invention

[0003] (a) Purpose of the invention The purpose of this invention is to provide a pipeline construction method and system for automated version marking. This application improves the efficiency of linking code version information with build artifacts, reduces manual recording and maintenance costs, and enhances the reliability and maintainability of automated deployment.

[0004] (II) Technical Solution To address the aforementioned problems, a first aspect of the present invention provides a pipeline construction method for automated version tagging. The method is based on an automated version tagging system, which includes automated deployment tools, a code repository, a continuous integration server, and a mirror repository. The method includes: After the automated deployment tool completes information collection and writing according to the custom metadata structure, it executes code submission to the code repository; After the code repository detects a code commit event via Webhook, it sends a trigger signal to the continuous integration server. After receiving the trigger signal, the continuous integration server pulls the latest committed code from the code repository and performs a build operation; After the code build is successful, the continuous integration server builds the application image and pushes it to the specified image repository; The automated deployment tool pulls the corresponding version of the application image from the image repository, starts the application in the target environment, and completes the automated deployment of the project.

[0005] Preferably, the automated deployment tool completes information collection and writing according to a custom metadata structure, including: After the metadata is defined, the version control information of the target metadata is collected and persisted to the attribute file; During the packaging phase, the data in the attribute file is converted into manifest entries and written to the MANIFEST.MF file.

[0006] Preferably, after the code repository detects a code commit event via Webhook, sending a trigger signal to the continuous integration server includes: When a specific event occurs in the code repository, a webhook request is sent to the automated deployment tool. After receiving and verifying the Webhook request, the automated deployment tool sends a trigger signal to the continuous integration server.

[0007] Preferably, the step of pulling the latest committed code from the code repository and performing a build operation includes: Dynamically receive code parameters according to code branches; Based on the code parameters, code is retrieved from the specified code repository address and authenticated using the specified access credentials.

[0008] Preferably, the execution of the build operation includes: generating a code build log and a code version number based on the build number, wherein the build number is generated by the automated deployment tool.

[0009] Preferably, the continuous integration server builds the application image and pushes it to the designated image repository, including: Define configuration parameter variables and exposed ports, and specify the image label; Associate the image tag with the code version number, generate the application image, and then push it to the specified image repository using docker push.

[0010] Preferably, the automated deployment tool pulls the corresponding version of the application image from the image repository, starts the application in the target environment, and completes the automated deployment of the project, including: The automated deployment tool uses the publish over SSH component built into it to complete authentication and establish an SSH tunnel with the remote server using SSH key pairs. The system pulls the corresponding version of the application image from the image repository to the remote server via the SSH channel, and calls the built-in deployment script, passing in the specified image repository address and application image information parameters to complete the automated deployment of the project.

[0011] Furthermore, a second aspect of the present invention provides a pipelined build system for automated version tagging, the system comprising an automated version tagging system, the automated tagging system including an automated deployment tool, a code repository, a continuous integration server, and a mirror repository, the pipelined build system comprising: The execution module includes: after the automated deployment tool completes information collection and writing according to the custom metadata structure, it executes and commits the code to the code repository; The triggering module includes: after the code repository detects a code commit event through a Webhook, it sends a trigger signal to the continuous integration server. The first build module includes: after the continuous integration server receives the trigger signal, it pulls the latest committed code from the code repository and performs the build operation; The second building module includes: after the code build is successful, the continuous integration server builds the application image and pushes it to the specified image repository; The deployment module includes: an automated deployment tool that pulls the corresponding version of the application image from the image repository, starts the application in the target environment, and completes the automated deployment of the project.

[0012] Preferably, the execution module specifically includes: After the metadata is defined, the version control information of the target metadata is collected and persisted to the attribute file; During the packaging phase, the data in the attribute file is converted into manifest entries and written to the MANIFEST.MF file.

[0013] Preferably, the triggering module specifically includes: When a specific event occurs in the code repository, a webhook request is sent to the automated deployment tool. After receiving and verifying the Webhook request, the automated deployment tool sends a trigger signal to the continuous integration server.

[0014] (III) Beneficial Effects The above-mentioned technical solution of the present invention has the following beneficial technical effects: The present invention provides a pipeline construction method and system for automated version marking. This application improves the efficiency of the correlation and traceability between code version information and construction products, reduces the cost of manual recording and maintenance, and improves the reliability and maintainability of automated deployment. This invention provides a method for automatically injecting source code version information during the code building process and automating build, image packaging, and deployment through a pipeline. Specifically, it includes: first, an automated deployment tool collects and writes information according to a custom metadata structure, then commits code to the code repository. This invention uses an automatic metadata injection mechanism to solve the version drift problem in traditional tagging methods. Next, the code repository detects the code commit event via a webhook and sends a trigger signal to the continuous integration server. Upon receiving the trigger signal, the continuous integration server pulls the latest committed code from the code repository and performs a build operation. After the code build is successful, the continuous integration server builds the application image and pushes it to the designated image repository. This application uses a dynamic version number generation and anchoring mechanism to solve the problem of image and source code version disconnect. By automating the process from code pulling, code building, image packaging, pushing to the image repository, to release within the pipeline, this application can quickly achieve version traceability and accurate rollback, effectively solve the version drift problem, shorten fault location time, and improve deployment reliability. Attached Figure Description

[0015] Figure 1 This is a flowchart of the pipeline construction method for automated version marking of the present invention; Figure 2 This is a schematic diagram of the pipeline construction process for the automated version marking of this invention; Figure 3 This is a technical roadmap of a specific embodiment of the present invention; Figure 4 This is a sample diagram of the metadata structure code in a specific embodiment of the present invention; Figure 5 This is a flowchart illustrating the code metadata information construction and injection process in a specific embodiment of the present invention; Figure 6 This is a schematic diagram illustrating the writing of code version metadata in a specific embodiment of the present invention; Figure 7 This is a schematic diagram of code repository synchronization according to a specific embodiment of the present invention; Figure 8 This is a schematic diagram of code construction in a specific embodiment of the present invention; Figure 9 This is a schematic diagram before the mirror image is created in a specific embodiment of the present invention; Figure 10 This is a schematic diagram illustrating the image creation and pushing process of a specific embodiment of the present invention; Figure 11This is a schematic diagram of the deployment script of a specific embodiment of the present invention; Figure 12 This is a schematic diagram of the production line according to a specific embodiment of the present invention.

[0016] Figure 13 This is a schematic diagram of the post-processing in a specific embodiment of the present invention.

[0017] Figure 14 This is a flowchart of the Webhook trigger event reception and verification process according to a specific embodiment of the present invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to specific embodiments and the accompanying drawings. It should be understood that these descriptions are merely exemplary and not intended to limit the scope of the invention. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concept of the invention.

[0019] like Figure 1 As shown, the first aspect of the present invention provides a pipeline construction method for automated version tagging. The method is based on an automated version tagging system, which includes automated deployment tools, a code repository, a continuous integration server, and a mirror repository. The method includes: S1. After the automated deployment tool completes information collection and writing according to the custom metadata structure, it commits code to the code repository. The information collection and writing according to the custom metadata structure includes: S11, after the metadata definition is completed, the version control information of the target metadata is collected and persisted as an attribute file; S12, during the packaging stage, the data in the attribute file is converted into manifest entries and written to the MANIFEST.MF file. S2. After the code repository detects a code commit event through a webhook, it sends a trigger signal to the continuous integration server. Specifically, this includes: S21, when a specific event occurs in the code repository, a webhook request is sent to the automated deployment tool; S22, after receiving and verifying the webhook request, the automated deployment tool sends a trigger signal to the continuous integration server.

[0020] S3, after receiving the trigger signal, the continuous integration server pulls the latest committed code from the code repository and performs a build operation. The process of pulling the latest committed code from the code repository and performing a build operation includes: S31, dynamically receiving code parameters according to the code branch; S32, pulling code from the specified code repository address based on the code parameters and authenticating it with the specified access credentials.

[0021] Preferably, the build operation performed in step S3 specifically includes: generating code build logs and code version numbers based on the build number, wherein the build number is generated by the automated deployment tool.

[0022] S4. After the code build is successful, the continuous integration server builds the application image and pushes it to the specified image repository. Specifically, this includes: S41, defining configuration parameter variables and exposed ports, and specifying image tags; S42, associating the image tags with the code version number, generating the application image, and then pushing it to the specified image repository via docker push.

[0023] S5, the automated deployment tool, pulls the corresponding version of the application image from the image repository, starts the application in the target environment, and completes the automated deployment of the project, specifically including: S51 uses the publish over SSH component built into the automated deployment tool to complete authentication and establish an SSH tunnel with the remote server using SSH key pairs; S52 pulls the corresponding version of the application image from the image repository to the remote server via the SSH channel, and calls the built-in deployment script, passing in the specified image repository address and application image information parameters to complete the automated deployment of the project.

[0024] Combined with appendix Figure 3 The method for constructing the production line according to the present invention is described in detail below: The technical approach of this invention includes the following steps: First, after the automated deployment tool completes information collection and writing according to the custom metadata structure, it performs the following operations: 2. Code submissions are automatically triggered in the pipeline via Webhook; 3. During the build process, Git version information is automatically collected and injected into the MANIFEST.MF file; IV. Use dynamic version numbers to associate build artifacts with image tags; V. Achieve fully automated deployment from code to production.

[0025] In the first step of the above technical approach, the processing of the metadata structure includes the following steps: (1) Metadata structure definition This invention defines the code version metadata information that needs to be injected. The data structure of the code version metadata is shown in Table 1, and the corresponding appendix... Figure 3 The code version metadata information in the "code repository" is the data source for the entire process. All subsequent metadata originates from the version control system here. Code examples are shown below. Figure 4 As shown.

[0026] Table 1 Data Definition Structure of Metadata (2) After defining the metadata structure of the code version to be injected, the process of building the metadata information collection and injection functional module is as follows (see Figure 5 ): Step 1, Code Version Metadata Collection Process Metadata collection process corresponding to the appendix Figure 5 The relevant operations in the Initialize phase are as follows: During the initialize phase of project building, the metadata collection component is activated and executed. It first recursively searches upwards from the project source code root directory for version control directories (such as .git); then it obtains version control information through the program API, including the URL of the remote repository, the complete SHA-1 ID of the latest commit pointed to by HEAD, the author information of the last commit, the commit time, and other information; after standardizing, escaping, and filtering the collected raw data, the component persists these key metadata into a property file.

[0027] Step 2, Code version metadata writing process Metadata writing process corresponding to the appendix Figure 5 The operation flow in the Package phase of project building is as follows: During the package phase, the metadata writing component is triggered. It uses the configured manifest entries to retrieve values ​​from the project's property pool and writes them to MANIFEST.MF. The resulting MANIFEST.MF is as follows: Figure 6 This contains complete version metadata, which is the key carrier for achieving version traceability.

[0028] Steps two through five in the technical roadmap correspond to the complete implementation process of the automated production line. Figure 3 The complete flowchart of the automated pipeline designed for this invention specifically includes: (1) Code repository synchronization, this step corresponds to the attached document. Figure 3 The Webhook triggering mechanism and code retrieval are explained below: Webhook triggering mechanism: Automated deployment tools and code version repositories (such as Gitee and GitLab) can use Webhook to implement a mechanism that automatically triggers builds when code submissions are made. The core logic is: when a specific event occurs in the code repository (such as code push events, merge request events, etc.), the automated deployment tool actively sends an HTTP request (Webhook) to the automated deployment tool. After receiving and verifying the request, the automated deployment tool triggers the corresponding build task according to preset rules. Figure 14This is a flowchart of the Webhook trigger event reception and verification process.

[0029] Code retrieval process: Code repository parameters are configured via the pipeline's `checkout` directive, specifically including: 1) Branch strategy: Dynamically receiving the code branch parameter `branches`, allowing flexible adjustment of the code deployment branch based on the actual scenario. 2) Credential management: The repository address is specified using `userRemoteConfigs`, and access credentials are specified using `credentialsId`. These credentials are stored using an encryption algorithm to prevent plaintext exposure. For the detailed implementation of this pipeline step, please refer to [link to pipeline implementation details]. Figure 7 .

[0030] (2) Code building (metadata injection) The source code is compiled (for Java projects, this means compiling into a deployable JAR file). Since the built-in build variable `BUILD_NUMBER` in the automated deployment tool is unique and can be used to query the code build log, it is used as part of the build artifact version number during the build process. This provides another way to trace back to the code version from the build artifact. The specific implementation of this pipeline step is as follows... Figure 8 As shown: (3) Mirror creation and push This step corresponds to the appendix Figure 3 Image creation and pushing (version number association), and image repository storage.

[0031] This step involves packaging the JAR file into a Docker image, pushing it to a private repository, and cleaning up redundant local images. Before creating the image, the configurable environment variables and exposed ports for the application must be defined in the Dockerfile, as shown in the following example. Figure 9 As shown.

[0032] When creating the image, the image is tagged with the same version number as the JAR file to establish a link between the build artifact and the image. Once creation is complete, it can be pushed to a private image repository. This pipeline step is as follows: Figure 10 As shown.

[0033] (4) Project deployment, including the following steps: a. SSH tunnel establishment: Establish a secure connection with the remote server through the publisherover SSH component of the automated deployment tool, using SSH key pairs (instead of passwords) for authentication to avoid plaintext transmission.

[0034] b. Deployment Script Execution: By calling a pre-installed deployment script on the production server and passing in parameters such as the private repository address and the image information to be deployed, the application can be automatically deployed in the production environment. The deployment script is as follows: Figure 11 As shown, the specific implementation process of the pipeline is as follows: Figure 12 As shown.

[0035] (5) Post-processing, including the following steps: a. Build artifact archiving: Archive all JAR files under the target directory using the archiveArtifacts directive and enable fingerprint tracking (fingerprint: true). Fingerprint data is stored in the global database of the automated deployment tool, recording information such as the MD5 hash value, build number, and parent build number of each JAR file, supporting reverse tracing from the production environment back to the original code commit; b. Environment information output: In the always clause of the post block (executed regardless of whether the build succeeds or fails), key environment information is output, such as... Figure 13 As shown, the meanings of each character are as follows: JOB_NAME: Identifies the business scenario of the pipeline (such as "User Service Deployment" or "Order Service Deployment"). BUILD_URL: Provides the entry point for the build details page, containing key information such as logs and artifact downloads; BUILD_NUMBER: Uniquely identifies this build, used for version rollback or issue localization; WORKSPACE: Locates the local code and artifact storage path, facilitating manual troubleshooting.

[0036] Other examples Figure 2 As shown, a second aspect of the present invention provides a pipelined build system for automated version tagging. The system includes an automated version tagging system, which comprises an automated deployment tool, a code repository, a continuous integration server, and a mirror repository. The pipelined build system includes: The execution module 21 includes: after the automated deployment tool completes information collection and writing according to the custom metadata structure, it executes and submits the code to the code repository; Trigger module 22 includes: after the code repository detects a code commit event through Webhook, it sends a trigger signal to the continuous integration server. The first build module 23 includes: after receiving a trigger signal, the continuous integration server pulls the latest committed code from the code repository and performs a build operation; The second building module 24 includes: after the code build is successful, the continuous integration server builds the application image and pushes it to the specified image repository; Deployment module 25 includes: an automated deployment tool that pulls the corresponding version of the application image from the image repository, starts the application in the target environment, and completes the automated deployment of the project.

[0037] Preferably, the execution module 21 specifically includes: after the metadata definition is completed, collecting the version control information of the target metadata and persisting it as an attribute file; during the packaging stage, converting the data in the attribute file into manifest entries and writing them into the MANIFEST.MF file.

[0038] Preferably, the triggering module 22 specifically includes: sending a Webhook request to the automated deployment tool when a specific event occurs in the code repository; and after receiving and verifying the Webhook request, the automated deployment tool sends a trigger signal to the continuous integration server.

[0039] The construction method provided by this invention defines a metadata structure that can completely record key version control information, including the current code commit version number, the current code commit time, the code branch, the code repository URL, etc. (the version metadata information definition is different for different code version management repositories; the data structure defined in this invention is an abstract data structure). It implements the construction function module process of metadata information collection and injection (collecting version control information and persisting it to an attribute file during the initialization phase, and writing it to MANIFEST.MF during the package phase). At the same time, it designs a complete implementation process of automated pipeline (covering code repository synchronization, project building, image creation and push, remote deployment, and post-processing). It realizes automatic code commit retrieval through a Webhook trigger mechanism, associates the build artifact with the code version by combining the BUILD_NUMBER version number, and uses SSH channel for secure deployment. This invention uses an automatic metadata injection mechanism (automatically collecting and writing version information during the build phase) to solve the version drift problem in traditional tagging methods; it uses a dynamic version number generation and anchoring mechanism to solve the problem of image and source code version disconnect; and it automates the first two steps through a fully automated pipeline build and deployment engine (including a webhook triggering mechanism), achieving efficient rollback and source tracing through pipeline records of each build. Through these methods, the efficiency of associating code version information with build artifacts is improved, manual recording and maintenance costs are reduced, and the reliability and maintainability of automated deployment are enhanced.

[0040] It should be understood that the specific embodiments described above are merely illustrative or explanatory of the principles of the invention and do not constitute a limitation thereof. Therefore, any modifications, equivalent substitutions, improvements, etc., made without departing from the spirit and scope of the invention should be included within the protection scope of the invention. Furthermore, the appended claims are intended to cover all variations and modifications falling within the scope and boundaries of the appended claims, or equivalent forms of such scope and boundaries. Obviously, the above embodiments are merely examples for clear illustration and are not intended to limit the implementation. For those skilled in the art, other variations or modifications can be made based on the above description. It is neither necessary nor possible to exhaustively list all embodiments here. However, obvious variations or modifications derived therefrom are still within the protection scope of this invention. Those skilled in the art should understand that embodiments of the invention can be provided as methods, systems, or computer program products. Therefore, the invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the invention can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps specifying the functions in one or more boxes. Those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it includes the flows of the embodiments of the methods described above. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc. The steps in the methods of the embodiments of the present invention can be adjusted, merged, and deleted according to actual needs. The modules in the system of the embodiments of the present invention can be merged, divided, and deleted according to actual needs.

Claims

1. A pipeline construction method for automated version tagging, characterized in that, The method is based on a version automatic marking system, the system comprises an automatic deployment tool, a code repository, a continuous integration server and an image repository, and the method comprises: After the automatic deployment tool completes information collection and writing according to a customized metadata structure, the automatic deployment tool performs code submission to the code repository; After the code repository detects a code submission event through a Webhook, the code repository sends a trigger signal to the continuous integration server; After the continuous integration server receives the trigger signal, the continuous integration server pulls the latest submitted code from the code repository and performs a building operation; After the code building is completed, the continuous integration server builds an application image and pushes the application image to a specified image repository; The automatic deployment tool pulls the application image of the corresponding version from the image repository, starts the application in a target environment, and completes the automatic deployment of the project.

2. The method of claim 1, wherein, The automatic deployment tool completes information collection and writing according to a customized metadata structure, which comprises: After the metadata definition is completed, the version control information of the target metadata is collected and persisted as an attribute file; In the packaging stage, the data in the attribute file is converted into a manifest entry and written into a MANIFEST.MF file.

3. The method of claim 1, wherein, After the code repository detects a code submission event through a Webhook, the code repository sends a trigger signal to the continuous integration server, which comprises: When a specific event occurs in the code repository, the code repository sends a Webhook request to the automatic deployment tool, After the automatic deployment tool receives and verifies the Webhook request, the automatic deployment tool sends a trigger signal to the continuous integration server.

4. The method of claim 1, wherein, The continuous integration server pulls the latest submitted code from the code repository and performs a building operation, which comprises: According to the code branch, the code parameters are dynamically received; Based on the code parameters, the code is pulled from a specified code repository address, and the specified access credentials are used for authentication.

5. The automated version tagging pipeline build method of claim 1, wherein, The building operation comprises generating a code building log and a code version number based on a build number, wherein the build number is generated by the automatic deployment tool.

6. The automated version tagging pipeline build method of claim 1, wherein, The continuous integration server builds an application image and pushes the application image to a specified image repository, which comprises: Defining configuration parameter variables and exposed ports, and specifying an image tag; Associating the image tag with the code version number, generating an application image, and pushing the application image to the specified image repository through docker push.

7. The automated version tagging pipeline build method of claim 1, wherein, The automatic deployment tool pulls the application image of the corresponding version from the image repository, starts the application in a target environment, and completes the automatic deployment of the project, which comprises: Using the publish over SSH component built in the automatic deployment tool, the SSH key pair is used for authentication and an SSH channel with a remote server is established; Through the SSH channel, the application image of the corresponding version is pulled from the image repository to the remote server, and the built-in deployment script is called, the specified image repository address and application image information parameters are input, and the automatic deployment of the project is completed.

8. A version-automated-tagged pipeline build system, characterized by, The system comprises a version automatic marking system, the automatic marking system comprises an automatic deployment tool, a code repository, a continuous integration server and an image repository, and the pipeline construction system comprises: The execution module comprises: after the automatic deployment tool completes information collection and writing according to a customized metadata structure, the automatic deployment tool performs code submission to the code repository; The triggering module comprises: after the code repository detects a code commit event through a Webhook, a triggering signal is sent to a continuous integration server; The first building module comprises: after the continuous integration server receives the triggering signal, the latest committed code is pulled from the code repository and a building operation is performed; The second building module comprises: after the code building is completed, the continuous integration server builds an application image and pushes it to a designated image repository; The deployment module comprises: an automated deployment tool pulls the application image of the corresponding version from the image repository, starts the application in a target environment, and completes the automated deployment of the project.

9. The automated version tagged pipeline build system of claim 8, wherein, The execution module specifically comprises: After the metadata definition is completed, the version control information of the target metadata is collected and persisted as an attribute file; In the packaging stage, the data in the attribute file data is converted into manifest entries and written into the MANIFEST.MF file.

10. The automated version tagging pipeline building system of claim 9, wherein, The triggering module specifically comprises: When a specific event occurs in the code repository, a Webhook request is sent to the automated deployment tool, After the automated deployment tool receives and verifies the Webhook request, a triggering signal is sent to the continuous integration server.

Images