A version risk management control method, system and storage medium based on Git

Abstract

The present invention discloses a version risk management and control system based on Git, comprising: a Git command encapsulation module, used for encapsulating and assembling Git native commands for use by business modules; a business module, used for assembling and merging code full-process information and collecting information returned during the execution process; a configuration module, used for saving parameter configuration and providing a query interface for other modules to avoid encoding sensitive account information into logic layer codes; a deployment module, used for pulling codes from a Git repository and deploying them on docker; a log module, used for unifying the log printing format during system operation; an email module, used for sending emails to notify users of operation results; and an extension module, used for extending the check of whether there are submissions that have been missed by merging in the code.

Description

Technical Field

[0001] The present invention belongs to the field of Internet technology and relates to a version risk management control method, system and storage medium based on Git. Background Art

[0002] Git is an open source distributed version control system used to handle any small or large project in an agile and efficient manner. Its main functions include centralized management of code archives, providing locking to avoid conflicts between submissions by different users, and comparison of different versions of source code.

[0003] However, as a general version control tool, although Git provides solutions to many version problems, due to its universality, it is difficult to fully match and integrate with developers' continuous build systems. Summary of the invention

[0004] The purpose of the present invention is to provide a version risk management control method, system and storage medium based on Git, which has the characteristics of avoiding high-risk operations such as code conflicts and forced merging that may occur when developers merge codes, and improving the quality of code management.

[0005] The technical solution adopted by the present invention is a version risk management control system based on Git, comprising:

[0006] Git command encapsulation module, used to encapsulate and assemble Git native commands for use by business modules;

[0007] Business module, used to assemble and merge the whole process information of the code and collect the information returned during the execution process;

[0008] Configuration module, used to save parameter configuration and provide query interface for other modules, to avoid encoding sensitive account information into logic layer code;

[0009] Deployment module, used to pull code from the Git repository and deploy it on Docker;

[0010] Log module, used to unify the log printing format during system operation;

[0011] Mail module, used to send emails to notify users of the running results;

[0012] Extension modules are used to extend other functions by referencing mature interfaces.

[0013] The present invention is also characterized in that:

[0014] A version risk management control method based on Git is implemented in the following steps:

[0015] Step 1: The developer initiates the code merging process, which is executed by the business module and the Git command encapsulation module: This risk management control system automatically clones the working cache path from Git for subsequent execution of the inspection logic;

[0016] Step 2: The detection process is performed by the business module and the configuration module: enter the development branch and the trunk respectively, obtain the latest commit record list of each, and filter out the commit records generated by merging codes and not actually submitted by controlling the --no-merge parameter of the git log command in Git;

[0017] Step 3: Compare the latest commit records of the development branch with those of the trunk to check whether the development branch contains all the commit records of the trunk, otherwise the operation will be interrupted;

[0018] Step 4: If the test passes, the merging process is carried out: merge the code on the development branch into the trunk, and collect relevant information such as project name, development branch name, success or failure, target deployment environment, etc. for use in subsequent processes;

[0019] Step 5. If the merge is successful, the deployment module will deploy it: remotely call the build process in Jenkins, automatically package and deploy the project into the docker image, and start it as a container, otherwise an error message will be returned;

[0020] Step 6: Embed the version risk management control system into the continuous integration tool Jenkins to provide batch operation features and graphical startup convenience.

[0021] The input and output in steps 1-6 are processed by the version risk management control system, and all sensitive information is blocked from printing.

[0022] The permission account is configured through the configuration file. The configuration file is stored in the Linux server and only specific accounts are given read permissions to ensure that it is not tampered with, minimizing the risk of leakage.

[0023] A computer-readable storage medium includes computer-executable instructions that, when executed by a computer system, execute a Git-based version risk management control method.

[0024] The beneficial effects of the present invention are:

[0025] By encapsulating Git native commands for code management, it provides integrated batch processing, conflict detection, automatic merging, and user notification tools to improve the accuracy and convenience of code management for developers, and reduces the learning cost by providing a graphical interface entry. By encapsulating a series of operations for merging codes through Python, the scattered operations are combined into a unified entry and process, shielding the input and output of sensitive information, and improving convenience and concealment. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 It is a flow chart of the system of the present invention;

[0027] Figure 2 It is the module relationship principle diagram of the present invention. DETAILED DESCRIPTION

[0028] The present invention is described in detail below with reference to the accompanying drawings and specific embodiments.

[0029] A Git-based version risk management control system, including:

[0030] Git command encapsulation module, used to encapsulate and assemble Git native commands for use by business modules;

[0031] Business module, used to assemble and merge the whole process information of the code and collect the information returned during the execution process;

[0032] Configuration module, used to save parameter configuration and provide query interface for other modules, to avoid encoding sensitive account information into logic layer code;

[0033] Deployment module, used to pull code from the Git repository and deploy it on Docker;

[0034] Log module, used to unify the log printing format during system operation;

