From the October 2015 Issue of Prestwood eMag

Proj Man PSDP & Process: QC: PSDP Change Management Procedure By Mike Prestwood

Posted 17 years ago on 4/23/2007 and updated 4/3/2010 Take Away: Quality Control: Vault change management procedure including using promotion groups.  Tags: Change Management KB100527

About Change Management / Version Control

This document specifies a procedure that will allow for concurrent development and testing by creating incremental builds that contain only the changes that will be tested. The revision control tool of choice is Vault.  

Basic Procedure

1. Developers lock source files by checking them out. They must keep code checked out until ready to test for a specific release.
   
2. The configuration manager / quality control gets the latest versions of the files and labels the project(s) "Build xyz Test".
   
3. A developer fixes bugs found during testing without introducing other changes to the code and checks the file(s) in.
   
4. Steps 2 and 3 are repeated as needed.
   
5. When the software is ready for production, the configuration manager / QC changes the label of the release build from "Build tuv Test" to "Build tuv Prod".

Example of labels as seen in Vault when "Show Labels" is selected (listed in reverse time order):

• Build 3.3.2 Test
• Build 3.3.1 Test
• Build 3.2.97 Prod
• Build 3.2.96 Test
• Build 3.2.95 Test

Parallel Development

There may be a need for two developers to make changes on the same file simultaneously. For example, developer 1 may be working on a new feature requiring three weeks development when developer 2 needs to do a one hour bug fix in the same file. In this scenario, the following steps are taken:

1. Developer 1 unlocks the file without checking in the current changes (Undo Check Out), but retains the changed file.
   
2. Developer 2 checks out the file.
   
3. Developer 2 changes the file with the bug fix.
   
4. Developer 2 checks in the file.
   
5. The basic procedure above is followed until the software is labelled for production.
   
6. Developer 1 checks out the file and merges the retained changes with changes made by developer 2.

Note that developer 1 and developer 2 may be the same person. Developers can do the merge manually or with a merge tool of choice. Developers are encouraged to use a personal revision control tool allowing them to do intermediate check ins during the development process prior to checking in code in the official quality control repository for testing / production.

Laura Lage

Comment 1 of 1 Do you have a suggestion for how to fix the following problem?: The table repair utility was run on some of the tables in the system. This always creates backup copies of the tables. Now when we try to delete the backups we cannot due to an error. The error seems to point to the backup tables being linked to the repaired tables. The culprit, I believe is referential integrity constraints. I don't know if someone tried to open one of the backup tables or not. All I know is that these files are taking up valuable space and it is desirable to remove them. Do we have to go through all of the tables and restructure them all to fix this or is there a simpler workaround? When the user is only running with Paradox Runtime, restructuring is not an option. Can't wait for your response. Posted 10 years ago

Article Contributed By Mike Prestwood:

Mike Prestwood is a drummer, an author, and creator of the PrestwoodBoards online community. He is the President & CEO of Prestwood IT Solutions. Prestwood IT provides Coding, Website, and Computer Tech services. Mike has authored 6 computer books and over 1,200 articles. As a drummer, he maintains play-drums.com and has authored 3 drum books. If you have a project you wish to discuss with Mike, you can send him a private message through his PrestwoodBoards home page or call him 9AM to 4PM PST at 916-726-5675 x205. Visit Profile