Solution for Software Release Management 1

[karu76]

Hi all,

I seeking for a more resolute approach to the release management process. Please enlighten me.

In my project we have 3 releases and 3 teams of at least 100 staff working on each release.

Currently Release 1 is in maintenance stage. Release 2 is in UAT and Release 3 is in build stage.

The problem is all 3 teams do not have the latest sourcecode versions of each other. So there is this tedious code merging process where each code is merged line for line and its done approx. ones in 3 mths.

Than we do a UAT on this .. and this cycle repeats endlessly. I feel this is an unprogressive approach and fustrating approach.

We cannot afford to have a single source control point because the will be more staff waiting for codes than working.

I hope u can suggest an approach which can perhaps throw some limelight into this problem..

Rgds.
L.Karu

 

[thedaver]

CVS is a very common open source project tool to maintain code.
As is "BitKeeper"...

Recommend you visit freshmeat.net

http://freshmeat.net/browse/52/

If you're doing Windows, M$ provides a source code control package of their own.

In any rate, you need to get a software tool in place and use a "check out and check in" methodology for each release.

D.E.R. Management - IT Project Management Consulting

http://www.dermanagement.com/

 

[planetant]

I agree. CVS-like stuff is the best way to do this.

*It has the check in checkout features;
*You can track changing through tagging and email confirmations;

It also needs some serious Project Management with strong process.

*Are you tagging the code for each release?

*Do you have well regulated servers - 'this server for user testing only (Should have very same environment to the live server); this server for staging, this server for development) then migrating the code between each server for additional testing of database architecture updates between versions as you go through development.

I cant stress tagging enough!

 

[karu76]

Hi guys, thank you for your advices. I will look into that CVS tool to study its advantages..

Yes planetant, we hv separate environments for the various stages. If we had adopted the one times release approach we could hv tightly coupled all the sources..

But since this releases are done in blocks and the blocks are interdependant on each other .. this mess occurs..

btw planetant, i dont understand the term tagging. can u explain more ?

i am thankful for all your suggestions..

L.Karu

 

[planetant]

Yeah, so this is the main thing to help you avoid trouble - branching and tagging the code. I cant imagine developing multiple lines of code from the same base without it.

Still it needs a good PM or PE or even a QA director coordinating. I seriously wouldnt worry about cost - spend whatever it takes, 'cause with a little planning this will save you so much dev time and chaos and worry and employee turnover and QA time, etc.

Notice that you can even revert branches if something goes horribly wrong:


This is a better description than what I could give:

http://liberty.sunsource.net/nonav/docs/ddCVS_cvsmanaging.html#aboutbranching

http://cvsbook.red-bean.com/cvsbook.html#Branches

--------------------------------------------------------------------------------
Tagging and branching
The CVS repository for your project hosted on this site supports branching and tagging your source files. At certain points in your project, you may want to enable development work in your project to progress in more than one direction simultaneously. Instead of maintaining a singular, linear path of development, CVS branching provides a way to divert or split the source tree for ancillary development activities without impacting progress of the project's primary effort. Examples of reasons to branch include:

to distinguish a clearly defined set of functionality in project source files for QA and testing, or
when you want to try an experiment such as added features or functionality without affecting the project's progress.
Tagging is included in the discussion about branching because the two operations are used in conjunction. Tagging allows you to "take a snapshot" of the overall project's state at a certain point in time, for example, to preserve a build with some particular characteristic. Because CVS manages individual file revisions, tagging is an important option for benchmarking the overall state of project source code. Files included in a tag will most likely be at different points in their respective revision numbering.

The critical difference between branching and tagging is the reason they are complimentary operations:

Branching affects individual files' revision numbering, whereas tagging assigns a common identifying marker across all project files at a fixed point in time.
So, for example, project files are often tagged at the point where branches are created.
Ultimately, branches in your project with successful outcomes get incorporated or merged back in to the main development trunk. When that happens -- and it may occur repeatedly on large or long-term projects -- identifying the point where this merge occurs is another reason to create a tag.

To tag project files, type:

cvs tag unique_tag_name
Your tag name can be a release name or date, a product version identifier, or whatever you choose.

To create a branch, type:

cvs tag -b unique_tag_name
Branching and tagging are complex topics with many considerations and options. You can find more comprehensive information and instructions in the following resources:


cvshome.org: "More about branching and tagging"

http://cvsbook.red-bean.com/cvsbook.html#toc_An Overview of CVS

"Marking A Moment In Time (Tags)"
"Branches"

http://cvsbook.red-bean.com/cvsbook.html#Branches

 

[karu76]

Thks to you planetant .. this is really exciting..

L.Karu