Software Configuration Management

S/W Config. Mgmt. Plan V. 1.0

Software Configuration Management

Project:

Year: 2008

Quality Manager:

Date:

Software Configuration Management

1 Introduction

The purpose of this document is to describe how the following operations are performed:

· How the project’s software files may be changed during the semester.

· How Change Tickets are handled

· How a complete project build occurs

· How the files are permanently archived between semesters

2 Procedure: Managing Changes to Files

This section describes how files are shared during the semester, between team developers.

All documents (SPMP, Requirements, Design, Test) and code are saved in Subversion.

2.1 Phase 1: Manual – Used previous years

A project is allocated a shared directory in the /home/student/Classes/Cs476 directory. This directory contains the documentation, source code, and test documentation.
The Quality Manager extracts the code from Subversion for the group and allocates a Sandbox directory within the project directory.
People update the Sandbox directory. When the code is tested and works, the QM releases the code back into Subversion.
At the end of the semester, all working code is updated back into Subversion and a release is named. Other releases may also be named, such as any delivery to a customer.

2.2 Phase 2: Subversion – To be used this year

· Each team member creates a working directory using the following command:

$ mkdir Project

$ cd Project

· Members check out (co) the entire project as follows:

$ svn co file:///home/svnrepos/{Countryside,Soccer,ModelGraphics}

· Members make changes and test their changes.

· Members pull in the most recent changes from the project, implemented by other team members. They then retest other functions with team members to make sure nothing is broke.

$ svn diff // Shows your differences compared to the repository

$ svn update // Updates your files

You can interpret the output in this way:

G – updates have been merged

C – updates will need to be merged manually

U – Updated from the repository – but you made no local changes.

· The files are then checked in and permanently stored in the repository.

$ svn commit

$ svn commit <specificFile>

2.3 Phase 3: Subversion Branches – For Advanced User Groups

Each user has a branch that they work off of. The branch name is the students login name (also cs email name).

· Files are checked out of their personal branch

$ svn co file:///home/svnrepos/{Countryside,Soccer,ModelGraphics}/branches/<name>

· Files are modified and tested for the new functionality.

· Any updates to the trunk are merged into the branch. The new functionality and previous or existing functionality is tested.

· If all passes, the branch logic is merged into the trunk and parts are retested. The ‘merge’ function can accomplish this.

$ svn help merge

3 Build Procedures

This section describes how a complete build of the software is performed.

4 Change Request Procedures

This section describes how Change Requests are handled on this project. Change Requests are handled through TRAC, located at https://www.cs.uwp.edu/projects.

4.1 New User

New users must register with TRAC. Login names shall be set to the students CS user/email name. Go to the link https://www.cs.uwp.edu/projects and select the ‘register’ link. Complete the information.

TRAC administrators are given passwords of the first and last initial and all numeric digits of their UWP ID (instructor can provide if necessary). They should change their password using the MY ACCOUNT menu.

TRAC administrators then enter the ADMIN menu and select ACCOUNTS->USERS to view all the registered users. They can then assign authority to each user via the GENERAL->PERMISSIONS menu. They assign users the DEVELOPER status by using the ADD SUBJECT TO GROUP box ADD function on the right hand side of the PERMISSIONS menu. (Subject=<username>, Group=developer)

4.2 Creating Tickets

Go to the link https://www.cs.uwp.edu/projects and select the ‘login’ link. Log in.

Any project member can create a ticket. The state value (before it has been assigned to anyone) is NEW. The Project Leader shall always be cc’d on a new ticket. The ticket can be assigned by the ticket creator to the most appropriate person on the team. If the most appropriate person is not known, then the ticket creator leaves the ticket in the NEW state and the Project Leader shall decide on any assignment.

The Ticket creator sets the following fields appropriately:

The TYPE can be set to one of the following:

· DEFECT: A bug that must be fixed in the code

· ENHANCEMENT: A newly requested feature to be implemented in code.

· TASK: Any job that does not result in a change in code.

The PRIORITY shall be set to an appropriate value:

· BLOCKER: Nothing (including testing) can happen until this is fixed. This bug prevents the product from being used.

· CRITICAL: This defect prevents a feature from being used.

· MAJOR: This defect impacts a feature’s usefulness in certain areas.

· MINOR: This defect has a workaround or is sufficiently minor that it is rarely encountered. Software may be installed regardless.

· TRIVIAL: A minor enhancement that does not change operation but clarifies operation to users.

The VERSION is the version of code that the defect was found in or the task or enhancement is to be worked upon. The MILESTONE is the proposed release for this fix or work.

The COMPONENT is the area of the software most affected by the change. The creator shall provide all information known about the problem or work in the FULL DESCRIPTION text box.

Be sure to LOGOUT when you are done.

4.3 Lifecycle of a Ticket

A MILESTONE shall exist minimally for each planned release to the customer. Minimally each code release shall be allocated a VERSION number. VERSION numbers consist of Major.Minor. For major releases, the Major number is incremented. If a release includes only minor updates to a version, the Minor number is incremented. The VERSION or COMPONENT can be added via Trac’s Admin menu (available to Trac Administrators.)

If someone is assigned a ticket they do not should be assigned to them, they can change the assignment to their Project Leader (changing the status to NEW). The Project Leader will then re-evaluate the assignment.

When the code is completed testing, the assigned owner can change the status to CLOSED. The Project Leader and Operations Manager shall be cc’d. The merging of the new code into the trunk is then scheduled and the revised code is re-tested, as described above.

5 Procedure: Releasing Software

This section describes how releases are done, for example, at semester end or after a release to the customer.

To create a release, the following command is used:

$ svn copy file:///home/svnrepos/<directory>/trunk <directory>/tags/release-1.0

5.1 History of SVN Branches

This section describes how different branches have been used historically for this project.

You create branches in the same way as tags:

$ svn copy <directory>/trunk branches/<username>