Building For Success

• incompatibilities in practice)

• COM model - Single point of registration in the registry (and single point of failure)

Having recognised the problems that this caused, Microsoft introduced .Net with its xcopy deployment promise. They have also changed their tune with regards to use of the registry, now recommending that applications store user settings in files under the “\Documents and Settings\\Application Data” tree for example.

Of course .Net doesn’t solve all problems, and there are indeed several different versions of the .Net runtime available which users need to have installed on their machines, or get them to download. As a result, COM is still the most widely used technology for mass market applications.

The problem with COM is that you need to register components in order to be able to use them. If you have multiple copies of a COM DLL on your system then the last registered one is the one that will be used. This can cause major problems when developing and testing, and then subsequently installing – are you sure you are using the right one? (Hint - process explorer from www.sysinternals.com will guarantee to tell you which process has which DLL loaded - and it's free!).

It can also cause major problems when building an application. If there are dependencies between COM DLLs in your application it is obviously vital to build them in the correct order. If you miss building (and registering) a DLL then you may pick up some dodgy previous version that happened to be lying around on your machine.

Many Windows developments had major problems in this area.

Windows Case Study
Interestingly the same product referred to in the previous case study had a Windows GUI implemented via Visual Basic and C++ COM DLLs which needed to be built in a particular order. Also, an installer needed to be created.

The procedure to produce a complete build of the system was quite well documented but ran to 30+ steps! This involved things like opening a project in Visual Basic and resetting the references (to other DLLs) before building. Results then needed to be manually copied to a different directory structure and the installer IDE used to create the installer. All told, a build took nearly 2 hours, and there was one person whose chief job it was to do this! If they were away or busy, the whole team had problems.

In contrast one of the authors automated a different system – rather smaller but also including Visual Basic and C++ DLLs and an installer. This was done using Scons, which since it is written in Python is very easy to customise if necessary. Dependencies were automatically extracted from project files and DLLs were built using the IDEs with command line parameters.

Conclusion
Since builds are so fundamental to the development of software, it is vital that they be done well.  Often, all it requires is the knowledge that such things are desirable and indeed vital – the implementation is not usually that difficult. The sad thing is how many teams are stumbling along with stone age processes as much through ignorance of the benefits as lack of expertise in implementation.

The advantage of agile methods is that a good build process is recognised for the fundamental enabler that it is, and thus a corner stone for all agile development.

References

[1] Codeline Merging and Locking: Continuous Updates and Two-Phased Commits, Configuration Management Journal, Nov 2003

[2] The Illusion of Control – Configuration Management Journal, Nov 2003

[3] The Agile Difference for SCM – Configuration Management Journal, Oct 2004