[0035] Mail module, used to send emails to notify users of the running results;

[0036] Extension modules are used to extend other functions by referencing mature interfaces.

[0037] A version risk management control method based on Git is implemented in the following steps:

[0038] Step 1: The developer initiates the code merging process, which is executed by the business module and the Git command encapsulation module: This risk management control system automatically clones the working cache path from Git for subsequent execution of the inspection logic;

[0039] Step 2: The detection process is performed by the business module and the configuration module: enter the development branch and the trunk respectively, obtain the latest commit record list of each, and filter out the commit records generated by merging codes and not actually submitted by controlling the --no-merge parameter of the git log command in Git;

[0040] Step 3: Compare the latest commit records of the development branch with those of the trunk to check whether the development branch contains all the commit records of the trunk, otherwise the operation will be interrupted;

[0041] Step 4: If the test passes, the merging process is carried out: merge the code on the development branch into the trunk, and collect relevant information such as project name, development branch name, success or failure, target deployment environment, etc. for use in subsequent processes;

[0042] Step 5. If the merge is successful, the deployment module will deploy it: remotely call the build process in Jenkins, automatically package and deploy the project into the docker image, and start it as a container, otherwise an error message will be returned;

[0043] Step 6: Embed the version risk management control system into the continuous integration tool Jenkins to provide batch operation features and graphical startup convenience.

[0044] The input and output in steps 1-6 are processed by the version risk management control system, and all sensitive information is blocked from printing.

[0045] The permission account is configured through the configuration file. The configuration file is stored in the Linux server and only specific accounts are given read permissions to ensure that it is not tampered with, minimizing the risk of leakage.

[0046] A computer-readable storage medium includes computer-executable instructions that, when executed by a computer system, execute a Git-based version risk management control method.

[0047] Example

[0048] Configuration server: one or more Linux servers;

[0049] Deploy related environments on the Linux server: Git, Jenkins, Python, mailbox, etc. If multiple servers are configured, it is also necessary to ensure that the servers have mutual access rights;

[0050] Install the Python dependency libraries used in the version risk management control system;

[0051] Copy the overall code of the version risk management control system to the script directory of Jenkins and configure access permissions;

[0052] Modify the configuration files in the version risk management control system, mainly involving the configuration of required permissions such as Git account password, server account password, email account password, Jenkins account password, etc.

[0053] Configure graphical and parameterized interface entrances in Jenkins to direct the execution process to the external call interface of the version risk management control system;

[0054] After the above steps are completed, the developer or tester will initiate the code merging process from Jenkins to automatically detect and execute the process of merging code - building project - deploying project.

[0055] The present invention integrates the Git merging principle and Python's re-packaging of native commands, so that the originally fragmented version management work that requires separate manual operations for each step is unified into the continuous integration devops system, which has certain information security protection and improves the work efficiency of developers and testers.

Claims

1. A Git-based version risk management control system, characterized by: include: Git command encapsulation module, used to encapsulate and assemble Git native commands for use by business modules; Business module, which processes and determines whether the development branch contains all the submissions of the trunk, is used to assemble and merge the full process information of the code and collect the information returned during the execution process; Configuration module, used to save parameter configuration and provide query interface for other modules, to avoid encoding sensitive account information into logic layer code; Deployment module, used to pull code from the Git repository and deploy it on Docker; Log module, used to unify the log format printing during system operation; Mail module, used to send emails to notify users of the running results; Extension modules are used to reference mature interfaces to extend other functions; The Git-based version risk management control system performs a Git-based version risk management control method according to the following steps: Step 1: The developer initiates the code merging process, which is executed by the business module and the Git command encapsulation module: This risk management control system automatically clones the working cache path from Git for subsequent execution of the inspection logic; Step 2: The detection process is performed by the business module and the configuration module: enter the development branch and the trunk respectively, obtain the latest commit record list of each, and filter out the commit records generated by merging codes and not actually submitted by controlling the --no-merge parameter of the git log command in Git; Step 3: Compare the latest commit records of the development branch with those of the trunk to check whether the development branch contains all the commit records of the trunk, otherwise the operation will be interrupted; Step 4: If the test passes, the merging process is carried out: merge the code on the development branch into the trunk, and collect the project name, development branch name, success or failure, and target deployment environment information for use in subsequent processes; Step 5. If the merge is successful, the deployment module will deploy it: remotely call the build process in Jenkins, automatically package and deploy the project into the docker image, and start it as a container, otherwise an error message will be returned; Step 6: embed the version risk management control system into the continuous integration tool Jenkins to provide batch operation features and graphical startup convenience; the input and output in steps 1-6 are processed by the version risk management control system, and all sensitive information printing is blocked externally; The permission account is configured through a configuration file, which is stored in a Linux server and only gives read permission to a preset account.

2. A computer-readable storage medium, characterized in that: The invention comprises computer executable instructions which, when executed by a computer system, perform the method according to claim 1.

Images