New 15 recommendations for source management

Zhang Keqiang author Weibo: Zhang Keqiang-Agile 307

Recommendation 1: Use a good Configuration management tool, also known as the version Control tool, for example GIT,SVN. Please discard VSS completely. Assuming that the new configuration management tool is used, CVS is no longer an option. The configuration management tools and version number control tools can be understood as referring to the same tools.

Recommendation 2: Abandon the ancient configuration management three-library approach, often referred to as the three libraries are the development library (dynamic Library), the controlled Library and product library (static library). This is the product library--the managed library---the development library. In the year when there was no strong version number control tool "Ancient", three-Library approach is the choice to have. And in the modern version number control tool (for example, CVS. Svn. git, etc.), the three-library approach has become outdated.

Recommendation 3: Do not include a version number in the name of the file that is included in the configuration management.

The current configuration management tool has a strong version number control function, and just to add the version number in the file name, it is equivalent to discard the tool version number control function, but only the configuration management tool as a normal storage space, like shared Folders, FTP.

Recommendation 4: You must submit the code yourself. Instead of letting others do it. There are some teams to keep the code base clean. Have a person specifically responsible for reviewing and submitting code.

This is not a good habit.

Source management is not meant to keep the code clean. At least not in the development process. It is designed to allow teams to integrate their work more frequently and to be able to roll back when there is a problem.

Recommendation 5: Without entering the version number library, it does not exist, "the only criterion for the progress of the work is the code into the version number library." Suppose to stick with this article. Find other good habits that will follow.

The task is divided into small pieces so often commit code, more frequent updates. Integration code. Most importantly, the code is often submitted to explain what is being done.

Recommendation 6: Identify code configuration items and non-configuration items.

Examples of non-configuration items are the target folder,. class file,. clashpath,.project,. Sonar, thumbs. Debug folder, and so on. Use the Ignore function to ignore non-configuration items. The code configuration items are complete and can be compiled elsewhere, but without disturbing the working environment elsewhere.

Recommendation 7: Each team should have a description of the code configuration items and non-configuration items, do not assume that each new team is Code Configuration Management talent, beware of self-righteous novice add some self-righteous rubbish. Although it can be deleted, but found to be deleted, it is cost in itself.

Recommendation 8: Dependencies also need to be added to the version number library, or maintain the appropriate libraries, the most important of which is the component library.

At the same time also contains pictures, compile scripts, database scripts, their own initiative test and so on.

Recommendation 9: The overall environment is also able to become a configuration item under cloud computing conditions, the most prominent element in the environment is the underlying data. How efficient it is to have a configuration management environment deployed within 1 minutes when you need to debug and test in a variety of different environments, such as a clean environment, a simulation environment, a point-in-time environment. The test crew loves this!

Recommendation 10: Avoid surface CMMI practices-just manage and maintain a controlled library, present it to the assessment team and respond to various checks. In essence, the project team uses an additional library to carry out its daily work, and copies the mandatory deliverables to the controlled repository only when the inspection is due. This approach satisfies the CMMI assessment. However, there are many other benefits of configuration management that are not actually being played. This is exactly how the ancient three-library scheme is.

Recommendation 11: Learn about the most common multi-branch development.

Multi-branch development is the most classic and often used mode, regardless of whether it is used, you should know how to play the multi-branch: How to pull the branch? What is the drop-down branch? How to merge into the trunk? How do I update from the trunk to the branch? How do I merge to other branches? Under what circumstances do branches are no longer maintained after merging branches? How do merge conflicts work?

Recommendation 12: Guard the backbone + Pioneer Branch, repair defects on the trunk and emergency response, and put the new features on the branch development, on the branch test through the merger to the Guardian Trunk, and then issued a new version.

This applies to scenarios that assume a large number of operational changes. Also most software products belong to such scenarios.

Recommendation 13: Trunk development. There are two cases of trunk development. Scenario 1: The branch development is not yet mastered, only the backbone is developed. Situation 2: After fully mastering the branch development. Active selection of backbone development. The obvious suggestion is to refer to situation 2. High risk of trunk development. Efficiency is also high. Well worth the work of the yards. Achieving high-quality and efficient trunk development is not absolutely difficult. The benefits are absolutely cost-effective.

< Span style= "Color:rgb (51, 51, 51); font-size:14px; line-height:23px; Background-color:rgb (250, 250, 250); " >
/span>

Recommendation 14: Single Branch development. The single branch development is actually not fundamentally different from the backbone development. Need to take all the methods of backbone development, daily work on the branch, the backbone for emergency response. Both require frequent two-way synchronization.

This pattern has the advantage of having both a daemon and a backbone, but the obvious complexity increases.

< Span style= "Color:rgb (51, 51, 51); font-size:14px; line-height:23px; Background-color:rgb (250, 250, 250); " > < Span style= "Color:rgb (51, 51, 51); font-size:14px; line-height:23px; Background-color:rgb (250, 250, 250); " >

Recommendation 15: All configuration items are managed together with the baseline. The main source, document and test code, if not in the same library, then need a special baseline file to describe the corresponding relationship between the same baseline. That's not a suggestion. This is the basic requirement for configuration management. But are often violated.

References Materials

Program Ape Development Weapon: 10 tips for source management

English original Http://java.dzone.com/articles/10-commandments-good-source

Chinese translation rewrite version http://tech.it168.com/a2012/0307/1321/000001321198.shtml

New 15 recommendations for source management