Software Configuration Management

[Geoff Vandegrift]

This is a dreaded topic however important it may be. We are a strictly Microsoft shop: we use Developer Studio and SourceSafe. I am wondering how other similar shops out there handle version tracking and builds.

I have brought our company a long way from where it was 1-2 years ago. When it was time for a build, we would each build our portion of the product (DLL, EXE, setup, etc.) waiting for the parts we needed and finally getting a distributable setup. This would literally take an afternoon of all the developers on the product. If it somehow failed, it took even more time. In addition to this nightmare, there was no way to ever return to the source code that originally produced a particular product.

Now we have a batch file that does all of this for us. Once a week we are able to kick off the batch and it gets everything out of SourceSafe, builds the product, publishes resulting libraries (for us to link to without having to build everything on our system), and gives us a setup. All the developers need to do is make sure their changes made it into SourceSafe. We also label any builds that go outside of our group so that we should theoretically be able to reproduce any of them.

(I know this is getting long, but please bear with me. I'm hoping this will generate some helpful discussion about SCM.)

The things I'm still not happy with abound! To build all of these projects from a batch, each project exports a .mak file from DevStudio. The batch then calls nmake for each .mak file (on the order of 50 makefiles for all the DLLs, etc.). It seems like I shouldn't have to do this. In the old days, makefiles worked recursively. However, to get this to happen in DevStudio, I have to have a workspace for each sub-tree at every project level export a makefile (as I understand it). Am I making things too difficult on myself.

The other major thing I'm not too happy with is our labeling process. DLLs that are shared accross products have their own versioning/labeling scheme and the batch file keeps track in its revision history which library a particular build depends on. Is this the orthodox way of doing things? Should I just label the root project for everything, so that all sub-projects end up with labels like "Product A v 2.5 alpha 1" even if the sub-project has nothing to do with Product A?

How do you guys do things in your shops? Is there some standard way of doing all this that I have completely missed? Any warnings, suggestions (books or otherwise), or questions for everyone?

Geoff Vandegrift

[Ed Syrett]

Hi Geoff,
>>>
To build all of these projects from a batch, each project exports a .mak file from DevStudio.
<<<

How do you do that ? Do you manually export the mak files from VC, or have you got some macro to do it ? I would certainly like to know if there is a way of getting VC to export a mak file from a command line. We check-in dsp files, so we can pretty much guarantee that they will be right (otherwise it wouldn't build for the developer) but we cannot guarantee that the mak files in SourceSafe are up to date with the dsp. Part of the problem is that when VC++ is "integrated" with SourceSafe, it only automatically checks out the dsp, leaving the mak file unchanged. We have the "Save mak file automatically" setting checked, but even so, the developers still sometimes forget that they have had the message that the mak file is readonly.

On the subject of dependencies, if you load up all your projects into one workspace, and then set up dependencies between the projects, the mak file that is generated will properly check that all the dependent projects have been built.

Meanwhile, I think we are in a worse position than you - my project has a dailybuild script, but the guys on the other larger project are still building manually in VC++ !!!!

Cheers,

Ed.

Ed Syrett
Senior Developer
Broadcast Systems Software Ltd.
UK.

[kdelgado]

We have a similiar nightmare where I work. We have upwards of 20 different applications that we sell as part of one massive suite. Building of the application is done by one of the developers working on that product. We keep versioning in the resource of the build. Each time a release build is made, we zip up the current source files for the product, and place them onto a server with nightly tape backup. The release executable/dll itself is placed onto another server with the build number included in the file name (ie "myapp.023.exe").

Then, we have our install shield script pointed to the proper directories for each application, and it strips off the build number for the apps when it builds the cab files for installation.

Now, here's the kicker: we have an internationalized product, and are currently selling English, French, German and Japanese version of our software...each of which has to have its own translated documentation and resources, and which all require seperate installations. Add to that, we have OEM agreements, and each of those OEM customers want thier own custom installations. So, for each company we have to do 4 (!!!!) installations. We have one person doing the install shield scripting now, and he does almost nothing but that.

To further complicate things, we do simultaneous developement of versions. We can be working on version 4 while version 3 has been passed on to QA. To do this, we split the codebase in source safe...and as bugs get fixed in one codebase, we have to make sure we update the code in the new codebase. It is a total nightmare.

You are not alone. But you also don't have it too bad...yet :) Good luck.

[Nelson Yu]

We've been using "msdev" directly to compile/build temporarily.

msdev FileName [/MAKE "ProjectName – ConfigName | ALL"] [/REBUILD /CLEAN /NORECURSE /OUT LogFile /USEENV]

Eventually we'll move to "imake"(non-MS) since we do lots of Cross-Platform development.