CSC/ECE 517 Fall 2009/wiki1a 4 srhi4: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
= Best Practices for Source Code Management with Version Control =
__TOC__
__TOC__


Line 23: Line 25:


   1. Have a main line from which all the code is derived
   1. Have a main line from which all the code is derived
   2. The main line sets up the base of the project. Typically, when some code is being developed for two different platforms, say, Windows and Linux, common modules are placed in the main line. The two codelines for Linux and Windows are then taken from the main line to create parallel development lines.
   2. The main line sets up the base of the project. Typically, when some code is being developed for two different platforms, say, <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Windows and Linux, common modules are placed in the main line. The two codelines for Linux and Windows are then taken     <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;from the main line to create parallel development lines.
   3. Have parallel maintenance and development lines
   3. Have parallel maintenance and development lines
   4. Product development and maintenance (eg: bug fixes) happen simultaneously. For this reason, we need two parallel lines and these lines should interact closely and integrate / merge frequently to stay up-to-date with the fixes
   4. Product development and maintenance (eg: bug fixes) happen simultaneously. For this reason, we need two parallel lines and <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;these lines should interact closely and integrate / merge frequently to stay up-to-date with the fixes
   5. Have one codeline per release
   5. Have one codeline per release
   6. Separation / Isolation of the codeline for a specific release becomes important since parallel work goes on on the previous version of the software(maintenance). Thus a new codeline should be drawn whenever a release for the product is planned  
   6. Separation / Isolation of the codeline for a specific release becomes important since parallel work goes on on the previous <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;version of the software(maintenance). Thus a new codeline should be drawn whenever a release for the product is planned  
   7. Create policies for each codeline
   7. Create policies for each codeline
   8. Policies for a codeline define the stability and maintainability of a source code management system. The policy for the development line could encourage late merges while those for bug fixes encourage merging often.  
   8. Policies for a codeline define the stability and maintainability of a source code management system. The policy for the <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;development line could encourage late merges while those for bug fixes encourage merging often.  
   9. Merge early and often
   9. Merge early and often
  10. As far as possible, developers must be working with the latest copy of the code. Thus, merging often becomes important. Early merges help in having common bases for further development since the early parts of the code are most critical. Frequent merging also helps in avoiding large merges later in the cycle which could lead to incosistent code. It is the best way to keep all developers in sync with the product code..  
  10. As far as possible, developers must be working with the latest copy of the code. Thus, merging often becomes important. <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Early merges help in having common bases for further development since the early parts of the code are most critical. Frequent <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;merging also helps in avoiding large merges later in the cycle which could lead to incosistent code. It is the best way to keep <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;all developers in sync with the product code..  
  11. Do not isolate too much,  
  11. Do not isolate too much,  
  12. Isolation could be beneficial in case of large projects. However, creating many codelines / branches is inadvisable.  The cost for merging could become high.
  12. Isolation could be beneficial in case of large projects. However, creating many codelines / branches is inadvisable.  The <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;cost for merging could become high.
  13. Analyse and realign
  13. Analyse and realign
  14. The versioning tree could grow out of bounds and become wider and wider. Wider the tree, the more codelines / branches it has and the more difficult it is to manage. SCM systems must be checked often for such widening trees and action for merging codelines must be taken appropriately to sync up versions
  14. The versioning tree could grow out of bounds and become wider and wider. Wider the tree, the more codelines / branches it <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;has and the more difficult it is to manage. SCM systems must be checked often for such widening trees and action for merging <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;codelines must be taken appropriately to sync up versions
  15. Have an owner for every codeline
  15. Have an owner for every codeline
  16. All the developers using the version control tool should be able to know who and how many are using the same code which makes it easier to decide whether or not he wants to work on the current version or wait for the newer one, once others check in their modifications.
  16. All the developers using the version control tool should be able to know who and how many are using the same code which <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;makes it easier to decide whether or not he wants to work on the current version or wait for the newer one, once others check <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;in their modifications.


