Software Configuration Management

Planning and Release Periods

Choosing a certain periodicity for integrating has some consequences in planning. Since we have chosen to integrate once a week, ideally the biggest task a developer works on is a week long. But we always have tasks that need more time than a week to be finished.

Having a task that lasts for more than one release is not a problem, because you can always rebase your work, updating it with the latest changes from the release. But is clear that doing so introduces some overhead and complexity in the process. It is better if you can avoid it. Figure 4 shows a task that is not completed in one release period and needs to be updated when the release is created. So if possible would be better to split long tasks so that they can be completed inside the release period.

[Click image to view at full size]

Figure 4: A task that lasts for several releases.

Build Automation

Again, during the finalization of a task the developer has to add version information to his executable. I started doing that modifying the version properties of the project with Delphi. The problem is that using an SCM tool you have to check out all the project files (not only the dpr) to modify and save the version information. So I decided to create a separate version file and include it as a resource (version information is a given resource). So during compilation a .res is created with brcc tool from the .rc file, and version information is added to the executable. Figure 5 shows the contents of the .rc file.

 

1 VERSIONINFO
FILEVERSION 4,3,211,0
PRODUCTVERSION 4,3,211,0
FILEOS 0X4
FILEFLAGS 0X04
FILETYPE 0X1
{
   BLOCK "StringFileInfo"
   {
      BLOCK "0C0A04F4"
      BEGIN
         VALUE" CompanyName",      "CIM, s.1."
         VALUE "FileDescription",  "V4.3"
         VALUE "FileVersion",      "4.3.211.0\255"
         VALUE "InternalName", "Xmas\255"
         VALUE "LegalCopyright",   "Copyright \251 1993-2004."
         VALUE "LegalTrademarks",  "marca registrada de\255"
         VALUE "ProductName",      "BL211"
         VALUE "Fecha",            "16/12/2005\255"
         VALUE "OriginalFilename", "exe\256"
      END       
   }
   BLOCK "VarFileInfo"
   {
      VALUE" Translation", 0x0C0A 0x04E4
   }
}

To compile the .res resource file I created a makefile, and I ended up using the makefile to compile both the finished tasks and the releases. So we compile under Delphi for normal development, but as soon as we finish a task we go to the build subdirectory and type something like: make TESTUNIT to run tests or buildtask to execute an script that will extract the task name using clearcase commands, create a .rc version information file with the task information and build our executable with that information.

Using a makefile is probably not the easiest or more fancy way to work, but we can easily create executable without debug information, run unittests or compile and include certain resources (now we include SQL sentences for different databases as resources, and an internal manager class loads the appropriate ones depending on the database you're connected to). It was specially helpful to create releases without debug information at the beginning, when we had five different Delphi projects (now we have only one dpr). Otherwise we would have to open each one of them, uncheck the debug information boxes, and compile.

Conclusion

Introducing a powerful SCM tool in a project is one of the main steps to follow if you want to increase the quality of your process. Activities will be better managed using such a tool. Finding bugs is easier because you can trace back any change done to your code base. And finally, controlling releases in a formal way introduces a work discipline that is helpful for the whole team.