15 new suggestions for source code management

Weibo by Zhang Keqiang: Zhang Keqiang-agile 307

Recommendation 1: Use a good configuration management tool, also known as version control, such as git and SVN. Discard VSS. If you use a new configuration management tool, CVS is no longer an option. The configuration management tool and version control tool can be understood as the same tool.

Recommendation 2: abandon the old three-Database Configuration management practices. The three libraries are usually referred to as development libraries (dynamic libraries), controlled libraries, and product libraries (static libraries ); the practice is to develop the library-> controlled library-> product library. In the ancient times when there was no powerful version control tool, the three-database approach had to be selected. With the support of modern version control tools (such as CVS, SVN, git, and so on, the three databases have become outdated.

Recommendation 3: do not include the version number in the name of the file to be included in configuration management. The current configuration management tool has powerful version control functions. if you add a version number to the file name, it is equivalent to giving up the version control function of the tool, the configuration management tool is just like a shared directory or FTP.

Suggestion 4: You must submit the code yourself, rather than asking others to do the work. Some teams have a dedicated person responsible for reviewing and submitting code to ensure the code library is clean. This is not a good habit. Source code management is not designed to keep the code clean, at least not in the development process. It aims to enable the team to integrate their work more frequently and roll back when there is a problem.

Recommendation 5: The version library does not exist if it is not entered. "The only criterion for working progress is that the Code has entered the version library ". If you stick to this line, you will find that other good habits will follow. The task is divided into small pieces, so code is often submitted, updated more frequently, and the code is integrated. The most important thing is that the Code is often submitted to illustrate what is being done.

Recommendation 6: Identify code configuration items and non-configuration items. Examples of non-configuration items include the target directory,. Class file,. clashpath,. Project,. Sonar, thumbs, and debug folder. The ignore function is used to ignore non-configuration items. The code configuration items must be complete, and the same results can be compiled elsewhere without interfering with the working environment elsewhere.

Recommendation 7: each team should describe code configuration items and non-configuration items. Do not assume that every new team member is a code Configuration Manager. Be careful when you are a self-righteous newbie and add some self-righteous spam. Although it can be deleted, it is a cost to delete it.

Recommendation 8: dependencies must also be added to the version library or the corresponding library must be maintained. The most important thing is the component library. It also includes images, compiling scripts, database scripts, and automated testing.

Recommendation 9: The overall environment can also be a configuration item under cloud computing conditions. The most prominent element in the environment is basic data. When debugging and testing in a variety of environments (such as a clean environment, a simulation environment, or a certain time point environment) are required, the environment for configuration management is deployed within one minute, how efficient it is. Testers love this!

Recommendation 10: Avoid the surface of the CMMS practice-only manage and maintain a controlled database and present it to the evaluation team and handle various checks. In essence, the project team uses another library to carry out daily work, only mandatory deliverables are copied to the controlled database during inspection. This approach satisfies the performance of the cmme evaluation, but does not actually take advantage of configuration management. The old three-database solution is exactly like this.

Recommendation 11: understand the most common multi-branch development. Multi-branch development is the most classic and commonly used mode. Whether it is used or not, you should know how to play with multiple branches: how to pull branches? What is the pull-down branch? How to merge to the trunk? How can I update from the trunk to the branch? How to merge to other branches? Under what circumstances will the branches no longer be maintained after the branches are merged? How can merge conflicts be solved?

Recommendation 12: Daemon trunk + pioneer branch, fix defects and respond to emergencies on the trunk, and place new functions on the branch for development. After the test is passed on the trunk, the new functions are merged to the daemon trunk, release the new version. This method is applicable to scenarios where a large number of O & M modifications are undertaken. This may be the case for most software products.

Recommendation 13: Trunk development. There are two main development cases: Case 1: Master branch development is not mastered, But master development is only available; Case 2: Master branch development and select master development. The obvious suggestion is case 2. The Risk and efficiency of trunk development are high. It is worth the efforts of coders to study and achieve high-quality and efficient trunk development. The benefits are absolutely cost-effective.

Recommendation 14: single branch development. There is no essential difference between single-branch development and trunk development. It requires all trunk development methods, and daily work is carried out on the branches. The trunk is used for emergency response. The two require frequent bidirectional synchronization. This mode has both the advantages of guarding the trunk and developing the trunk, but obviously the complexity is improved.

Recommendation 15: All configuration items are managed along with the baseline. It mainly includes source code, documentation, and test code. If not in the same database, a special baseline file is required to describe the correspondence between the same baseline. This is not a suggestion. This is the basic requirement of configuration management, but is often violated.

References

Programmer development tool: 10 suggestions for source code management

Original http://java.dzone.com/articles/10-commandments-good-source

Simplified http://tech.it168.com/a2012/0307/1321/000001321198.shtml