Project management based on SVN--centralization and dispersion

We're not going to talk about GIT much better than SVN, nor about Maven and Gradle, based on the existing development environment, and most companies are using SVN + Maven for project management-because this has met most of the code management needs, and for a mature company, The change in project management tools may require a lot of cost and determination, and GIT-based project management will be described in detail later.

The old silver sticks who do program development and project management must know that there are two ways of project development management based on SVN: centralized development and decentralized development, corresponding to normal language description, centralized development is based on trunk development, and decentralized development is based on branches development. The two are not absolutely good or bad, in which way, the choice is entirely based on personal preferences, project structure and company regulations.

Centralized development-trunk-based development

The backbone-based development approach may be a more mainstream development approach, with the main definition of three directories as follows:

Trunk: Development Engineering (non-stable)

Tag: We believe that a stable release package

Branches:bug, requirements Change Branch

Describe the development step in a language: Create a new project in the trunk, At this point, the version number is 1.0.0-snapshot, assign permissions to all developers, all developer features after the development of the code to the trunk, testing based on trunk testing, the trunk is locked-not allow code modification, after testing, tag, At this point, the 1.0.0-release version officially released, the trunk version number changed to 1.1.0-snapshot, unlock the trunk, all developers began to develop 1.1.0-snapshot, if there is no detection of bugs and changes in demand, based on 1.0.0-release tag In the branch 1.0.0-patch, all the relevant developers to 1.0.0-patch maintenance development, while the backbone of the 1.1.0-snapshot is also in sync.

Many people here will ask, how do you merge the code in 1.0.0-patch into 1.1.0-snapshot? Here's a scene to describe it in detail.

Programmer Xiao Zhang is responsible for the development of user Registration module, after the whole project 1.0.0-release release, 1.1.0-snapshot need to upgrade the registration module, at this time ( note that the code is not formally started to write ) , the 1.0.0-release version running on the line found a hidden bug (either a code bug or a business bug), the small Zhang needs to 1.0.0-release this tag to a branch 1.0.0-patch-01 to fix the bug, after the repair, the 1.0 .0-patch-01 merge into the trunk, Build version 1.0.1-snapshot, and then publish to tag, this time tags contain 1.0.0-release and 1.0.1-release two tags, after the new version of 1.1.0-snapshot development -This is the best result.

But the fact is not as people want, we often encounter the situation is 1.1.0-snapshot has been developed for a period of time, at this time found the 1.0.0-relase in the hidden bug, need urgent repair, we also use a scene here to specifically describe.

Programmer Xiao Zhang is responsible for the development of the user Registration module, after the entire project 1.0.0-release release, 1.1.0-snapshot need to upgrade the registration module, at this time ( note that the code has been formally started to write ), The 1.0.0-release version running on the line found a hidden bug (either a code bug or a business bug), the small Zhang needs to 1.0.0-release this tag to a branch 1.0.0-patch-01 to fix the bug, after the repair, will 1.0.0 -patch-01 alone , the next story is more complicated, and Zhang needs to 1.0.0-patch-01 the code in the manual and the 1.1.0-snapshot is developing a merge -- This is a common but unusual result.

Why is the second scenario a common but unusual one that tests the entire PMO management-why is there an emergency bug? Why do I need urgent online? This can cause two of the most immediate problems:

1. The online version is not a release version, but rather a branch patch.

2. It is painful to merge the code in the patch into the code you are developing.

If you encounter such a situation, first can not panic, as far as possible first to solve the problem on the line, and then to consider how to merge the code in the new version of the issue, this will certainly cause 1.1.0 delayed release and 1.0.1 of the missing, serious may need to re-examine-but you can not avoid, But the responsibility is relatively clear.

Of course, in order to avoid this situation as far as possible, it is generally recommended that a new version of the line after a period of time (such as a week) developers pause the development to do a rest, do the project summary, add some documents and other work, Then the 1.1.0 iteration, which not only completes the perfect ending, but also reduces the probability of the occurrence of scenario 2, which is beneficial to the company, the developer and the project management.

