CN109522025B - Code issuing system based on git - Google Patents
Code issuing system based on git Download PDFInfo
- Publication number
- CN109522025B CN109522025B CN201811275390.8A CN201811275390A CN109522025B CN 109522025 B CN109522025 B CN 109522025B CN 201811275390 A CN201811275390 A CN 201811275390A CN 109522025 B CN109522025 B CN 109522025B
- Authority
- CN
- China
- Prior art keywords
- work order
- git
- deployment
- warehouse
- operation platform
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
Abstract
The invention provides a code issuing system based on git, which is characterized by comprising a git warehouse, a work order information database, a target machine cluster, a configuration management background and a deployment operation platform. By designing a multi-branch, multi-environment, parallel development and serial release scheme of a gitflow workflow mode based on git version control and an improved version, the problems of mutual interference of multiple requirements, multi-person collaborative development, remote code sharing, missed release, entrained release and the like in a test stage are effectively solved.
Description
Technical Field
The invention relates to the technical field of internet, in particular to a code issuing system based on git.
Background
The existing release system based on the single svn backbone is realized in the following way:
all developers develop on the same backbone of a warehouse, testers test and verify in the same test environment, and finally modified file increments are manually deployed on line.
The main disadvantages of the existing solutions are:
in the testing stage, all requirements conflict with each other and interfere with each other, so that the research and development process is seriously influenced;
in the development and test stage, multi-person cooperative work and code remote sharing cannot be realized;
the problems of missing release and entrained release of files are easy to occur when the system is deployed online.
Therefore, a new release system is continuously developed to solve the problems of mutual interference of multiple requirements, multi-person collaborative development, code remote sharing, release omission, entrainment release and the like in the test stage.
Disclosure of Invention
The technical problem to be solved by the present invention is to overcome the problems existing in the prior art, and to provide a code publishing system based on git.
In order to solve the above problems, the technical solution of the present invention is as follows:
a code release system based on git comprises a git warehouse, a work order information database, a target machine cluster, a configuration management background and a deployment operation platform;
git warehouse: the source code for all items is stored. When a new project is created, a new git repository needs to be created on the gitlab, and the corresponding source code file is uploaded to the repository.
Work order information database: and storing the configuration information of all projects and all work order information under each project. The mysql database is used, and the work order information comprises work order states, a person to be promoted, testers, managers, branch names corresponding to the work orders, a dependent common warehouse, creation time, tag marks after release completion and deployment result logs, and is used by a deployment operation platform and a configuration management background.
Target machine clustering: the system is a collection of dockers and physical machines, and is mainly used as a target machine for allocating a deployment operation platform to a new work order. Target machine clusters are mainly divided into three categories: the system comprises a testing docker, a pre-release machine and a production environment machine, wherein the testing docker is uniformly and randomly distributed to a created work order by a deployment operation platform and is recycled and reused along with the end of the work order; the pre-distribution machine and the production environment machine are relatively fixed and can not be changed under normal conditions.
Configuring a management background: the configuration management background is mainly responsible for managing a series of configuration information of the new project access release system. The method comprises the steps of identifying a new project warehouse by calling an api interface of a gitlab by a configuration management background, storing configuration information after matching projects are successful, and writing the relevant configuration information of the projects into a configuration table in a work order information database by a system.
The deployment operation platform calls the git warehouse, the work order information database and the target machine cluster to complete the functions of all links of the whole life cycle of the work order;
firstly, a deployment operation platform reads a configuration table in a work order information database, shows all configured projects, a developer creates a release work order under one project, the deployment operation platform creates a new feature branch on a warehouse by calling an api interface of a branch creating of a gitlab, and simultaneously randomly acquires a machine from idle machines of a target machine cluster to distribute the machine to the release work order for use, and writes a corresponding machine ip into the work order database;
when a developer clicks a deployment function, a deployment operation platform sends a deployment instruction to a target machine through a paramiko module of python, and after the target machine receives the deployment instruction, the target machine immediately executes the deployment instruction to pull codes of corresponding branches of a corresponding warehouse from a git remote warehouse into a project directory of a local machine through an http protocol to complete deployment operation;
and finally, after the work order is successfully checked and accepted, the deployment operation platform calls a git interface of the gitlab to finish the tag printing operation, meanwhile, the interface returns tag id to the deployment operation platform, and finally the deployment operation platform writes the tag id into the corresponding work order record of the work order database.
Has the advantages that: by designing a multi-branch, multi-environment, parallel development and serial release scheme of a gitflow workflow mode based on git version control and an improved version, the problems of mutual interference of multiple requirements, multi-person collaborative development, remote code sharing, missed release, entrained release and the like in a test stage are effectively solved.
Drawings
The invention is described in detail below with reference to the drawings and the detailed description;
FIG. 1 is a schematic structural diagram of the present invention.
Detailed Description
In order to make the technical means, the creation characteristics, the achievement purposes and the effects of the invention easy to understand, the invention is further explained below by combining the specific drawings.
Abbreviations and Key term definitions
git: the system is an open-source distributed version control system, and can effectively process the version management of the project from a very small project to a very large project at a high speed. git is an open source version control software developed by Linus Torvalds to help manage Linux kernel development.
common warehouse: a technical team pulls out the same logical code that multiple projects commonly use to unify the common warehouse of storage.
feature branch: branches for developers and testers to modify and verify properties.
A develoop branch: and the branch is used for aggregating the line characteristics to be issued.
release branching: a branch for pre-release deployment.
hot fix branch: for emergency repair of a defective branch on the line.
master trunk: a branch for production environment deployment.
MR: merge request, branch merge request.
gitflow: a set of software development workflows built based on the powerful branching capabilities of git was first proposed in 2010 by Vincent Driessen.
And (5) tag printing: when the master backbone is released, the released version node is recorded as a mark, so that the operations of later review, rollback and the like are facilitated.
Referring to fig. 1, the code issuing system based on git designed in this embodiment is composed of five modules, i.e., a git warehouse, a work order information database, a target machine cluster, a configuration management background, and a deployment operation platform.
git warehouse
The git repository is primarily responsible for storing the source code of all items. When a new project is created, a new git repository needs to be created on the gitlab, and the corresponding source code file is uploaded to the repository.
Work order information database
The mysql database is used and mainly responsible for storing the configuration information of all projects and all work order information under each project, including work order states, a pick-up person, a tester, an administrator, branch names corresponding to the work orders, a dependent common warehouse, creation time, tag marks finished in release, deployment result logs and the like, and is used for a deployment operation platform and a configuration management background.
Target machine cluster
The system is a collection of dockers and physical machines, and is mainly used as a target machine for allocating a deployment operation platform to a new work order. Target machine clusters are mainly divided into three categories: the system comprises a testing docker, a pre-release machine and a production environment machine, wherein the testing docker is uniformly and randomly distributed to a created work order by a deployment operation platform and is recycled and reused along with the end of the work order; the pre-distribution machine and the production environment machine are relatively fixed and can not be changed under normal conditions.
Configuration management back-end
The configuration management background is mainly responsible for managing a series of configuration information of the new project access release system, including warehouse url addresses, deployment commands, project dependence, authority distribution and the like, identifies the new project warehouse by calling the api interface of the gitlab, stores the configuration information after the matching of the project is successful, and writes the relevant configuration information of the project into a configuration table in the work order information database by the system.
Deploying an operating platform
The deployment operation platform is the core of the whole system and is responsible for calling a git warehouse, a work order information database and a target machine cluster to complete the functions of all links of the whole life cycle of the work order.
Firstly, a deployment operation platform reads a configuration table in a work order information database, shows all configured projects, a developer creates a release work order under one project, the deployment operation platform creates a new feature branch on a warehouse by calling an api interface of a branch creating field of a gitlab, and simultaneously randomly acquires a machine from idle machines of a target machine cluster to allocate to the release work order, and writes a corresponding machine ip into the work order database.
And then when the developer clicks a deployment function, the deployment operation platform sends a deployment instruction to the target machine through a paramiko module of python (using ssh protocol), and after the target machine receives the deployment instruction, the target machine immediately executes the deployment instruction and pulls codes of corresponding branches of the corresponding warehouse from the git remote warehouse into a project directory of the local machine through an http protocol to complete deployment operation.
And finally, after the work order is successfully checked and accepted, the deployment operation platform calls a git interface of the gitlab to finish the tag printing operation, meanwhile, the interface returns tag id to the deployment operation platform, and finally the deployment operation platform writes the tag id into the corresponding work order record of the work order database.
Referring to FIG. 2, the branching model of the project warehouse, git warehouse and its branch management description:
the git warehouse may be M item warehouses + N common warehouses (M ═ 1,2,3 …; N ═ 0,1,2,3 …). The warehouses all follow the branch mode of gitflow and comprise two resident protection branches of master and develop and three temporary branches of feature, release and hotfix.
Where the branch model of the project warehouse and the branch model of the common warehouse have some differences. Cutting a develoop branch of the project warehouse from a master trunk; each feature branch is cut out from the develop branch, and finally merged back to the develop branch and destroyed; cutting a release branch from the develoop branch, and finally merging the release branch and the master trunk and destroying the release branch and the master trunk; and (4) cutting out the hotsfix from the master, finally merging the hotsfix into a devielop branch and a master trunk and destroying the hotsfix, wherein the feature, the release and the master are respectively used for deployment in a test environment, a pre-release environment and a production environment.
Referring to fig. 3, a branch model of a common warehouse, since the common warehouse is depended on by multiple items at the same time, in order to isolate a release risk that may be brought when each item depends on the common warehouse and to facilitate parallel deployment of multiple items, a branch of the common warehouse is adjusted: there is a master backbone, a plurality of xx _ master, xx _ devildoop, xx _ hot, xx _ release, xx _ feature branch (wherein xx is the alias of each item), wherein xx _ feature, xx _ release, xx _ master are used for test environment, pre-release environment, production environment deployment.
Description of deployment operation platform flow and operation method
The deployment operation platform is mainly used by developers, testers and managers, and mainly completes the automatic management of branches of each link in the gitflow workflow (including the creation, combination and destruction of the branches, the creation of an MR and the publishing of tag), the authority control of each role, the deployment and rollback of each phase code, the torsion of the state of a work order, the checking of the work order and other tasks. There are four environments in the development process: the development environment is freely processed by developers and is not included in a deployment operation platform, and detailed flows of a test stage, a pre-release stage and a production environment stage are mainly described herein. The operation flow of the test environment refers to fig. 4, the operation flow of the pre-release stage refers to fig. 5, the operation flow of the production environment stage refers to fig. 6, and the emergency repair flow of the current network problem refers to fig. 7.
The following is a core page for deploying the operation platform, the above processes are all embodied on the operation button of the work order list page (as in fig. 8) and the button of the deployment page (as in fig. 9), and three roles of the developer, the tester and the administrator have different permissions at each stage respectively.
The configuration management background mainly has the functions of accessing a new project for the deployment operation platform, configuring corresponding project managers, developers and testers for the new project, configuring corresponding project dependence, configuring branch name rules, configuring project classification, configuring project deployment target nodes, configuring deployment paths, deployment commands and the like. The project configuration home page is shown in fig. 10 and the deployment target node configuration is shown in fig. 11.
So far, the access projects of the release system are 108, the deployment tasks of 12939 release work orders are completed smoothly, and after an accident 0 is deployed on a work order line, the research and development efficiency and the research and development quality are greatly improved, and the risks of release missing and release carried by the release are effectively avoided.
The foregoing shows and describes the general principles, essential features, and advantages of the invention. It will be understood by those skilled in the art that the present invention is not limited to the embodiments described above, which are given by way of illustration of the principles of the present invention, and that various changes and modifications may be made without departing from the spirit and scope of the invention as defined by the appended claims. The scope of the invention patent claims is defined by the appended claims and their equivalents.
Claims (5)
1. A code release system based on git is characterized by comprising a git warehouse, a work order information database, a target machine cluster, a configuration management background and a deployment operation platform;
git warehouse: storing source codes of all items; when a new project is created, a new git warehouse is created on the gitlab, and a corresponding source code file is uploaded to the warehouse;
work order information database: storing configuration information of all projects and all work order information under each project;
target machine clustering: the system is a collection of a batch of dockers and physical machines, and is used as a target machine for allocating an operating platform to a new work order for use;
configuring a management background: the configuration management background is mainly responsible for managing a series of configuration information of the new project access release system;
the deployment operation platform calls the git warehouse, the work order information database and the target machine cluster to complete the functions of all links of the whole life cycle of the work order; the specific process is as follows:
firstly, a deployment operation platform reads a configuration table in a work order information database, shows all configured projects, a developer creates a release work order under one project, the deployment operation platform creates a new feature branch on a warehouse by calling an api interface of a branch creating of a gitlab, and simultaneously randomly acquires a machine from idle machines of a target machine cluster to distribute the machine to the release work order for use, and writes a corresponding machine ip into the work order database;
when a developer clicks a deployment function, a deployment operation platform sends a deployment instruction to a target machine through a paramiko module of python, and after the target machine receives the deployment instruction, the target machine immediately executes the deployment instruction to pull codes of corresponding branches of a corresponding warehouse from a git remote warehouse into a project directory of a local machine through an http protocol to complete deployment operation;
and finally, after the work order is successfully checked and accepted, the deployment operation platform calls a git interface of the gitlab to finish the tag printing operation, meanwhile, the interface returns tag id to the deployment operation platform, and finally the deployment operation platform writes the tag id into the corresponding work order record of the work order database.
2. The git-based code release system as claimed in claim 1, wherein the work order information database uses mysql database, and the work order information includes work order status, pick-up person, tester, manager, branch name corresponding to the work order, dependent common warehouse, creation time, tag mark of release completion, and deployment result log for deployment operation platform and configuration management background.
3. A git-based code distribution system as claimed in claim 1 wherein said target machine cluster comprises: testing a docker, a pre-release machine and a production environment machine; and the testing docker is uniformly and randomly distributed to the created work order by the deployment operation platform, and is recycled and reused along with the end of the work order.
4. The git-based code release system of claim 1, wherein the configuration manages the management of background information, including warehouse url addresses, deployment commands, project dependencies and rights assignment; and the configuration management background identifies a new project warehouse by calling the api interface of the gitlab, saves the configuration information after the project matching is successful, and writes the relevant configuration information of the project into a configuration table in the work order information database by the system.
5. A git-based code distribution system as claimed in claim 1, wherein said git repository is M item repository plus N common repository.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811275390.8A CN109522025B (en) | 2018-10-30 | 2018-10-30 | Code issuing system based on git |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811275390.8A CN109522025B (en) | 2018-10-30 | 2018-10-30 | Code issuing system based on git |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109522025A CN109522025A (en) | 2019-03-26 |
| CN109522025B true CN109522025B (en) | 2021-07-20 |
Family
ID=65774180
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811275390.8A Active CN109522025B (en) | 2018-10-30 | 2018-10-30 | Code issuing system based on git |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109522025B (en) |
Families Citing this family (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110134431A (en) * | 2019-04-16 | 2019-08-16 | 深圳壹账通智能科技有限公司 | Code data management method and system |
| CN110187914B (en) * | 2019-05-23 | 2023-05-26 | 杭州火小二科技有限公司 | Application development method, system and device |
| CN110489158B (en) * | 2019-08-01 | 2023-05-05 | 北京字节跳动网络技术有限公司 | Method, device, medium and electronic equipment for optimizing code hosting platform |
| CN110598450A (en) * | 2019-09-19 | 2019-12-20 | 海明联合能源集团矩网科技有限公司 | System and method for bottom layer locking |
| CN113127027A (en) * | 2019-12-31 | 2021-07-16 | 深圳云天励飞技术有限公司 | Version updating method and device based on distributed version control system |
| CN111399856A (en) * | 2020-03-11 | 2020-07-10 | 山东汇贸电子口岸有限公司 | File configuration editing method and system in service deployment |
| CN111352651B (en) * | 2020-03-31 | 2023-03-31 | 中国建设银行股份有限公司 | Code branch management method and device |
| CN111666081B (en) * | 2020-04-30 | 2024-04-05 | 平安科技（深圳）有限公司 | Git-based project version release method, device, equipment and medium |
| CN111338784B (en) * | 2020-05-25 | 2020-12-22 | 南栖仙策(南京)科技有限公司 | Method and system for realizing integration of code warehouse and computing service |
| CN111625221B (en) * | 2020-05-26 | 2023-09-29 | 艾普阳科技（深圳）有限公司 | Version control method, device, equipment and medium applied to integrated development environment |
| CN111694599A (en) * | 2020-06-11 | 2020-09-22 | 北京首汽智行科技有限公司 | Product publishing method |
| CN112015465A (en) * | 2020-09-03 | 2020-12-01 | 中国平安财产保险股份有限公司 | Project engineering configuration publishing method and device, computer equipment and storage medium |
| CN111930423B (en) * | 2020-09-17 | 2021-08-24 | 四川新网银行股份有限公司 | Method for tracing software release version based on microservice |
| CN112379918B (en) * | 2020-12-04 | 2024-04-19 | 北京顺达同行科技有限公司 | Code issuing method, device, computer equipment and storage medium |
| CN112633856A (en) * | 2020-12-31 | 2021-04-09 | 中国农业银行股份有限公司 | Data processing method and device based on work items |
| CN113312040B (en) * | 2021-06-15 | 2022-09-27 | 浪潮云信息技术股份公司 | Method for realizing application release of low-code development platform and storage medium |
| CN114168213A (en) * | 2021-10-26 | 2022-03-11 | 青岛海尔科技有限公司 | Software release method and device based on Jenkins and electronic equipment |
| CN114416109B (en) * | 2021-12-15 | 2023-01-10 | 广州市玄武无线科技股份有限公司 | Program deployment method and device, computer device, and storage medium |
| CN115291929B (en) * | 2022-07-05 | 2023-04-11 | 华南师范大学 | Programming block management system for artificial intelligence education graphical programming software |
| CN115185561A (en) * | 2022-07-20 | 2022-10-14 | 杭州雷数科技有限公司 | CICD system based on service Jenkins and implementation method |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105094851A (en) * | 2015-09-06 | 2015-11-25 | 浪潮软件股份有限公司 | Method for momentarily issuing codes based on Git |
| CN106997297A (en) * | 2017-03-31 | 2017-08-01 | 广东亿迅科技有限公司 | A kind of software development management platform and method based on DevOps |
| CN107465548A (en) * | 2017-08-17 | 2017-12-12 | 北京云纵信息技术有限公司 | The dispositions method and device of code |
| CN107678773A (en) * | 2017-09-28 | 2018-02-09 | 郑州云海信息技术有限公司 | A kind of code development based on git and testing process management method |
| CN108415694A (en) * | 2018-02-28 | 2018-08-17 | 山东汇贸电子口岸有限公司 | A kind of Android agile development system and methods based on GitFlow workflows |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE10050546B4 (en) * | 2000-10-12 | 2008-07-24 | Rohde & Schwarz Gmbh & Co. Kg | Method of distributing a meter firmware program code to multiple meters |
-
2018
- 2018-10-30 CN CN201811275390.8A patent/CN109522025B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105094851A (en) * | 2015-09-06 | 2015-11-25 | 浪潮软件股份有限公司 | Method for momentarily issuing codes based on Git |
| CN106997297A (en) * | 2017-03-31 | 2017-08-01 | 广东亿迅科技有限公司 | A kind of software development management platform and method based on DevOps |
| CN107465548A (en) * | 2017-08-17 | 2017-12-12 | 北京云纵信息技术有限公司 | The dispositions method and device of code |
| CN107678773A (en) * | 2017-09-28 | 2018-02-09 | 郑州云海信息技术有限公司 | A kind of code development based on git and testing process management method |
| CN108415694A (en) * | 2018-02-28 | 2018-08-17 | 山东汇贸电子口岸有限公司 | A kind of Android agile development system and methods based on GitFlow workflows |
Non-Patent Citations (1)
| Title |
|---|
| 云及高性能计算集群环境中配置管理系统设计;赵春燕等;《计算技术与自动化》;20160331;第35卷(第1期);第111-116页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109522025A (en) | 2019-03-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109522025B (en) | Code issuing system based on git | |
| CN111352651B (en) | Code branch management method and device | |
| US8112742B2 (en) | Method and system for debugging data integration applications with reusable synthetic data values | |
| CN106708740B (en) | Script testing method and device | |
| US8745589B2 (en) | Automatic extraction of test case for a build in testing lifecycle | |
| CN107315689A (en) | The Automation regression testing method of granularity is retrieved based on Git code files | |
| US7917344B2 (en) | Enterprise multi-program process development and integration process | |
| CN101932999A (en) | Automated methods and systems for developing and deploying projects in parallel | |
| US11055078B2 (en) | Systems and methods for deploying software products to environments | |
| EP2610762A1 (en) | Database version management system | |
| CN108776643B (en) | Target code merging control method and system based on version control process | |
| US9639350B2 (en) | Tagging non-upstream source code | |
| US20100121668A1 (en) | Automated compliance checking for process instance migration | |
| WO2017083206A1 (en) | Recency-based identification of area paths for target components | |
| CN101673374A (en) | Bill processing method and device | |
| CN113094066A (en) | Multi-server code publishing method and system | |
| CN110865806A (en) | Code processing method, device, server and storage medium | |
| US9354769B1 (en) | Electronically controlling commitment of a change to stored information | |
| Łuczak et al. | The process of creating web applications in ruby on rails | |
| CN116400950A (en) | DevOps element pipeline system based on version control | |
| CN111090420A (en) | Task function line-based software project management method and system | |
| US9141650B1 (en) | Methods and systems for filtering tree node data to determine part and assembly relationships | |
| Mitchell et al. | SQL Server Integration Services Design Patterns | |
| CN117112011A (en) | Version management method and device | |
| Hüttermann | Automatic Releasing |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |