Setting Up Test and Production Environments

I can give some options based on my experience.

I)
(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.

II)
(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.

-Vasudev

 

ch_vasu,

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.

Steve

Steve

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.
davidckeith@netscape.net

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. :-)

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

Comment accepted as answer

Well it looks like the first respondent, namely captainkirk, has received all the points.

Thanks again everyone! :)