Skip to content

CVS and Best Practice and Standard

August 10, 2009

CVS Best Practice
===============
Following are the standards follwed by TenthPlanet Technologies for CVS Best Practices as part of
OSS Configuration Management.

Repositories per Partner
———————————-

For a specific Partner we are maintaining seperate Repository. For that Partner there
may be many projects and each of these project sources are maintained as seperate Module with
in this Repository. Each Project Module will have seperate branch for development.

Example
Partner : KBlue
Project : GotGame, openBLUEWebEdition
Repositories per Project
———————————-

For Projects we are maintaining seperate Repository, each repositoy will have single
module containing the Base Project source. For Development there will be a seperate branch
for this module. Developer assigned for this project can able to checkout the source from
this branch for development.

Example
Project : Ebel, EbelWebEditio, WebstorePortal and LaboCast

Repositories per Product
———————————–

Simillarly like Project, we maintain seperate Repository for Product, each
repositoy will have single module containing the Base Product source. For Development there
will be a seperate branch for this module. Developer assigned for this product can able to
checkout the source from this branch for development.

Example
Project : iCompiere, iCMS and iPortal

User Previllage Setting :
———————————

Developer who are assigned for this Project alone will able to Checkout the Source. More over
Developer’s are restricted to commit their source in some of the folders.
Versioning / Tagging convention for each Release
————————————————

Each Release will be Tagged / Versioned as per the standard Naming convention.

Standard Tag Naming : < Project / Functionality – Name >_< M1 / M2 / … >_< Inernal / External >_< Date >

< Project / Functionality – Name > :
———————————————-

If we plan for a Major Release there will be more than one functionality  and it will be hard to
mention all the functionality, in that case just ProjectName will be mentioned.

If we plan for minor Release we will mention the functionality Name for which the release
is made. This is mandatory.

< M1 / M2 / … > :
——————-

M1, M2,….. denotes the Milestone Releases, for example M1 is ment for Milestone 1 and
simillarlly for others.
This is not mandatory.

< Inernal / External > :
————————

Internal : This is used for internal testing.

External : External label is used when the Release is planned for client. After internal QA is
done, based on Bug and severity report PM will decide for the Release.

This is mandatory

< Date > :
———-

Date when the QA has been requested for.This is mandatory.

Note : On the same day, if second release is planned then the new Lable will have “R2” at the end.
Example 1 : PM Plan’s for GotGame Release to client with 5 functionalities for Milestone 1 on 2 May 2007,
then in this situation Version / Tag lable should be like this

< Project / Functionality – Name >_< M1 / M2 / … >_< Inernal / External >_< Date >

“GotGame_M1_External_02May2007”

Example 2 : Second Release on same day.

“GotGame_M1_External_02May2007_R2”

Example 3 : PM Plan’s for GotGame internal with 1 functionalities named as “ShipToOrder” for Milestone 1
on 2 May 2007, then in this situation Version / Tag lable should be like this

< Project / Functionality – Name >_< M1 / M2 / … >_< Inernal / External >_< Date >

“ShipToOrder_M1_External_02May2007”

Advertisements
No comments yet

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: