Why have it

Why have it? There must be something wrong with our project, so the solution should be agreed according to the actual situation.

First of all, let’s talk about our project. Our project is a system for hospitals to use, including Web, small programs and App…. , this article mainly for our Web and small programs.

Our project is a multi-person collaborative development project, and there are more than ten developers involved. In the development process, we have the following problems.

Background 1: The Dev branch is our development branch, and every developer needs to merge his branch into the dev branch after work every day, and the dev branch has the latest code on it.

Background 2: The development of each business function is jointly developed by several people. Each developer develops in his own personal branch, joins his personal branch to dev branch after work every day, and starts development after pulling dev branch to dev branch at work the next day.

Background 3: Our system is based on configuration, and each hospital may not have the same functions, so we provide different configurations for each hospital, compile and package the system according to the configuration, and finally get a system with different functions. The system used by each hospital is deployed on different servers.

Background 4: The Release branch is our release branch

  • [Question 1]Both business A and business B are under development. Business A has completed development and needs to be handed over for testing. The test environment needs to be released from dev branch. However, the development of B business has not been completed. Even if B business does not affect A business, A business cannot be released online after passing the test, because the system functions are incomplete because B business has not been developed or tested.
    • In addition, dev branch is A development branch, and every day other developers add codes to DEV. Student A’s code does not affect A’s business, but how to ensure that BCDEFG’s code will not affect A’s business
  • 【 Question 2 】If the system is properly upgraded, all hospitals in use need to be upgraded to. ABC Hospital is a long-time user and has been using this system for a long time. Hospital D has just joined. In this case, you need to add configurations for hospital D, including the LOGO of hospital D and the name of hospital D. In addition, Hospital D also put forward some other requirements. We need to add new configuration options to be compatible with the three HOSPITALS ABC. After the configuration was added, we had to test another wave to make sure it met the needs of Hospital D and there were no new bugs. However, there will be a problem. If you modify the configuration in release and cooperate with the test, it will definitely affect the normal release of ABC.
    • [Derived problem] In addition, if there is an urgent bug in the online environment during the test, and urgent repair is needed to go online, the bug repair will be blocked in the release modification.
    • [Derivative problem] In the test process, the new business function test has passed and needs to be released online, but the new node (namely HOSPITAL D) is still being tested, resulting in the accumulation of new functions and unable to be put online normally.

The last scheme is also the management scheme we are using in our project. It is not perfect. If similar problems occur in your project, I hope this scheme can provide some solutions for you.

Background the noun

Node/Node: All nodes or nodes mentioned below refer to customers (hospitals) using this system.

