Customer Interview

In this edition, we turn the spotlight on ourselves and highlight how we use SnapshotCM in developing SnapshotCM.

Describe the SnapshotCM configuration at True Blue Software?

SnapshotCM source is organized as two SnapshotCM projects: one for the database and one for the rest of the product. In addition, we have a third project for utilities and other files we share across our various systems.

Within each project, we have a common snapshot structure that is illustrated below:

Common -----------> Next
+ Integration       + Work
  + Work

Common and Next are release snapshots while Common/Integration, Common/Integration/Work and Next/Work are development snapshots. In addition to these five snapshots, additional snapshots are created for each release and frequently for longer-term development tasks.

Most current development happens either in Current/Integration/Work or directly in Current/Integration. Next/Work is used for next generation development. Release candidates are built from the Common snapshot, with minor changes often being done directly in Common as well. We have found that these five snapshots serve us well, allowing us to work on next generation code, current release and next release activities in parallel, and merge changes forward with ease.

How do you handle having multiple projects contributing to your product release?

The common snapshot structure in each project is key. Also important is that we arrange the workspaces for each pair of snapshots (one in Project 1 and the same named snapshot from Project 2) adjacent to one another, such that the relative paths from one to the other are known.

How do you handle portability variants in your setup?

All platforms are updated, built and tested from the same snapshots, forcing the code base to remain portable. After any portability changes are checked in, all platforms are updated, rebuilt and retested, iterating as necessary until everything builds consistently from an identical code base. Only when absolutely required, do we use conditional compilation or platform specific files in our shared code base.

How do you handle building on multiple platforms?

Each platform, as far as SnapshotCM is concerned, is configured identically. And all unix platform building and testing is fully automated. We have a script to update and build the projects in order, install the results and then run the test suite. Once all tests pass on all platforms, another script is used to create the install packages. Windows packaging and testing is similar, though most building is still done in the IDE.

What do you do to insure your release consistency and quality?

We have automated much of the release process, and have developed a one page checklist of manual tasks which we use to insure we don't forget anything. If it hasn't been automated, it is on the checklist. The checklist includes pre-build tasks like setting the release version number, as well as some post-install manual test scenarios, and a number of things in between. The automated tests and automated release processes help insure we release a quality product. Usually well before a release is ready to go, we are using it ourselves. Our daily use helps insure our customers only see a polished result.

Do you do any wide area network development?

Yes, we use several out-of-state systems for our porting efforts, typically accessing them using telnet. The typical scenario for temporary machines is to ftp and install the previous SnapshotCM port, use that to create and update workspaces from our SnapshotCM server, then run the same build, test and packaging tools we use on other platforms. Bootstrapping a new platform is more difficult as we need to ftp the initial workspace source, though SnapshotCM, once built, helps us identify any changed files to check in. The source is quite portable, so most ports are straightforward and quick.

What development tools are used in developing SnapshotCM?

Our primary development is done using Visual Studio with the SnapshotCM Source Code Integration. On non-Windows systems, we use gcc or the platform vendor's compilers, gmake, and a number of home-built shell scripts. On Windows we use cygwin to allow us to use the same shell scripts for packaging and testing on Windows as we use on unix systems.