Seminar in Software Design : Configuration Management
Configuration Management
Lecturers

Aviva Dayan, Arik Gendelman and Pablo Galiana.

Presentation

Configuration Management

Abstract

The problem: Software problems often occur because of poor configuration management. These problems can be frustrating because they take time to fix, they often happen at inopportune times, and they are totally unnecessary. For example, a difficult bug that was fixed at great expense suddenly reappears; a developed and tested feature is mysteriously missing; or a fully tested program suddenly doesn't work.

The solution: Configuration management helps to reduce these problems by coordinating the work products of the many different people who work on a common project.

Configuration Management (CM) is a discipline that applies technical and administrative direction and surveillance over the lifecycle of items to:

* Identify and document the functional and physical characteristics of configuration items.

* Control changes to configuration items and their related documentation.

* Record and report information needed to manage configuration items effectively, including the status of proposed changes and implementation status of approved changes.

* Audit configuration items to verify conformance to specifications, drawings, interface control documents, and other contractual requirements.

Change is a natural part of the software development process, but needs to be controlled effectively. Software configuration management (SCM) is a software engineering discipline comprised of tools and techniques used to manage change to software assets. It is a set of activities that are designed to control change by identifying the work products that are likely to change, establishing relationships among them, defining mechanisms for managing different versions of these work products, controlling changes that are imposed, and auditing and reporting on the changes that are made.

There exist many solutions for SCM, each one of them has its advantages and disadvantages. We concentrate below on three different SCM products.

Microsoft SourceSafe: the Microsoft solution for SCM.

Advantages:
  • Synchronized with Visual Studio.
  • Relatively inexpensive.
  • Relatively simple to administrate.

Disadvantages:
  • Does not support branching.
  • Not compatible with other OS’s.
  • Critical repository corruption is possible.
  • Only small projects.

Concurrent Versions System (CVS): commonly used in Open Source projects.

Advantages:
  • Free.
  • Open Source.
  • Large community of experienced users.
  • Multi platform.
  • Supports separate development lines (branches).
  • De-facto standard for many IDE's.

Disadvantages:
  • Open Source – problematic support.
  • Performance problems in large projects.

Rational ClearCase: market share of 33% (source IDC).

Advantages:
  • Can handle projects with a lot of developers and that go on for a very long time.
  • Developed and marketed by IBM.
  • Versatile – lots of possibilities and capabilities.
  • Enables real parallel development.
  • Supported by multiple OS.

Disadvantages:
  • High price.
  • Too versatile – one can never learn all capabilities.
  • Complex support.
 
References

<SourceSafe>
<CVS>
<ClearCase>
Demo
Overview

We demonstrate the basic functions of Configuration Management using Microsoft Visual SourceSafe.

(Click here to view a Macromedia flash demonstration of ClearCase, prepared by IBM/Rational.)

In order to run the demo successfully, you will need MS Windows XP and MS Visual Studio. (We ran the demo using Visual Studio 2005 Beta Version with Visual Basic and Visual SourceSafe.)

Files
 
(To download the file we used as a .zip file, click here)
 
items.xml file
<?xml version="1.0" encoding="utf-8" ?>
<itemcol>
	<item>
		<desc>Original Version</desc>
	</item>
</itemcol>
Installation Instructions

A. Creating the Database

  1. Open Microsoft Visual SourceSafe Administration.



  2. Create a new database: select File | New Database.
  3. The Add SourceSafe Database Wizard appears. Select Next.



  4. Type the location for the database (or click Browse) and click Next. (This demo uses C:\ssddemo as the location.)



  5. Enter the name of the database (ssddemo). Click Next.



  6. Choose the Team Version Control Model: select Copy-Modify-Merge Model. Click Next.



  7. Click Finish.



  8. The Microsoft Visual SourceSafe Administration console will show a list of the users and theirs access rights on the database.



 
B. Defining the users
  1. In the Visual SourceSafe Administration console select Users | Add User.
  2. Type user1 as the username and user1 as the password.



  3. Click OK.
  4. Select Users | Add User.
  5. Type user2 as the username and user2 as the password.
  6. Click OK.
  7. Close Microsoft Visual SourceSafe Administration console.
C. Creating the Visual Studio project for the demo
  1. Open Visual Studio.
  2. Select File | New Project.
  3. In Project Types, choose Visual Basic – Windows.
  4. Under Templates choose Windows Application.
  5. Type ssddemo in the Name field.



  6. Click OK.
  7. The new project will be created with a default Form1.vb form. Close the form.
  8. Save the project: choose File | Save All.
  9. Accept the default names and location suggested and click the box Add to Source Control.



  10. Click Save.
  11. A pop-up window with the title “Log On to Visual SourceSafe Database” will appear.
  12. Enter user1 as the username and password. The database must be the previously created ssddemo. Click OK.



  13. In the Add to SourceSafe window click OK.
  14. Choose Yes when prompted.

 