Branch management

  • Release branch: branch that is running online

  • Release_ [node] Branch: [Optional] Node is the node name, and the release branch is used as the base

    • This branch is for new nodes to go online. When a new node needs to go online, the release branch is used as the benchmark to cut this branch, and the node is bug-free and problem-free. After going online, this branch will be merged back to the Release branch, and this branch will be deleted

  • During the launch of this branch, the bug of the Release branch was fixed. Merge the Release branch to the current branch, and never reverse merge

    • During the launch of this branch, a bug was found in the test, which belongs to the bug of other nodes. The bug was modified in the Release branch, and the previous operation was performed after the modification

    • This node has its own functions, for example: the map navigation of node A and node B (A function of the system) is the article, but the map navigation of node C needs to jump to its own address. This modification should be modified in the current branch and compatible with node A and node B at the same time

    • When this node is online and stable, it will be merged back into the Release branch and deleted

    • When this node was merged back to the Release branch, it was found that new functions were added to the Release branch, but this function was not launched on this node this time. The Release branch was first merged to the current node, and after no conflict, this branch was deleted when merged back to the Release branch

    • After merging back to the Release branch, new functions will never come online on the current node. Modify the configuration of this node in the Release branch for compatibility processing (this node has been deleted).

  • Special circumstances: During the launch of this branch, the test found a bug, which belongs to the bug of other nodes and should be merged into the current branch after the release branch is modified. However, new functions are added to the release branch at this time, and the current node is not online, so the bug needs to be modified twice in the release branch and the current branch. (There will be conflicts when merging back into the Release branch, so merge the Release branch into the current branch first, resolve the conflict, merge back into the branch, and then delete the branch)

  • Business branch: The business branch is the newly developed functional branch, which is based on the Release branch

    • [Branch name] : Business name pinyin abbreviation _dev such as online consultation: Yewu_dev

  • Branch of the business development process, will release branch to branch business merger once a day, but definitely not business branch to release branch can be consolidated into (the reason for doing this is to avoid this business finally testing, bug due to other business, found by test, and then give to the business developer, cause waste time; Or the testing of this business is blocked due to a bug in another business; Another reason is that the functionality of the business branch is not yet developed.

    • After the business branch test is completed and the product is accepted, if it needs to go online immediately, it can be merged into the Release branch; if it does not need to go online immediately, it can be merged into the Dev branch; The branch cannot be deleted before the service is online. After the service is online, the branch can be deleted.
    • In the process of service functions waiting to go online, other bugs may be found in the test. In this case, the branch shall be cut and repaired based on Dev. After the repair is completed, the branch shall be merged back to dev
    • If nothing else, the business branch is both a development branch and a testing branch

  • Service Branch _ Test Branch: [Optional] This branch is cut if necessary based on the service branch

    • [Branch name] : Abbreviation of business name pinyin _test, for example, online consultation: Yewu_test

    • Business scenarios 】 【 branch is version 1.0, is testing phase at this time, the product has made a iterative version 1.2 to 1.0, version 1.0 required prior online, version 1.2 can develop gradually, at the moment we cannot directly in business branch development version 1.2, this will be a serious impact on version 1.0, even 1.0 version can’t online. At this point, you need to cut out the 1.0 version branch for testing (the current branch) against the business branch, and then develop the 1.2 version in the business branch (this branch must be cut before the 1.2 development).

    • When testing for a bug in this branch, you need to determine whether the bug exists in version 1.2.

      • If it does not exist, use this branch as the base, cut out a branch to fix the bug, and merge back to this branch after the repair. After the test is accepted, the cut out branch is deleted

        At this time, the reason why the branch is used as the benchmark to cut the branch to fix the bug, rather than the personal business branch to directly fix the bug and merge it is considered that the personal business branch needs to develop the 1.2 version at this time, and the personal business branch has the 1.2 version of the code, so it needs to cut the new branch to fix the bug.

      • If it exists in version 1.2, refer to business Branch and Business branch

  • Service branch and Service branch _ Test branch Bug branch: [Optional] Service branch and service branch _ Test branch This branch is used to correct common bugs. When cutting service branch _ Test branch, the branch is cut based on the service branch.

    • [Branch name] : Service name abbreviation _common_hotfix For example, online consultation: Yewu_common_hotfix

    • Scenario The service branch is 1.2. Business branch _ Test branch is version 1.0.

      The two branches have common underlying parts. At this point, one is under development and the other is under testing. During testing, the test found a bug, which is an underlying bug, in both 1.2 and 1.0.

      If the bug is modified in the business branch _ test branch, it will be merged into the business branch. Some of the bugs in the test branch have been fixed and incorporated into the test branch, but this part of the bug is not possible in 1.2 (this part of the bug scenario condition soil has been removed by the product), direct merging will cause the code to conflict with 1.2, which needs to remove the content. (This part of logic has been completely changed in 1.2, the merger had a serious impact on 1.2 in the past, the minor impact was a lot of redundant code in the product)

      In the same way, merging test branches after changes in business branch version 1.2 will also have an impact on the new logic code of 1.2 and 1.0.

      Based on this, it is recommended to cut the test branch simultaneously. This branch of code is behind both the test and development branches, so merging into the test and development branches is less problematic after fixing common bugs in this branch

      Of course, this branch can be cut or not according to the actual situation. If 1.0 is finished and there are no underlying problems, this branch can not be cut.

      Decide that the underlying code should be changed twice in the business branch and the test branch, or not.

      Use according to the actual situation to decide whether to cut this branch, all in order to facilitate the development of the least bug principle

  • Coupling business test branch: [Optional] Pull based on DEV.

    • [branch name] : common_business_test

    • [Scenario] The three services A, B, and C are coupled and need to be jointly tested. However, our baseline is that all services are combined to the Dev branch after the service branch test, that is, separate test. The coupled service joint test cannot be met.

      At this point, the dev branch can be used as the benchmark to decouple the business test branch. The three services are merged into this branch, and the test is completed, and then the business branch is merged into the Dev branch.

      After the test of A business is completed and the product has been accepted, but the test of B and C business is not completed, A business can also be directly merged into the Dev branch.

      In case of slight coupling, A business is tested, but B business is not completely completed, but the coupling part is not affected. At this time, A and B can be merged into this branch. After the test of A business and the coupling part is completed, the Dev branch can be directly merged (need to know the online time, refer to the instructions of other scenario 2).

      PS: The coupling node test branch is mainly used by the coupled business test, and is eventually merged into the dev branch by the business branch, not by the coupling test branch, so it must be clear

    • Delete the branch test immediately after it is completed. Pull the branch test again next time

    • Bugs that are coupled to the business test branch are modified in the personal branch, merged into the business branch, and then merged from the business branch into this branch. Changes can also be made directly in the business branch and then merged into the coupled business test branch. However, it is forbidden to merge the coupled business test branch directly after the personal branch has been modified

    • The reason why this branch is chosen to base on DEV rather than release is that the risk problem is front-loaded, and the business branch will eventually be merged to dev branch, so it is better to resolve conflicts or other problems in advance than resolve them in the final merger

  • Multi-business common parts (such as common components) development branch: [Optional] This branch is based on the Release branch

    • [Branch name] : common_business_dev

    • When the same component or plug-in is used in multiple business development processes, the release branch can be used as the benchmark to cut this branch to develop the common part of development, and after the development is completed, it can be merged into the business branch needed. (See Other Scenario 1 for more details)

    • This branch is only used for the common part of multi-service development and is deleted after use

    • Is not the branch as part of the entire project public development branch consideration is of use: every day we are not in the development of public section, will only use common parts to use, if the public part of the branch of the whole project, we must maintain this branch, cannot make the branch code far behind, there are maintenance costs.

      If your code is hundreds of versions behind, when you use it again, you need to pull the latest code from release and merge it. Hundreds of versions are bound to have conflicts, and it’s much easier to use a branch than to spend time trying to resolve them

    • This node can also be used as a coupling node test branch. But when we write code, we want each function to do one thing, a single responsibility, so here, we want to use a single principle, each branch to do one thing. So there are two branches that are not too different

  • Dev branch: Dev branch is a branch waiting to be launched. All service function products will be merged into this branch after acceptance

    • If a bug is found in the business that has been merged with this branch, the branch will be cut and fixed based on dev, following Article 4 of the business branch description (below).
    • In the process of service functions waiting to go online, other bugs may be found in the test. In this case, the branch shall be cut and repaired based on Dev. After the repair is completed, the branch shall be merged back to dev
    • For dev to go live, merge dev into the Release branch, configure the release branch, merge dev into master, and then release it to master. (If a pre-release environment is available later, dev will go to release, and the pre-release environment on release will go to Master, and the master branch will release)

  • Personal branch/Personal development branch: Personal branch is suggested to be cut based on business branch,

    • [Branch name] : initials _ business pinyin initials for example: Zhang SAN developed online consultation zs_zxwz

    • If people at the same time to develop multiple business functions, please refer to the branch of the business as A benchmark to build multiple individual branch, branch does not allow an individual to develop multiple business at the same time (, this regulation is to ensure the purity of each branch of the business, otherwise there may be A test of business process, business B code messy unpredictable problem)

    • Personal branches are only allowed to merge with business branches

    • Bugs found during business testing mentioned to specific individuals were merged into business branches after modification in personal branches

    • For bug fixes that are to be launched or have been launched, follow the bug repair instructions of this branch. It is forbidden to merge personal branches into corresponding branches after modification. Absolutely not

  • Master branch: Every time the release branch needs to release, the release branch is merged into the Master branch, and the master branch finally releases the version.

    • The Release branch is online stable code

  • The Tag version:

    • A new node is tagged with release_[node] after being tagged with release_[node]
    • The stable version node goes online, and the release is merged into the master. After the master releases the version, it will Tag with the master

Other scenarios

  1. In the simultaneous development of A, B and C, ABC uses the same common components and the same plug-in and other parts with the same content. How to deal with them?

    Business A, B and C are all under development. For business under development, the code of release branch must be merged every day, indicating that the baseline of business A, B and C is the same.

    To ensure the purity of business A, B, and C, it is not appropriate for the common parts to be developed in either branch and then synchronized to the other two.

    So, in order to ensure the purity, avoid pollution and effects, based on the release branch, draw in another branch, the branch again to develop public parts, components etc, the development is completed, the branch merged into A, B, C three business branches, pull up to the new branch will not have A development of the business, there are only three common content of the business, The business branch also ensures maximum purity when merged into the business branch

    Disadvantages: trouble, join A, B, C three business just need A public plug-in, but need to pull branch introduction first, in merge, trouble

    • Decided to pull the branch, multi-business common part development branch

  2. When A, B, and C services are being developed at the same time, ABC services have partial or low coupling, ABC services can be launched separately, and SERVICE A wants to jump to A page of service B, what should I do?

    B business provides A business with path, input parameters and other content, and A business processes it. At this time, the jump may not be able to pass, but this problem will not occur after the code is synchronized to dev. In the testing process, explanations need to be given to the test (there is already A coupling business test branch to solve the problem).

    The product of business A has been accepted and will be merged into the Dev branch. At this time, the development of business B has not yet been completed. First, we need to know the online time of business A.

    If service B can be merged into the Dev branch after service A comes online, service A can be directly merged into the Dev branch

    If business A is online and business B is not tested and accepted, it cannot be merged into dev branch, the processing of coupling part should be hidden or other processing. After communication with the product, it can be merged into dev branch after business branch processing is completed

  3. The three services A, B and C are under simultaneous development. The three services ABC are seriously coupled and need to be online at the same time. How to deal with this?

    For the three businesses with very high coupling, it is strongly recommended to build a business branch as a business development, which can be handled by personnel multi-point branch management scheme

    It is best to tackle the root cause