• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 217
  • Last Modified:

Setting Up Test and Production Environments

How would you separate code that is not yet fully tested from production code given the following parameters?

- Our company has developed a program using Visual C++ 6.0 called PROJECT
- We use Visual SourceSafe 6.0
- Our team consists of 8 programmers
- Each programmer could be working on maintenance or enhancements to the PROJECT

I was thinking that we could have a test environment and a production environment. When code submitted by a programmer had passed QA, it could be migrated into the production environment. The problem with this is that the resource files (resource.h) aren't very multi-user friendly. Maybe multiple resource files could help this (see TN035). Also, the migration of code from the test to the production environments involves human intervention and that means that errors will occur. For instance, a programmer forgets to put a file back or maybe unknowingly puts back a file that shouldn't be put back (i.e. hasn't been tested).

I'm putting up 500 points for a solution based on real life experience that best meets our needs given the parameters describes above.

1 Solution
I have seen a couple of different scenarios:

1) maintain two trees in SourceSafe, one for production and one for development. You would label the development tree at certain points where you find the code to be stable and migrate it to the production tree.

2) maintain one tree and do daily builds (or less periodic) on a build machine against the development code and notify developers about which projects break for whatever reason - missing files, compile errors, etc. and label the code which is stable.

In any case, the developers would coordinate to regularly do gets on the current code and merge changes into the freshly gotten code. I would not recommend doing anything other than exclusive lockouts of any code that is being modified, so that no complex merges need to be done if more than one developer is working on the same module. This saves alot of headaches.

I assume that your complaints regarding resource.h stem from several developers modifying the resources of the same project. If you split the project by functionality into several .RC files, you can more easily manage this problem.
I can give some options based on my experience.

(assuming that code modifications are done by production team only and Testing is done by Testing team only)

1. If the project is small and does not have logical subdivisions then
- Once the code is freezed label the code in VSS with 'Release for Testing Team on mm/dd/yy'.

- The testing team can build that code and start testing it.

-Once the testing is finished then, the testing team will give the bug list according to the test plan.

- Development team will recieve that Test result report and start fixing the bugs.

- Again the updated code will be labeled on the same VSS folder.

This cycle goes for so many iterrations.

2. If the project is big and if we can have logical subdivisions then

-Either you can go for DLLs or u can create separate .rc files for different logical module(to ease the modifications).
- then rest of the procedure follows as given above for the point number 1.

(assuming that code modifications are done by both production team and maintainence team,  and Testing is done by Test team only.)

-Production team should release the code on module by module(DLL by DLL) basis. While releasing the code the code should be labled in VSS. Now the labeling should be very clear which team has done it. So label the code with 'Release for testing By Production team as on date'.

- The testing team is going to release the test result report after testing the code. Then the maintianence team is going to fix the bugs on modules basis. Now once the bugs are fixed the code is labeled based the Test Result Report(TRR) No.

Here there no question of merging the code. But people may need to wait for each activity (which is safe).

Note 1: It is always safe to keep the stable code in the form of zip for each release to Testing Team (eventhough it is labeled ). So u may need to keep the zipped source code in VSS in a separate folder(eventhough it is duplicate). The advantage is when VSS is got corrupted u can at least get the zipped code(provided that zip file is not corrupted. Many times i faced this kind of problem). Here the zipped code will not be altered at all.

Note 2:
I feel creating separate folders in VSS for Production code and Testing/Maintance code will be very difficult. Because once the code is modified in one part of VSS it has to be  updated in the other part manually. While transferring the code u may need to merge the updations which is very painful and may result to errors/re-work.

We may feel like we are saving the time by creating the seperate folders and working parallaly but what i found in one of the project is total confussion at the last moment when there was a tension of Releasing the Code(containing more than 75-100 files).

The organization depends on the kind of production procedure and Testing procedure.

This is my experience and if any body has better solution welcome.



SteveGTRAuthor Commented:

Thank you for your response. You have definitely given us here something workable. I rejected your answer because I'd like to hear other experts' suggestions. If nobody has anything better, I will award you the points.

Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

SteveGTRAuthor Commented:

We were running some scenarios around here based on your suggest ch_vasu. Here is an example using two programmers P1 and P2 working on PROJECT that has a baseline tested date of 1/1/00 (labeled snapshot):

1/1/00 --- PROJECT Baseline

Let's say that P1 puts back their code to be QA's on 2/1/00 and PROJECT is given a label:

2/1/00 --- P1 Task in QA

P2 puts back their code 3/1/00 and another label is produced:

3/1/00 --- P2 Task in QA

On 3/15/00 P2's task is fully tested, so the label is changed to tested:

3/1/00 --- P2 Task TESTED

On 4/1/00 P1's task is rejected and changes are made and placed back out to the system.

4/1/00 --- P1 Task back in QA

