CVS usage and build instructions

1. Concurrent version control

1.1. Main rules

To achieve efficient development, repeatable builds and simplify code maintenance these rules should be followed by all development, QA, and support personnel.

• All application code, build and support scripts should be in CVS.

• Building of the project for QA and production can be done only in the clean environment when all code is checked out from CVS using appropriate tag to the new and empty directory to avoid the mixing of the code with any other code.

• Application should be divided into as many modules (CVS projects) as possible, which allows parallel developments of application subsystems. Modules relationships are maintained by either 3^rd party tool, i.e. WCM…, or by version documentation.

• Branch creation should be avoided as much as possible to reduce number of supported versions of the application and its subsystems.

• There should be no “non-CVS” copies of the code from CVS, therefore every developer should work with previously checked out code.

• All changes in each file should be either checked in or rolled back.

• All changes should be checked in as soon as project can be compiled without errors, so the rest of the team can continue development.

• None of the files should be locked during check out process, CVS is an excellent tool for real concurrent development.

• All development, except emergency fixes should be conducted in the main trunk of the CVS project.

1.2. Main trunk

Main truck of CVS project is for ongoing development. Its head contains most recent changes and allows further development and checking in. To check out the head, developer should only name the project without any additional branch information, which reduces errors.

1.3. Branch

CVS provides an ability to create separate from the main truck (or other branch) branches of code. It is highly recommended though to avoid creation of the branches unless the tag from which branch is created defines the production version of the code, and when for business reasons most resent tag of the main trunk can not be moved to production.

The only reason for creation of the branch is when something should be changed in the code due to the bug or small enhancement which can not wait until a new version is ready or suitable for production purposes.

1.4. Merge

1.4.1. Code merging

During each check in to CVS of edited files or update existing set of files from CVS some files are merged by the CVS. In most cases CVS can merge files by itself, in case of conflicts CVS informs developer about necessity to edit appropriate files to resolve such conflicts.

In case developer checks in edited files at least once a day merging process is very robust and transparent.

1.4.2. Branch merging

There are several types of changes which can be done in the branch.

The first one is a bug fix. Such change usually is not required to be moved to the head of the trunk because such bug is either fixed (or planned to be fixed) in the new version or simply does not exist there due to significant code changes or improvements.

The second type is enhancement which again can be already a part of the new version.

Using branches only for emergency fixes of production versions virtually prevents development team from merging branches with the main trunk by using CVS commands. Otherwise when branch and main trunk are very different merge cannot be conducted. That means that any necessity to merge branch with the main truck should be very carefully evaluated.

1.5. Files locks

As was explained above CVS is an excellent tool which takes care of any changes in the files and using current instructions locking of the files should be avoided, which speeds up the development.

2. CVS usage

2.1. Tag names and version numbers

There should be too types of tags, one for development (interim versions) and one for production.

The format of the tags will be as following:

V [major version] _ [minor version] _ {Development | Production} [development build version]

It will be transformed to the version using this format:

[Major version] . [Minor version] . [Build version] < Development >

For example:

V1_5_D021 or 1.5.021

V1_5_P022 or 1.5.022

Note that all components of the version for both development and production are the same. Developers will use sequential numbers for the build while production tag will be issued only when needed. It will help to track production ready versions.

For example:

2.2. Interim builds

Interim build will be conducted by development team using development tags only.

2.3. Final (production) builds

Development team will be using only development tags. Only when version is ready for staging environment QA will tag approved development tag with production tag, so it can be the case when code tagged with tag V1_5_D025 (development) will be tagged as well as V1_5_P025 (production).

2.4. Emergency fix of the existing version

In case when code which should be fixed is already tagged with the production code and main trunk contains changes which are either not tested enough or cannot be used by particular client branch should be created.

Branch should be created by development team which will conduct emergency fix and provide QA with appropriate tag for testing.

Even if fix should be done almost immediately the whole cycle should be finished, to avoid mixes of the code, which produces even more errors. Whole cycle can be finished in less than an hour which is more then a reasonable delay.

3. Build instructions

This topic will be explained in more details down the road when development will be conducted based on the rules above using modular structure of the application with or without WCM tool.

4. Scenario

Developer #1

• Code is checked out from the main trunk (no tag is used) to the empty directory

Developer #2

• Code is checked out from the main trunk (no tag is used) to the empty directory

Developer #1

• Some files are changed, project compiles

• Update is done – no merges have been found

• Project is checked in

Developer #2

• Some files are changed, project compiles

• Update is done – files are merged

• Project compiles

• Project is checked in

Team leader

• Sets development tag

• Reports to QA tag for testing

QA team

• Code is checked out using reported tag to the empty directory

• Project compiles

• Application is tested in the clean environment (there are no files from the previous testing, and deployment directory is empty)

• Sets production tag

• Code is checked out using production tag to the empty directory

• Project compiles and binaries provided to the support team

Support team

• Takes binaries from QA and move them to production environment which should be clean - there are no files from the previous rollout, and deployment directory is empty)

Home | About ByelaTech | Contact Us | Resources | Careers | Term Of Use | Site Map

Send mail to webmaster@byelatech.com with questions or comments about this web site.
Copyright © 2002-2006 ByelaTech Inc. All Rights reserved.