Tuesday, February 13, 2007

Release notes … Completed Successfully

 

Situation

  • You are using Visual Source Safe as a source code repository.
  • Multiple developers in the team, each of them have a set of features/bugs to work on.
  • You have more than one source code repository; for example a development and production.
  • For configuration management purpose; it is required a release notes document for each developer to list the files added/modified/deleted in the source code.

Problem

· Release notes is an error prone task, developers always forget to list some files or take long time to prepare the release notes

· You end up with wasted time for unreliable documents with missing information.

 

Solution

Automate the release notes creation and let developers focus on coding and debugging, let them live in Visual Studio not in MS Word or Excel

  1. Assign feature/bug set for a developer.
  2. The developer shall start by getting the latest version of the source code stored in the source code repository.
  3. The developer will create a label on VSS before making any modification on any files, for example (Dev-X-YYMMDD-0).
  4. The developer will check-out files, work on his local machine and no files shall be checked-in until he finish all the assigned tasks.
  5. We are not talking about a process, so skip talking about how to make a code review or Check-in polices and so on …
  6. The developer should check-in all the affected files, should add useful information in the check-in comment; for example Feature No. or Bug ID.
  7. Then creates a new label like(Dev-X-YYMMDD-1).
  8. Use VssReporter to get the list of modifications between the two labels [Screen Shot will be here]
  9. Export the list as CSV or XML.

Finally, you have the list of modifications occurred, the CSV file can be used directly from MS Excel or use the XML file to make further reporting like the following ideas:

    • Create an XSLT to produce a fancy report with grouping on the Application/Module level or Solution/Project level.
    • Create an XSLT to produce a batch or script that will pull the affected files into a new folder with the same folder structure to create a Delta package.
    • Create XSLT for any other thing in your mind, you have and XML file that has all the affected files with attributes like when/what and whom.

Credits goes to my colleagues Tarek and Zidan, where we spent nights merging code of 7 developers from 2 sites. We came up with this approach to reduce time in release notes preparation and focus on development.

4 comments:

Fatma Ali said...

Hello Essam

I think this would be a very good idea if your are doing major changes. but in support projects(projects that need rapid small changes/ solving defects) this will result in a big number of labels .. the label will then lose its value and it'll be confusing.

Fatma Ali said...

Hello Essam

I think this would be a very good idea if your are doing major changes. but in support projects(projects that need rapid small changes/ solving defects) this will result in a big number of labels .. the label will then lose its value and it'll be confusing.

Fatma Ali said...

Hello Essam

I think this would be a very good idea if your are doing major changes. but in support projects(projects that need rapid small changes/ solving defects) this will result in a big number of labels .. the label will then lose its value and it'll be confusing.

Essam said...

we can remove the labels that we don’t need any more http://mark.michaelis.net/SourceSafe/Faq.htm#_Toc33748936

And more is better than nothing by the way :)