Monday, February 6, 2012

Source Code Configuration Management Best Practices - Software Development

Configuration Management(CM) is another important aspect in Software Development Life Cycle. Here I'm presenting the best practices, lessons learnt & tips while dealing with configuration management taking Tortoise SVN as SVN client Configuration Management Tool. I've categorized these practices as General, Branching & Tagging, Merging & Builds.The guidelines are more of SVN Subversion Dos and Donts. I've shared some 25 tips & tricks in Source Code Management.


GENERAL PRACTICES
  1. Check in often: Do not keep checkouts for more than 3 days. The sooner you check-in your changes the sooner you can realize your changes have been well integrated with other changes and are working fine
  2. Commit logical changesets: Do not check-in multiple changes that serve different purposes made on the same file at once.  It makes maintenance difficult
  3. Do not ever check-in the code without getting it reviewed. Worst case the peer review. You never know the code that's works fine on your system can affect or break any other functionalities. This might cause other developers to pause their work. The review must capture the impact along with other review checklists
  4. Do not copy an SVN folder from one location to another and try check-in files from copied location, the files will get committed in the orinal location! Instead use SVN export option available if you want to copy a SVN folder to a different location (Make sure the copied folder does not show SVN icon)
  5. Never overwrite a file into SVN repository and commit it, instead merge two files, verify the merge and commit
  6. Do not work outside of managed workspaces. SCM system can only track work in progress when it takes place within managed workspaces. The work done outside managed workspace(Ex: on a local copy) is not the work done because that work can any time be last due reasons like disk crash etc
  7. Do not share the workspace (where developers build, test, debug). It will be confusing and the work can not be tracked and it's against SCM rule
  8. Write Meaningful Commit Messages. The message must be to the point and describing what was changed and possibly why.
  9. Use a common and planned editor for viewing the source files. All project members must use the same editor for editing the files. This is because editors can insert/modify certain characters in the source files and such file some times may not be comparable by file compare softwares or SVN diff may not indicate the correct changes made
  10. Stay in sync with latest changes: As a developer, the quality of your work depends on how well it meshes with other peoples' work. So update your workspace on regular basis.
  11. Before you claim that your files have been checked-in, invoke SVN "Check for modifications" option and verify that any file still needs to be checked-in. This is necessary because there is a chance that we may forget to check-in some files and it gets discovered during the smoke testing the build. Imagine the time taken to rebuild and retest for this mistake!
BRANCHING/TAGGING
  1.  Do not branch until unless required, since we'll have to merge the branch to trunk and merging is time consuming and error prone
  2. Propagate early : When any changes need to be propagated from branch to trunk, do it sooner than later.Postponed change propagation can result in complex file merges.
  3. Always use Head Revision option for tagging the source code folders before the release. It ensures that always the latest copy from main is tagged irrespective of whether you have taken update or not
  4. Tag the source code, documents before any release is made. We may want to go back to the source code or any project artifacts for a particular release made at any point of time
  5. Never check-in any changes in the tag. Tags must never change. Some CM Tools ensure this. Tag is just a symbolic name for a particular revision. SVN calls it as "cheap copies". For SVN, best way to ensure this is to have commit hook on tag.
  6. If a new changes are to be done on the top of a tagged source base, create a new branch and do required changes there and make the release. More importantly merge the changes made in the  branch to the trunk.
MERGING

  1. Track merges manually. While committing the result of a merge, write a descriptive log message that clearly explains what was merged.(Ex: Merged revisions 3490:4120 of /branches/example branch to /trunk and purpose of the merge)
  2. Preview Merges : Merging results in local modifications, preview all the merges(It's better if the  owner of the change once verifies the merge in case owner is not taking up merge activity)
  3. Be cautious about the situation where two sets of changes cannot be separated out. Consider this case; you have local changes to a file called file1 and you are performing merge to file1 itself, if you feel your merge was not done properly and you want to revert the merge and if you revert your local changes to file1 before merge had taken place will be lost!
  4. Get right person to do the merge. The person must be best prepared for resolving conflicts.  Changes can be merged by (a) the owner of the target files, (b) the person who made the original changes, or (c) someone else. Either (a) or (b) will do a better job than (c)
BUILDS
  1. Check -in all the source files before the build is taken. People who are working on the project files must acknolwegde to the build focal that modified files and their dependent files have been checked-in. 
  2. Build often:(Sanity builds) End-to-end builds with regression testing reveal integration problems introduced by check-ins
  3. Keep build logs and build outputs for future reference
  4. Run the test cases identified to make sure there is no build error.
  5. Automate everything in the build process that can be automated. There is always a chance for a mistake in doing the things manually.

No comments:

Post a Comment

Related Posts Plugin for WordPress, Blogger...