What do you do with P1's changes from 2/1/00? Do you back them out? If not then is the 1/1/00 baseline still the only threshold code base you have? When you introduce 6 or more programmers how do you keep track of all this? What chance do you ever have of producing another TESTED baseline of code?
A simple method of re-assuring an everlasting  production environment is the following:

Lets divide the people (assymetrically)into 2 groups testing and programmers ( it could even be everyone on both teams)

Now if you take these 5 easy steps :

1.Project has an entry on SourceSafe database
however , the Testing team ensure that the code that passed the testing is stored on a different location with versioning control , and is accessed only by the testing team.

2.The Project team labels every milestone (it could be a release or merely a new feature)

3.A bug report system is launched between the testing team and the programmers

4.A design review is conducted to match the design and the implementation and to avoid future bugs concerning new features or capabilities.

5.A file that needs to be accessed by multiple users is replicated , and one of the programmers is responsible for integration of the file on an N time line ( could be a day or more depends on access frequency) that will help to avoid human errors(although it would waste some time)

Steve I was the CM / Version Control person for over 16 months on a project that at one time had 8 full time programmers.  Currently we are down to 3 part time programmers, mainteance only.  The project was built using Visual  C++ version 5.x with Source Safe under Win NT.  This is a _very_ intense GUI based project.  It includes an extensive control pannel, a World Map, and about 6 different sources the user can choose from.  These sources once turned on and parsed would appear as an icon over the map based on the lat/long of the data source or referencing.   There could be in excess of 10k icons, but we encourage a count of < 5k for performance reasons.  Okay so much for the project description.

We have one and only one person who can check files out and check files in.  Anyone can get the "Latest and Greatest", but only one person has full access to the library.  It was not uncommon to have 2 programmers waiting while code was being incorporated into Source Safe, which means those who are waiting will have to integrate their code to the next version, and retest _before_ their code is incorporated.

The process was as follows:

* Programmer provides code and documentation describing what was changed, what STRs and SCRs were incorporated.  This needed to include what classes, methods, and members were effected.  If I didn't get it, their code waited until I got it.

* With code and documentation received, code was incorporated into a _copy_ of the Baselined code and tested in those area effected by the change.  If testing produced errors the programmer was called to determine the cause of the problem.  Sometimes it was operator error on my part, but other times it was not.

* With prelim testing completed, required files from the Baseline were checked out and coded was incorporated.  Effected code is tested once again including a fast check of related areas.  If testing produced errors and are proven to not be operator error programmer is called.  This was rare.

* With testing complete, modified Baseline files were checked in, and the documentation file is placed in a directory system for the tracking of change information.

* The last step is to get a copy of the full Baseline and build the system at this new version on our demonstration system.  The effected areas were basicly checked as well as related functionality.

While this sounds like a very labor intensive process, which it is, we have an extremly solid product.  Anytime we diviated from this process which I have basicly outlined for you, we had problems.  We call it cheep insurance.

I hope this helps.
If you have any question don't hesitate to ask.

David C. Keith, a.k.a. TrainMan
Sr. Software Eng.
I have worked in many situations where this has come up, and most of the time it has been workable.

The easiest, is of course if there is a way to organize the project into subsections.    If this is doable, then you give a particular programmer update authorization over those subsections.  Sometimes it simpy means no more than one programmer on a subsection, but if three or 4 people work on a subsection, one individual has to be responsible for moving the code from internal development to group sharing.  This is best done with an application such as visual Source safe.

If you cannot divide the work, and evreyone will be working on everything, then you will need to insure a more strict source code control system, in which each time a product is checked out, it is branched, to insure that changes can be easily rebranched into the product.  I do not suggest this route, as it almost always causes chaos in the long run.

The most important thing is to not ever 'hack' around the source versioning system, even when it seems neccesarry.  Even if that system isnt an application but an honor system.  ('I will ask joe before uploading anything').  Once you break it, it becomes, ineffective.  This is of course, the largest hurdle.  Often its getting the developers to deal with the annoyances of dealing with a version control system (being botha developer and a manager, i undersand both sides of the coin) can be one of the more difficult aspects.

Good luck. :-)
SteveGTRAuthor Commented:
Well I've gotten many good ideas from all of you. No definitive answer, but I've got a solution of my own that should work. I'm going to try and spread the points around to all of you. Thanks for your efforts
SteveGTRAuthor Commented:
Comment accepted as answer
SteveGTRAuthor Commented:
Well it looks like the first respondent, namely captainkirk, has received all the points.

Thanks again everyone! :)
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: MCSA MCSE Windows Server 2012

This course teaches how to install and configure Windows Server 2012 R2.  It is the first step on your path to becoming a Microsoft Certified Solutions Expert (MCSE).

Tackle projects and never again get stuck behind a technical roadblock.
Join Now