Mike MacDonagh's Blog

Somewhere in the overlap between software development, process improvement and psychology

Tag Archives: msbuild

How to migrate source to Jazz RTC SCM

First of all, although it might seem tempting to seperate scm and build, especially from a business change and planning perspective you just can’t (unless you’re writing scripting languages!). Software is just useless text if it can’t be built/run and a software team can’t be expected to move where they store their source without ensuring that build doesn’t get broken. In a perfect world build scripts would be generic and work regardless of the scm system they’re coming from but that generally isn’t the case due to this not being a perfect world:

  • different scm systems/ides imposing different structural constraints
  • absolute paths to files
  • dodgy use of symlinks
  • lack of parameterization of build scripts
  • complexity of numerous build technologies

This means that when migrating a team into Jazz SCM you need to at least ensure that their current builds work in their current normal way. Ideally it would be great to (re)engineer them to word with RTC Build but that isn’t always practical. This build refactoring shouldn’t be underestimated as it can take a while because of general build complexity, project complexity and technology complexity. It’s not unusual to find in just one organisation the use of: ant, maven, junit, ivy, make, clearmake, msbuild sometimes all on the same “project”. Add unit testing, style checking, static analysis and other things that people tend to add into the build process and you’re looking at a large amount of technical skill needed to even begin to make sense of what’s currently going on.

For this reason when moving a team from cm system X to RTC Jazz SCM I find it necessary to build the stream in 2 parts, which means you need a repeatable migration script that doesn’t get tripped up by things like permission or line end delimiter platform differences.

My general migration script (assuming not synchronizing or bridging):

  1.     Label/Baseline/Shapshot source files in old scm system
  2.     Using linux copy source files from existing scm/view/folder to a holding area
  3.     chown if necessary and chmod files to u:rw(x),o—,g—
  4.     I tend to do a dos2unix conversion on appropriate files to normalise mixed mode files
  5.     Share to RTC
  6.     Baseline/Snapshot in RTC
  7.     Make builds work (generally a process of changing absolute path references to local relative paths – often “/view/blah/…/proj” to “../” (here be technical complexity)
  8.     Baseline/Snapshot in RTC (“Initial scm migration with working build”)

There is a great advantage in following this process (which is why I’ve scripted steps 1-4 although unfortunately I can’t share that) somewhat slavishly in that it is repeatable to update a file set as a change set. If you do this to create an example stream for a team to experiment and gain confidence in while they’re still developing in their existing system, then when they choose to adopt you can simply update their stream(s) by:

  1.     [Optionally] revert to working build snapshot “Initial scm migration with working build” from step 8 above
  2.     Repeat steps 1-4 above
  3.     Copy files in holding area to RTC workspace
  4.     In RTC Pending Changes view drop-down the refresh button to select “Refresh Sandbox and Remote Changes”

You then get a change set showing the file changes since the experimental migration and the present time, simply undo or merge changes to build files to retain local workspace references and then deliver to update RTC using an atomic change set(s) 🙂

%d bloggers like this: