Permissions Management in SourceSafe
source:
Software engineering network of experts:
Mac
Foreword Today, with the growing scale of software projects and the continuous intensification of project complexity, the importance of software configuration management (SCM) is increasingly recognized. Many excellent software configuration management tools also have to be born, making us easily manage our software projects, as one of this, Microsoft Visual SourceSafe is easy to use, easy to efficient, and Windows operating system and Microsoft development tools. High integration and other advantages. Today, let's talk about the rights management in VSS. First of all, I will explain the principle of implementation of the VSS mid-level mechanism, which is designed to VSS's default security access mechanism, project security and other content, then I will tell the specific method of implementing the permissions mechanism, and finally I will combine a software transfer project. Let's talk about how permission management is applied to the actual project process. 1. After VSS default security access control, each time you install VSS, the system automatically activates the default security access control mechanism. This set of mechanisms is very simple, it includes two levels of permissions: 1) Read-only privilege: Users can view all objects in the VSS database, but cannot modify 2) Read and write permissions: Users can view and modify any VSS database When you add new users every time you add new users, you can decide the user's permissions. In the "Add User" dialog box, you can confirm the user's permissions by it. We have said that this is just an extremely simple, coarseline solution, but it is also the simplest. In the actual process, you may need more detailed permission assignments, and even you want each file to set different permissions for different users. Then we have to personally set up the security mechanism of our project. Note: All security settings in SourceSafe are made in Visual SourceSafe Administrator, so before you go deep into the details: You must confirm one thing: your admin password is secure, except for you, don't want anyone else. Visual SourceSafe Administrator. Otherwise, all safety considerations are futile. Second, project security and user access before explaining project security, let's review the basic composition framework of VSS, VSS contains multiple databases, each database contains many projects, and may be nesting in the project. The subproject, and finally is your source file. You can compare this class to disk partitions, directory, subdirectory, files in the operating system, each machine containing a lot of disk partitions, contains countless directories, subdirectories in each partition, is your file in subdirectory . The user in the VSS is based on the VSS database, that is, each database contains its own user list. User Access Permissions What projects can be accessed (including viewing, modifying, and executing commands) database, which can only be accessed by those already authorized users, which is the so-called project security. Unfortunately, VSS only provides user permission control to the project (corresponding to the directory), and does not set different user access (such as Rational ClearCase, etc.) for each file. Although you can use some kind of way to do this, such as increasing sub-projects, but then destroying the normative, readability, and rationality of the entire project structure, even have some subprojects without any meaning. VSS defines four-level user access, the level is low to high, the latter includes all the prior to permissions, such as the Check Out permission automatically has read permissions.
1) Read-only (R): Allow View files, corresponding to View, GET, etc. Command 2) Check Out (c): You can use Check Out, Check IN, undo check out, modify the file content 3) file, delete (a) : You can add, delete, rename files, or add tags to the file, and the corresponding command has Add, Delete, Label, Rename and other 4) destruction (D): This level of authority corresponds to those with great destructive operations ( Just those who are unkinding to be fried squid), please keep your name: Destroy, Purge, Rollback. So some people can call it as suicide privileges. In fact, you can find that the two level permissions in the default security mechanism are related to these four, but the latter is divided into three different levels. Ok, we can start setting up different users after each level of permissions. You must activate the project security mechanism before setting up user permissions. Open the Tools menu of the VSS Administrator, click Options to get the SourceSafe Options dialog, select Project Security and check the Enable Project Security check box. (As shown in the figure below) Figure 1 There are three ways to activate the project security mechanism. You can set the user's project access: to set the permissions of each user for the project, and copy user permissions for the user. Corresponding to the Assign Rights for User, Rights Assignments for User, Rights Assignments for User, and Copy User Rights, corresponding to the Tools menu. We take a brief description with method one as an example. As shown in the figure below, select the item in the left box, select the user in the upper right box, and the user's current permissions are displayed in the User Rights of the right foot, select the different check box to set your own permissions. Note: Automatically reflects all sub-projects for each item. Two users authorized three, privilege management in actual projects in this section, I mainly combined with the actual application of authority management as an experience of configuration administrators, and need to consider during application factor.
The project we have to contact is a software handover project. The membership and responsibilities of this project team are allocated as follows: Project Manager: 1 person, responsible for coordinating the entire project business analyst, 1 person, responsible for the overall system architect of the entire system business : 1 person, responsible for the system architecture of the entire system Package Owner: 3 people, responsible for the three partial modules of the system front, intermediate and background database: 3-5 people, responsible for each module database administrator (DBA): 1 People, responsible for system database TEST / QA: 1 person, responsible for testing and quality assurance of the entire software, TECHNICAL WRITER: 1 person, responsible for the Writing Change Control Committee (CCB) of the related technical documentation: 3 people, responsible for project requirements change audit and implementation Most of the software configuration administrator, the actual process of the external project manager will have a person crossing. For example, the actual number of our projects has only 9, and the project manager is also a member of the CCB, and the Package Owner also partly controls the head of the module. . According to the actual composition of our project, I gave the item structure shown below in VSS: Figure 3 VSS project structure illustration: 1. Mainly stored project executables or software installation files in the Exec project, due to the project More complex, the establishment of the process is time-long and complicated, so the executable files are stored directly in the VSS. The general project is not recommended to use this. 2, just shown the main part of the entire project structure, omitted the details, such as the Client project contains many small items. Next, you need to set different user access to each item and subject. Since all software major changes need to be handed over, we can execute the CCB auditing signature, so we use the D (6) level of the entire project to the CCB member. The project manager is mainly responsible for the grasp of the overall progress of the project and works with the external project group, and other departments, so it has R permission to the entire project and has a DEVELOPMENT Document A permission. There are two privileges that configure administrators, one is A permission to have the entire project, and another may have only some project A permissions, depending on how much actual permissions given to the configuration administrator. In this kind of push, the person in charge of each module has a respective module. In addition, due to the particularity of the transfer project, it is generally mainly based on training in the project, rarely involves software modification, so it is recommended that the project start phase does not give development engineer user C permissions to avoid unnecessary errors and debates. Summary This article is discussed by discussing the specific mechanisms of the permission management implementation of the VSS, and the application is explained in the actual process. Although the transfer project has its own specialty, I believe that the basic idea of its security management is in communication with any project, I hope this article can give you a certain revelation and reference. Reference 1) A large number of "project" in this article, sometimes it refers to the actual software project, sometimes it refers to projects, sub-projects in the VSS database, please pay attention to distinguish. 2) For more details on software configuration management, you can refer to this website. Software configuration management mainly includes version management, change management, permission management, etc., this paper mainly involves authority management. 3) Software version uses Microsoft Visual SourceSafe 6.0 English, other versions, please perform the corresponding control. 4) Details of all of these commands can be referred to VSS help. 5) Project background roughly introduction: The software that is handed over is a foreign company software, which is a three-layer application of Microsoft DNA architecture, and the code amount is about 1500,000.
