Micro-unit code branch management method based on GitLab and DevOps

Abstract

The invention provides a micro-unit code branch management method based on GitLab and DevOps, and belongs to the field of research and development test management.According to the method, GitLab is adopted for branch management, Dev serves as a trunk for development, function development is conducted through a derived branch MyDev, and after testing, the MyDev is merged to a Release branch, and Tag issuing is conducted. And aiming at an online problem, repairing from a Release branch and printing a new Tag. Meanwhile, in combination with DevOps practice, automatic testing, code review, safety review and automatic packaging deployment are carried out, each large process and link are divided into micro-units, and smooth and efficient automatic implementation of the version control and release process is ensured.

Description

Technical Field

[0001] The present invention relates to the field of R&D test management, and in particular to a micro-unit code branch management method based on GitLab and DevOps. Background Art

[0002] With the continuous evolution of software development practices, the traditional Git Flow model has provided a clear structure and process for version control and project management for a certain period of time, but now it has gradually revealed its limitations in adapting to modern DevOps (development and operation integration) process practices. DevOps emphasizes the close collaboration and automation of development, testing, and operations, and pursues rapid iteration, continuous integration / continuous deployment (CI / CD), and high software quality and reliability.

[0003] The Git Flow model, with its feature branches (such as feature branches, release branches, hotfix branches) and long-term maintenance of the trunk (master / main) and development (develop) branches, provides a good version control strategy for large projects. However, this model is cumbersome and inflexible in the modern DevOps environment that pursues rapid response to market changes, frequent release of small iterations and automated processes. Summary of the invention

[0004] In order to solve the above technical problems, the present invention provides a micro-unit code branch management method based on GitLab and DevOps, which integrates GitLab's code branches into the DEVOPS process, improves the efficiency of development and continuous integration and continuous deployment, ensures software quality and accelerates version iteration, while improving the security of configuration items.

[0005] The technical solution of the present invention is:

[0006] A micro-unit code branch management method based on GitLab and DevOps. It uses GitLab for branch management, takes Dev as the main trunk for development, and develops functions through the derived branch MyDev. After testing, it is merged into the Release branch and tagged for release. For online problems, fix them from the Release branch and add new tags. At the same time, combined with DevOps practice, automated testing, code review, security review and automatic packaging and deployment are carried out, and each large process and link is divided into micro units to ensure the smooth and efficient automation of version control and release processes.

[0007] Furthermore,

[0008] As a core tool for version control, GitLab plays a vital role. First of all, all functional development starts from the main branch Dev. When there is a new functional requirement, developers will derive their own MyDev branches from the Dev branch to implement the function and unit test locally. Once the development is completed and passes the preliminary test, these MyDev branches will be merged back to Dev and then incorporated into the Release branch in preparation for more comprehensive testing and the final version release. If a problem is found during the test, a new MyDev branch will be separated from the current Release branch for bug fixing until the problem is solved and the test is passed, and finally the version release standard is met. At this time, a version tag will be added to the Release branch, such as Tag1.0.0, indicating that the version is officially available, and it will be updated to the Dev branch synchronously to keep the latest status of the trunk.

[0009] A flexible strategy is adopted to handle personalized needs. Once a main version such as Tag1.0.0 is released, a new branch, such as Release1.1.x, will be derived from the Release branch of that version, which is specifically used to develop customized functions for specific customers or scenarios. Developers also create their own MyDev branch from the Release1.1.x branch to develop customized functions. After the function development is completed, after a rigorous testing process and confirmation, a version tag, such as Tag1.1.0, will be added to the Release1.1.x branch, and it will be decided whether to merge it back to the Dev trunk branch based on project requirements.

[0010] In the above process, DevOps practices are deeply integrated to ensure software quality and development efficiency. Before the version label is added, interface automation testing and some performance testing will be performed on the Release branch to ensure the stability and performance of the new function. At the same time, UI interface automation testing will be performed based on the version label to ensure the compatibility and functionality of the user interface. In addition, code review and security review are performed before the function is merged into the Dev branch to ensure code quality and security. At key nodes, such as when a function is merged into the Dev or Release branch, code logic review and status update will also be triggered to ensure that all changes meet expectations. Finally, the automatic packaging and deployment mechanism will automatically start when updating from Dev to the Release branch, achieving seamless upgrades and providing users with a smooth user experience.

[0011] The beneficial effects of the present invention are