Decentralized development--based on the development of branches

Decentralized development is based on the branch branches development, but also I personally prefer a way, its three directories are defined as follows:

Trunk: a stable trunk

Tag: We believe that a stable release package

Branches: Developing slices

Unlike centralized development, our branches is the one where the individual developers are responsible for the slices, while the trunk is always a stable version of snapshot-it's logical, and the snapshot represents a preview instead of "junk", At least the normal operation can be counted as the preview version, while the backbone of the centralized development, although labeled Snapshot Preview version, is actually a "junk"--under normal circumstances you are not able to run, the development environment always has a variety of uncertainties.

Describe the development step in language: Create a new project in trunk trunk, then copy to branches, establish milestone, SP1, sp2...spn respectively, each slice corresponding to a development or front-end or white box test, when everyone's development is complete, submit the code, The project manager merges SP1, SP2, and other slices into the milestone, noting that instead of merging into the trunk, the name of a branch is called the milestone--milestone, which is specifically used to merge the various codes, and after the milestone code is merged, Deploying to a test environment allows the test group to intervene in the test-after it has been merged into the trunk, then released on the trunk, archived and online in the tag, the version number in the trunk is upgraded to the next version, and all the development slices are re-sliced.

If the above description is awkward, you can look at this scenario:

The project manager built a project, Version number is 1.0.0-snapshot, programmer Xiao Wang from the project manager to get a task is to develop the Order Query Center This module, his slice is 1.0.0-snapshot-sp1, after the development of the code, the project manager merged code to milestone, and then Xiao Wang began to develop other code, Project manager in succession from Xiao Zhang, Xiao Li side received SP2, SP3 code, feel can release a version, called on the test to milestone test, and then merge to the backbone to play tag on line, this time the version number is 1.0.0-release, the backbone of the version number is 1.1.0- SNAPSHOT, at this time the project manager re-slicing, everyone's code from 1.0.0-SNAPSHOT-SPN to 1.1.0-SNAPSHOT-SPN for development, milestone also become 1.1.0-snapshot, cyclical ...

There is also the problem of centralized development-what happens to older versions of bugs? We also simulate a scene here.

1.0.0-snapshot passed the test and has already hit tag on the line, The version number on the 1.0.0-release,trunk is the version on the 1.1.0-snapshot,milestone is also 1.1.0-snapshot, all development has claimed the respective 1.1.0-snapshot SP for the next version of the development, at this time 1.0 .0-release a hidden bug that needs urgent repair and online, the project manager found the bug in charge of the king, let him to his responsible 1.0.0-snapshot-spn fix, after the completion of the merger milestone, Test, hit tag online, At this point the online version is 1.1.0-release, and the trunk version becomes 1.1.1-snapshot,milestone the same as 1.1.1-snapshot.

In this, we have a question: because the bug caused by Xiao Wang is a version of the backbone version than the development of the SP version, is there a conflict?

In fact, there is no conflict, the SP version number is actually weakened-in fact, I do not care whether the SP version number is correct, when an incorrect situation occurs, by the individual slices of the developers themselves through the merge Milestone Milestone code solution.

Summarize some of the concepts derived from decentralized development:

SP: Develop slices.

MILESTONE: Milestones, corresponding to the test environment

Trunk: trunk, corresponding to pre-release environment

TAG: archive, corresponding to the online environment

Decentralized development is focused on ensuring the relative stability of the test environment, the absolute stability of the pre-release environment, and the absolute stability of the online environment, and let's imagine: Is it easy to deliver consistently?

Summarize

Centralized development for small-scale projects, such as MicroServices, widgets.

Decentralized development is suitable for fast iterations-better fit for unknown requirements.

Project management based on SVN--centralization and dispersion