Preface With the increasing scale of software projects and the increasing complexity of projects, the importance of Software Configuration Management (SCM) has been increasingly recognized by everyone. Many excellent software configuration management tools have also emerged, allowing us to easily and effectively manage our software projects, as one of them, microsoft Visual sourcesafe is easy to use, convenient and efficient, and highly integrated with Windows operating systems and Microsoft development tools. Today, let's talk about permission management in VSS. First, I will explain the principle of implementing the permission mechanism in VSS. Here I design the default security access mechanism of VSS, project security, and so on. Then I will tell you how to implement the permission mechanism, finally, I will talk about how to apply permission management to a project based on the specific circumstances of a software handover project. 1. default access control for VSS After you install VSS, the system automatically activates the default security access control mechanism. This mechanism is very simple. It includes two levels of permissions: 1) read-only permission: You can view all objects in the VSS database, but cannot modify them. 2) read and write permissions: users can view and modify any objects in the VSS database. Each time you add a new user, you can determine the permission level of the user. The "Add User" dialog box contains a "Read Only" check box, through which you can determine the permissions of users. As we mentioned earlier, this is an extremely simple and crude solution, but it is also the simplest. In the actual process, you may need more detailed permission assignment, and even want each file to be able to set different permissions for different users. Then we have to set up the security mechanism of our project. Note: All security settings in sourcesafe are performed in visual sourcesafe administrator. Therefore, before going into the following details, you must confirm that your admin password is secure, no one except you can access visual sourcesafe administrator as you like. Otherwise, all security considerations will be futile. 2. Project security and User Access Permissions Before explaining project security, let's first review the basic composition framework of VSS. vss contains multiple databases, and each database contains many projects, in addition, different sub-projects may be nested in the project, and finally your source files. You can compare this to the disk partitions, directories, subdirectories, files in the operating system. Each machine contains many disk partitions, and each partition contains countless directories and subdirectories, it is your file in the subdirectory. The user in VSS is based on the VSS database, that is, each database contains its own user list. User access permission refers to the items in the database that the user can access (including viewing, modifying, and executing commands). For a project, it can only be accessed by authorized users, that is, project security. Unfortunately, VSS only provides user permission Control for projects (corresponding to directories, different user access permissions cannot be set for each file (such as rational clearcase ). Although you can use some work und to do this, such as adding sub-projects, it damages the standardization, readability, and rationality of the entire project structure, it even generates sub-projects with no significance. VSS defines level-4 User Access Permissions, from low to high. The latter includes all the permissions of the former. For example, if you have the check out permission, the latter automatically has the read permission. 1) read-only (R): allows you to view files, corresponding to view, get, and other commands 2) Check out (c): You can use the check out, check in, undo check out and other commands to modify the file content. 3) file addition/deletion (a): You can add, delete, or rename a file in a project or add a label to the file. The corresponding Commands include add, delete, label, rename, etc. 4) Destruction (d): this level of permission corresponds to those operations that are very destructive (that is, those operations that may be fired accidentally). Please remember their names: Destroy, purge, rollback. So some people call it the suicide permission. In fact, you can find that the two-level permissions in the default security mechanism correspond to the four, but the latter divides the read and write permissions of the former into three different levels. Well, after understanding the meaning of each level of permissions, we can start to set permissions for different users. Before setting user permissions, you must activate the project security mechanism. Open the Tools menu of VSS administrator, click Options to get the sourcesafe Options dialog box, select project security and check the ENABLE Project security check box. (As shown in) Figure 1 activating the Project Security Mechanism There are three methods in VSS to set project access permissions for users: Set permissions for each user for projects, Set permissions for accessing each project for users, and copy user permissions, they correspond to assign rights by project, rights assignments for user, and copy user rights under the Tools menu respectively. Let's take the method as an example. As shown in, select a project in the Left box, select a user in the upper right box, and display the current permissions of the user in the lower right corner, select different check boxes to set your own permissions. Note: The user permission settings for each project are automatically reflected in all sub-projects of the project. Figure 2 user authorization Iii. Application of permission management in actual projects In this section, I will talk about the practical application of permission management based on my experience as a configuration administrator in the actual project process and the factors that need to be considered during the application process. The project we want to contact is a software handover project. The composition and responsibilities of this project team are as follows: Project Manager: one person responsible for coordinating the entire project
Business Analyst, one person in charge of the entire system business
System Architect: one person responsible for the system architecture of the entire system
Package owner: three persons, responsible for the front-end, middle-layer, and back-end database of the system.
Module owner: 3-5 persons, responsible for each module
Database Administrator (DBA): 1 person in charge of System databases
Test/QA: one person responsible for testing and quality assurance of the entire software
Technical writer: 1 person, responsible for writing related technical documents
Change Control Board (CCB): three persons responsible for reviewing and executing changes to project requirements, including software configuration administrator and foreign Project Manager In the actual process, most people may be crossed. For example, the actual number of people in our project is only 9, the project manager is also a member of CCB, and the package owner is also the module owner. Based on the actual composition of our project, the following project structure is provided in VSS: Figure 3 VSS project structure Illustration: 1. the exec project mainly stores Project executable files or software installation files. Because the project is complex and the creation process is long and complex, the executable files are directly stored in VSS. This is not recommended for general projects. 2. The figure only shows the main part of the entire project structure, omitting the details. For example, the client project contains many small projects. Next, you need to set different user access permissions for each project and sub-project. Since all major software changes must be approved and signed by CCB before they can be executed, we grant the D (6) level permissions of the entire project to CCB members. The project manager is mainly responsible for grasping the overall progress of the project and coordinating the work with the external project team and other departments. Therefore, he has the r permission of the entire project and the permission of the Development document. The configuration administrator has two permissions: one is to have a permission for the entire project, and the other is to have only a permission for some projects, this depends on the actual permissions granted to the configuration administrator. Similarly, each module owner has a permission for each module. In addition, due to the special nature of the handover project, training is generally the main part in the project start process, and software modification is rarely involved, therefore, we recommend that you do not grant the C permission to the Development Engineer at the beginning of the project to avoid unnecessary errors and disputes. Summary This article discusses the specific mechanism of implementing permission management in VSS, and explains the application in the actual process with examples. Although the handover project has its own particularity, I believe that the basic idea of security management for any project is the same. I hope this article will give you some inspiration and reference. Reference 1) This article involves a lot of the word "project", sometimes it refers to the actual software project, and sometimes it refers to the project and sub-project in the VSS database. Please be careful when distinguishing. 2) For more information about Software Configuration Management, refer to the relevant content of this website. Software Configuration Management mainly includes version management, change management, and permission management. This article mainly covers permission management. 3) The software version uses Microsoft Visual sourcesafe 6.0 in English. For other versions, see comparison. 4) for details about all these commands, refer to the VSS help. 5) Project Background: The software handed over is a foreign company's software, which is a three-tier application based on Microsoft's DNA architecture,CodeThe number is about 1.5 million rows. Objectives of the handover: master the existing system, fully understand the relevant business logic, and make full preparations for developing your own software that meets China's national conditions. This may involve re-analysis of requirements, re-architecture of the system, and migration to the Java platform. 6) We use R, C, A, and d to indicate read, check out, add, and destroy permissions in VSS. |