[0012] The use of GitLab micro-unit code branch management and a development process that deeply integrates DevOps practices has significantly improved the efficiency and quality of software development. This process effectively avoids code conflicts by developing functions on independent MyDev branches, and combines automated testing, code review, and security audits to ensure high quality and security of the code. At the same time, it promotes knowledge sharing and collaboration among teams, accelerates product iteration, especially rapid response to personalized needs, and enables efficient launch of new versions through automated deployment mechanisms. A clear version control and tag management mechanism not only facilitates project maintenance and knowledge accumulation, but also reduces operation and maintenance costs and risks, ensuring the stability and market competitiveness of the software. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1 It is a schematic diagram of the workflow of the present invention. DETAILED DESCRIPTION

[0014] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

[0015] The present invention discloses a micro-unit code branch management method based on GitLab and DevOps, which aims to reconstruct the Git Flow model to perform GitLab code branch management, combine the DevOps concept, and realize automated testing, code review, security verification and deployment through micro-unitization, so as to ensure efficient and smooth automation of version control and release processes.

[0016] This paper is committed to deeply refactoring the Git Flow model, deeply integrating the best practices of DevOps, and breaking down the huge version control and release process into a series of efficient and collaborative micro-unit tasks through refined automated testing, code review, security audit, and one-click packaging and deployment. This reconstruction aims to ensure that the entire chain from development to deployment is smooth and unimpeded, while significantly improving the level of process automation and ensuring efficiency and smoothness.

[0017] like Figure 1 As shown in the figure, the technical principle is explained by taking 10 people developing the product and packaging and releasing version 1.0.0 as an example. The specific instructions are as follows:

[0018] 1. Pull from Master to the main branch Dev, with Dev as the main branch and Master as the original version.

[0019] 2. R&D develops 10 requirements (i.e. 10 new functions). 10 people simultaneously fork their own branches (MyDev) from Dev and pull them to local for development. Two of them perform local self-testing (unit testing) after development and then modify the bugs. After passing the test, they push them to MyDev.

[0020] 3. MyDev initiates a merge request to the Dev branch, triggering the DevOps process to change the status and conduct code review and code security review. After the review is passed, it is merged to the Dev trunk and the MyDev branch is destroyed. If the review fails, it will return to MyDev for modification.

[0021] 4. Pull Release1.0.x from Dev and submit for testing: If the test passes, wait for other requirements to continue development until all functional points required for a version release are completed, and submit for testing, trigger the DevOps process, automatically package and deploy, and perform interface automation testing and some performance testing.

[0022] 5. If the test fails, send the branch MyDev from Release1.0.x to fix the bug

[0023] 6. After the modification, the DevOps process is triggered to change the status, and code review and code security review are performed. After the review is passed, the code is submitted and Release 1.0.x is updated, the test is submitted, and the MyDev branch is destroyed; if the review fails, MyDev will be returned for modification.

[0024] 7. If the test passes, wait for other requirements to continue development and the remaining R&D to be completed until all the functional points required for a version release are completed and pass the test, tag 1.0.x, trigger the DevOps process to change the status, automatically package and deploy, and perform automated testing of the UI interface.

[0025] 8. After Release1.0.x is tagged 1.0.x, the code is updated to the trunk (Dev), and Release1.0.x is destroyed at the same time.

[0026] Regulations and instructions:

[0027] 1. Regulations: Tags can be added only after all major requirements of a version are completed. If there are 10 requirements in total, 8 of which have been developed and passed the test, and two requirements are under development, and the development of the next stage, version 2.xx, has already started, then the two people will submit the development to Release 1.0.x directly after they are completed, and will not be directly merged into Dev for testing. After passing the test, tags will be added and then merged into Dev.

[0028] 2. Regulations: The tag version is fixed and cannot be modified. When a bug occurs in the online tag 1.0.0, it is pulled from Release (always the latest tag) to my branch (MyDev). After the bug is fixed, it is submitted to Release 1.0.x version for testing. After passing the test, it is tagged 1.0.1 and the code is updated to the Dev trunk.

[0029] 3. Regulations: A new branch Release1.1.x is dispatched from Release1.0.x as the project's personalized demand development. R&D dispatches a new branch Mydev from Release1.1.x for development. After development, it is submitted and merged into Release1.1.x, submitted for testing, and after passing the test, it is tagged with 1.1.0 and it is determined whether it needs to be merged into the Dev trunk.

[0030] 4. Note: The important components of the micro-unit code branch are the Dev overall trunk, the MyDev local branch, and the Release pre-release branch. By integrating the Devops link in the above-mentioned process, multi-version parallel development can be achieved.

[0031] 5. Note: The branch naming convention consists of at least three digits, namely xxx; the first digit represents major version development and iteration, the second digit represents personalized demand development, and the third digit represents defect changes and online hot bug fixes.

[0032] Taking the drone inspection project from initial code development to product version release and online bug hot fix as an example, the use and implementation of this invention method is described:

[0033] 1. Start from the time when the R&D newly developed code is handed over to the configuration administrator to enter the Master branch of the GitLab library, and the R&D management will pull the Dev branch from the Master as the R&D trunk version;

[0034] 2. Nine R&D personnel pull their own branches MyDev (distinguished by the first capital letter of their names) from Dev and pull them to local development. They develop the corresponding requirements assigned to each person. After some R&D personnel complete local development, they perform self-testing (unit testing) and modify bugs. After retesting, they push them to MyDev.

[0035] 3. MyDev initiates a merge request to the Dev branch, triggering the DevOps process to change the status, and conducts code review and code security review. After the review is passed, it is merged to the Dev trunk and the MyDev branch is destroyed. If the review fails, it will return to MyDev for modification;

[0036] 4. After most people's needs have been developed and self-tested, R&D management will pull Release 1.0.0 from Dev and submit it for testing: If the test passes, wait for other needs to continue development until all functional points required for a version release are completed, and submit the test, triggering the DevOps process, automatically packaging and deploying, and performing interface automation testing and some performance testing.

[0037] 5. If the test fails, send the branch MyDev from Release1.0.0 to modify the code for the bug;

[0038] 6. After the modified code is submitted, it will trigger the DevOps process to change the status, and conduct code review and code security review. After the review is passed, the code is submitted and Release 1.0.0 is updated, the test is submitted, and the MyDev branch is destroyed; if the review fails, it will return to MyDev for modification;

[0039] 7. If the test passes, wait for other requirements to continue development and the remaining R&D to be completed until all the functional points required for a version release are completed and pass the test, tag 1.0.0, trigger the DevOps process to change the status, automatically package and deploy, and perform UI interface automated testing;

[0040] 8. After Release 1.0.0 is tagged with 1.0.0, the code is updated to the trunk (Dev), and Release 1.0.0 is destroyed. At the same time, Tag 1.0.0 can be released online. Other trunk requirements continue to be developed and cycle through steps 2-8, and the version number is changed at the same time;

[0041] 9. If a bug occurs in the online version of Tag1.0.0 and needs to be hot-fixed, branch Release1.0.1 is dispatched from Tag1.0.0, and then steps 5-8 are repeated, while the version number is changed.

[0042] The above description is only a preferred embodiment of the present invention, which is only used to illustrate the technical solution of the present invention, and is not used to limit the protection scope of the present invention. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention are included in the protection scope of the present invention.

Claims

1. A micro-unit code branch management method based on GitLab and DevOps, characterized in that: GitLab is used for branch management. Dev is used as the main development branch. Functional development is performed through the derived branch MyDev. After testing, it is merged into the Release branch and tagged for release. For online issues, we fix them from the Release branch and add new tags. At the same time, we combine DevOps practices to perform automated testing, code review, security review, and automatic packaging and deployment, dividing each large process and link into micro units.

2. The method according to claim 1, characterized in that First of all, all functional development starts from the main branch Dev. When there is a new functional requirement, the respective MyDev branch is derived from the Dev branch, and the functional implementation and unit testing are performed locally.

3. The method according to claim 2, characterized in that Once development is complete and passes initial testing, these MyDev branches are merged back into Dev and subsequently incorporated into the Release branch, ready for more comprehensive testing and final release.

4. The method according to claim 3, characterized in that If a problem is found during testing, a new MyDev branch will be separated from the current Release branch to fix the bug until the problem is solved and passes the test, and finally meets the version release standards. At this time, a version label will be added to the Release branch to indicate that the version is officially available, and it will be updated synchronously to the Dev branch to keep the latest status of the trunk.

5. The method according to claim 1, characterized in that To handle personalized needs, once the main version is released, a new branch is derived from the Release branch of that version, which is specifically used to develop customized functions for specific customers or scenarios.

6. The method according to claim 5, characterized in that Create your own MyDev branch from the Release1.1.x branch to develop customized functions; After the function development is completed and confirmed to be correct through the testing process, a version tag will be added to the Release1.1.x branch, and it will be decided whether to merge it back to the Dev trunk branch based on project requirements.

7. The method according to any one of claims 4 to 6, characterized in that: Perform interface automation testing and some performance testing on the Release branch to ensure the stability and performance of new functions; UI interface automation testing is performed based on version tags to ensure the compatibility and functionality of the user interface.

8. The method according to any one of claims 4 to 6, characterized in that: Code review and security review are performed before the function is merged into the Dev branch to ensure code quality and security; At key points, trigger code logic review and status update to ensure that all changes meet expectations.

9. The method according to claim 2, characterized in that: The automatic packaging and deployment mechanism will be automatically started when updating from the Dev branch to the Release branch, achieving seamless upgrades.

Images