Weibo by Zhang Keqiang: Zhang Keqiang-agile 307
Article 5 of the 15 new suggestions for source code management mentions that each team should describe code configuration items and non-configuration items. Do not assume that every new team is a code Configuration Manager, be careful when you are a self-righteous newbie. Although it can be deleted, it is a cost to delete it.
The efficient organization Configuration Management Plan also mentions product line-level Configuration Management. What should be the Configuration Management of the product development team? This article attempts to explore.
First, describe the features of the Product Development Team discussed in this article. Product development here refers to the development of a product or product line. The product lifecycle is longer than one year. To improve the product, new requirements are constantly met, the product defects also need to be solved during development. Such product development is different from short-term contract outsourcing projects, and its product development team will undertake the operation and maintenance of this product (line) for a long time, enhance modification, and develop and build. It should be said that most of the current teams belong to such teams.
What are configuration management rules? The configuration management rule may be too academic. To put it bluntly, the core is how to store files and upgrade versions. Rules are the conventions that the team complies. For example, to store meeting minutes in a directory, the file name of the meeting minutes must start with the meeting date in the format of yyyymmdd. Why do we need configuration management rules from the product development team? 1. the development team is composed of multiple people. The rules can be queried by all people. There is a basis for collaboration to provide efficiency. 2. product development is a long-term process and there will be more and more files. Without certain rules, this will cause loss or difficulty in searching files.
Who will formulate the configuration management rules of the team? The team leader is responsible for the long-term information assets of the team, and organizes team members to discuss the configuration management rules of the team. If the team has a role such as configuration administrator, drafting and maintenance of configuration management rules is, of course, the first thing to do is to configure the administrator. What are the configuration management rules of the team? For the software development team, it is obvious that source code management is the key content covered by rules. For source code management, you need to answer the following typical questions: 1. What kind of source code version control tool should you choose? If the organization has been selected or has been selected in history, follow the rules. This is a basic tool that generally does not change frequently, and changes must be carefully considered. Of course, this is often the content of organizational considerations. Therefore, this issue is not a problem for most teams, because there are already selected tools. 2. What kind of trunk branch mode is selected for source code? This is a choice that significantly affects the efficiency of the team. The decision must be made by the team leader. Different trunk branch models are applicable to different scenarios and should be provided by experts in the team, if it is difficult to make decisions within the team, it is also appropriate for the experts in the organization to design the main branch mode of the team. Some organizations even invite industry experts to design the main branch development mode for important product lines, develop rules. 3. What operations should I pay attention to for the selected trunk branch mode? For example, the following question: 3.1 When will the branches be pulled from the trunk? 3.2 under what circumstances will branches be merged to the trunk? 3.3 under what circumstances will the Branch be pulled from the branch? 3.4 under what circumstances will the master be merged into the branch? 3.5 under what circumstances will the branches be merged into the branches? 3.6 under what circumstances will the Branch be deleted? 3.7 If no branch is selected for the trunk, what should I pay attention? Is there any supporting means? 4. What rules should I follow during source code check? How to Write instructions for checking in? Need to be associated with a change, requirement, or defect? Do I need to perform local static code scanning first? Code review first? Or after scanning, or code review5, which areas of the Code are high-level information security code? The access level is relatively high, and the team's peripheral members need to apply for access? How to apply? 6. What areas of code are the core code? Or the code in the red zone, but when the code is modified here, the corresponding test scope needs to be extended and associated with other systems? 7. In order to work collaboratively, how do I set it on the engineer's local computer? The second is the document. There are two types of documents in terms of the survival time: the first is that their lifecycles are the same as those of the product; the second is that their lifecycles are the same as those of specific improvements, transactions, or projects, it is significantly shorter than the product life cycle. The first type of documents can be referred to as product-level documents. For example, team configuration management rules should be product-level documents that deserve long-term compliance and improvement. Typical documents include: 1. Product White Paper, product Introduction 2: product function catalog, usage instructions, system function tree 3, product application architecture, component (system, subsystem, module) structure, component (system, subsystem, module) interface Description 4: product performance architecture, concurrency control, architecture mode for handling high-performance requirements 5. team charter, Team Improvement Suggestions 6. Product to-do list, original requirements
The second type of documents can be referred to as project-level documents, which are the most familiar documents, such as: 1, Project Plan 2, project requirement specification 3, Project Meeting Minutes 4, and project test plan.
For two different types of documents, for team configuration management rules, product-level documents are the focus of processing, because this is a long-term document.
The benefits of the team's configuration management rules are generally described as follows: the team's configuration management rules process product information assets, and of course they are well-developed and implemented. As he said, a good and unified collaborative work platform can improve the efficiency of team collaboration and allow every engineer to work smoothly.
About the configuration management rules of the Product Development Team