Ownership is a key term used in source code management. Every codeline is assigned an owner who is responsible for the codeline. The owner's typical tasks would be to assist in code integration and changes in his codeline, clarify ambiguous code policies, decide when to freeze and unfreeze code, co-ordinate across teams to make successful merges.
Ownership is a key term used in source code management. Every codeline is assigned an owner who is responsible for the codeline. The owner's typical tasks would be to assist in code integration and changes in his codeline, clarify ambiguous code policies, decide when to freeze and unfreeze code, co-ordinate across teams to make successful merges.

Revision as of 03:29, 6 September 2009

Best Practices for Source Code Management with Version Control

Introduction

Source Code Management (also called Revision Control) is a technique used to manage and monitor the codebase of any software in order to track the changes made to the code. It plays an important role in a setup where there are many people (software developers) have to modify / work on the same code. In such a scenario, merging different versions of the same code and availability of the latest version of the code becomes a critical factor, SCM helps in doing that.


Motivation for Source code management (SCM)

In a development environment, a single project can simultaneously be in multiple phases. One team would be working on building new features into the product. A second team would be working on fixing bugs (Tech support) while a third team concentrates on prototypes for future development. Different lines are created for each of these items – Functional line, development line, maintenance line, release line, integration line and so on. In such an environment, management of the codebase becomes critical for the following reasons

 — Allow simultaneous / parallel development of software. 
 — Integrate code changes from different teams / developers
 — Propagate bug fixes to future versions of the software
 — Isolate, coordinate and tidily separate work item units
 — Track and revert to older versions
 — Keep related projects in sync with one another


Efficient Source Code Management (SCM)

There are a lot of challenges associated with SCM. There is no standard way for source code management. Each project uses a different way of SCM depending on development cycles, releases, bug fixes, size of the project etc. However, there a few common guidelines and patterns that allow for efficient management. The following section describes a few common guidelines in a typical scenario

  1. Have a main line from which all the code is derived
  2. The main line sets up the base of the project. Typically, when some code is being developed for two different platforms, say,  
     Windows and Linux, common modules are placed in the main line. The two codelines for Linux and Windows are then taken
     from the main line to create parallel development lines. 3. Have parallel maintenance and development lines 4. Product development and maintenance (eg: bug fixes) happen simultaneously. For this reason, we need two parallel lines and
     these lines should interact closely and integrate / merge frequently to stay up-to-date with the fixes 5. Have one codeline per release 6. Separation / Isolation of the codeline for a specific release becomes important since parallel work goes on on the previous
     version of the software(maintenance). Thus a new codeline should be drawn whenever a release for the product is planned 7. Create policies for each codeline 8. Policies for a codeline define the stability and maintainability of a source code management system. The policy for the
     development line could encourage late merges while those for bug fixes encourage merging often. 9. Merge early and often 10. As far as possible, developers must be working with the latest copy of the code. Thus, merging often becomes important.
     Early merges help in having common bases for further development since the early parts of the code are most critical. Frequent
     merging also helps in avoiding large merges later in the cycle which could lead to incosistent code. It is the best way to keep
     all developers in sync with the product code.. 11. Do not isolate too much, 12. Isolation could be beneficial in case of large projects. However, creating many codelines / branches is inadvisable. The
     cost for merging could become high. 13. Analyse and realign 14. The versioning tree could grow out of bounds and become wider and wider. Wider the tree, the more codelines / branches it
     has and the more difficult it is to manage. SCM systems must be checked often for such widening trees and action for merging
     codelines must be taken appropriately to sync up versions 15. Have an owner for every codeline 16. All the developers using the version control tool should be able to know who and how many are using the same code which
     makes it easier to decide whether or not he wants to work on the current version or wait for the newer one, once others check
     in their modifications.

Ownership is a key term used in source code management. Every codeline is assigned an owner who is responsible for the codeline. The owner's typical tasks would be to assist in code integration and changes in his codeline, clarify ambiguous code policies, decide when to freeze and unfreeze code, co-ordinate across teams to make successful merges.