D. Adding the items.xml file to the project
  1. In the Solution Explorer right-click in ssddemo project.
  2. Choose Add | New Item.
  3. Select XML File and type items.xml as the name of the file. Click OK.
  4. Copy the following text and paste it into the project items.xml file.
    <?xml version="1.0" encoding="utf-8" ?>
    <itemcol>
    	<item>
    		<desc>Original Version</desc>
    	</item>
    </itemcol>
  5. Save the file selecting File | Save items.xml (or Ctrl-S).
  6. Close the file.
  7. In the Solution Explorer right-click in ssddemo project and choose Check In.
  8. In the Check In window choose Check In.



 

Demonstration
The demonstration will demonstrate the four following actions in SourceSafe:
  1. Check-out / check-in with one user.
  2. Check-out / check-in with two users, including merge.
  3. Get latest version and comparison of files.
  4. File history.
 
Note: the demonstrations are related one to the other and should be done in order.
 
 
1. Demonstration of check-out / check-in with one user.
  • user1 checks-out the file items.xml as follows:
    1. In the Solution Explorer, user1 right-clicks in items.xml file and chooses Check Out for Edit.
    2. user1 chooses Check Out.
    3. user1 opens the file (double-click).
  • user1 changes the file as follows:
    1. user1 changes the text from "Original Version" to "Modified Version".
    2. user1 saves the file (Ctrl-S) and closes it.
  • user1 checks-in the file items.xml as follows:
    1. In the Solution Explorer, user1 right-clicks on the items.xml file and chooses Check In.
    2. In the Check In window, user1 chooses Check In.
 
2. Demonstration of check-out / check-in with two users, including merge.
  • user2 enters the system and opens the project as follows:
    1. user2 pens another session of Visual Studio.
    2. user2 selects File | Open Project.
    3. In the Open Project window, user2 chooses My SourceSafe(LAN) and then the ssddemo database, and then clicks OK.



    4. A pop-up window with the title “Log On to Visual SourceSafe Database” will appear. Enters user2 as the username and password, and clicks OK.



    5. user2 chooses ssddemo.root and clicks Open, then chooses ssddemo and clicks Open again. Then, he choose ssddemo.sln and clicks Open a third time.
  • user2 checks-out the file items.xml as follows:
    1. In the Solution Explorer, user2 right-clicks on items.xml file and chooses Check Out for Edit.
    2. user2 chooses Check Out.
    3. user2 opens the file (double-click).
  • user2 opens the file: notices that it contains "Modified Version".



  • user2 changes the file, as follows:
    1. Changes "Modified Version" to "User2 Version".
    2. Saves the file.
    3. Closes the file.
  • user1 checks-out the file items.xml, as follows:
    1. Within the user1 session of Visual Studio.
    2. In the Solution Explorer, user1 right-clicks on items.xml file and chooses Check Out for Edit.
    3. A message will appear informing that the file was checked out by another user (user2). User1 selects Yes.



    4. user1 opens the file (double-click).
  • user1 sees the text "Modified Version".



  • user1 changes the file as follows:
    1. Changes "Modified Version" to "User1 Version".
    2. Saves the file.
    3. Closes the file.
  • user1 checks-in his file as follows:
    1. In the Solution Explorer, user1 right-clicks on items.xml file and chooses Check In.
    2. In the Check In window, user1 chooses Check In.
  • user2 tries to check-in the file, as follows:
    1. Within the user2 session of Visual Studio:
    2. In the Solution Explorer, user2 right-clicks on items.xml file and chooses Check In.
    3. In the Check In window, user2 chooses Check In.
    4. user2 receives an announcement of merge.



  • user2 selects his changes to be written to the merged version of items.xml as follows:
    1. In the Local version window (upper right) user2 selects the text in blue. The Merged version in the database will be now the user2 version.



    2. Clicks OK.
    3. Clicks Yes.
    4. Clicks Yes to check-in the changes.
3. Demonstration of “get latest version”.
  • user1 brings the file from the repository, using “get latest version”, as follows:
    1. From within the user1 session of Visual Studio:
      1. In the Solution Explorer, user1 right-clicks on items.xml file and chooses Get Latest Version.
      2. User1 opens the file items.xml.
  • Changes to the file will appear in the screen ("User2 Version"). That is because the latest version in the database is the version that user2 modified in the merge.



4. Demonstration of History
  • user1 views the history of the file items.xml as follows:
    1. In the Solution Explorer, user1 right-clicks in items.xml file and chooses History.
    2. The window History Options appears. user1 clicks OK.



    3. The History window opens containing the history of items.xml.



  • user1 can now view any version of the file, as follows:
    1. user1 selects any file in the list and clicks the button View.
    2. user1 clicks OK.



    3. The window containing the file items.xml appears.



    4. user1 closes the View window.
    5. user1 closes the History window by pressing Close.