For the branch-based version, we need to talk about the following diagram, which perfectly illustrates the panorama of the configuration management process. First of all, this diagram is written based on the Git model, but in fact, Git and Subversion have figured out the version control management concept, but Git does make a qualitative leap forward than Subversion in branch management and distributed performance (but this is not the focus of this article).
Before introducing the principle of this graph, let's talk about two different strategies for general version control, one is "pioneer backbone, stable branch", and the other is "stable backbone, pioneer branch". As the name suggests, it is the stable version (production version), on the trunk or on the branch. In the case of traditional project teams using VSS, it is difficult to say which mode it belongs to, mainly because VSS itself does not have a branch management strategy, so many project teams establish two version libraries (or three) respectively, corresponding to the production environment and development environment, of course, this is also a kind of branch management in disguise. However, if you switch to Subversion or Git as a version control tool, most teams use the stable trunk mode, that is, the trunk (truck or master) corresponds to a stable production environment, and tags different releases to indicate the production version. Personally, I think that the stable backbone code pattern should be the absolute mainstream code version control management solution at present. The above picture is the standard "stable backbone" management model.
master: The corresponding Subversion is truck。 Corresponding to the production version, it is tagged once every release.
release branch (also known as integration branch): As long as the production is updated, it needs to be merged into the release branch (integration branch) first. It is somewhat similar to what the project team currently calls the concept of "pre-production" and "simulated environment".
develop branch (dev branch or dev branch): The environment faced by the development environment.
feature branch (feature branch): Some independent functions can be separated from a separate development branch. This is mainly to deal with the fact that some features may take a relatively long time to update, so as not to drag down the release and separate branches.
hotfixes branch (bug fix branch): The bug here is mainly a production bug.
After introducing the trunk and branches, I need to introduce the direction of these branches generation and merging.
master is the production version, and the trunk only accepts two branches for merging, one is the release branch (integration branch) and the other is the hotfixes branch. No other branch can be merged into a production branch.
The release branch is initially created at the same time as production, which is exactly the same as production. He only accepts the dev branch to merge with it. In other words, he does not accept merging directly from the feature branch or the bugfixes branch.
The dev branch, the development branch, like the integration branch, is the same as the production environment at a certain point in time. However, as the development progresses, new features will continue to be created on the dev branch. dev theory only accepts merging of two branches, one is hotfixes and the other is the feature branch.
feature branch, starting at a certain point (version) with the dev branch, the feature branch will eventually merge with the dev branch.
Let's briefly introduce the version control method in the form of a scenario
Suppose a production version is divided into branches (dev, hotfixes, release), and at this time, dev starts to develop a total of ten functions. When 8 of the 10 features were developed, the testing team began to intervene for internal testing, and the configuration administrator deployed the dev branch to the dev environment for testing through continuous integration tools (a separate topic here). When the test verification found that two of the functions were completely unacceptable and needed to be redone, such as simple insurance insurance and claim return, two feature branches were separated from dev, corresponding to simple insurance insurance and claim refund, and on the dev branch, the corresponding code also needed to be rolled back (manual operation here). When the test team finds that there is no problem with the dev branch test, it meets the conditions of UAT, so the configuration administrator merges the dev branch into the release branch, and then uses continuous integration tools to publish this branch to the pre-production environment and hand it over to the user for testing. When the user verification finds a problem, the developer modifies the dev branch, and then merges it into the release branch (here, in the original picture, it is directly modified in the release branch, I think this is not good, I recommend that the developer only face the dev branch), when the verification release verification process suddenly discovers that there is a serious bug in the build environment that needs to be fixed immediately, then it is urgently modified on the hotfixes branch, and it is urgently launched after verifying that it is correct. At the same time, the hotfixes branch is merged with dev (here it is mostly manual, because at this time the production version is already very different from the dev version, and it is often impossible to complete the automatic merge), and then dev is merged into the release. After a period of time, the claim return function may no longer be needed and needs to be canceled, so the claim return feature branch will be deleted. Another feature is easy to insure and has been developed and merged into the dev branch again to go live with the next online version.
The above scenario basically includes routine development, unpacking, emergency updates and other scenarios in the daily development process.
|
Posted on 4/8/2018 10:25:39 AM
|
|
|
|
