Skip to content

Using Delphi in a team

I was just reading Marshall Fryman’s post about getting Delphi set up in a uniform way in a team or group setting.  He’s looking for a tool to manage the 3rd party components and compiler patches so that everyone on the team has the same setting.

What we ended up doing was documenting the install process for each component and compiler patch in our internal development wiki.  I prefer this method rather than an automated process like what Marshall described.  The wiki has a page that documents each step and provides helpful notes and also includes extra information when needed.  When we change or update a component, we just update that article in the wiki and then notify the developers what would be affected by the change.  We used MediaWiki, but any decent wiki package would do.

This isn’t limited to Delphi, we do the same for our .NET development environments.  When we rebuild a PC or add a new team member, it’s a straight forward process to get the IDE setup to our team standard.  It also allows us to customize the how we want the components to be installed.  For example, we make sure that each component set has the compiled units separate from the source code.  By just having the compiled files on the search path, doing full builds will not need to spend extra time compiling the third party code.  Most 3rd party packages already do that, but not all of them.  That saves a bit of time.  We also enforce a no warning and no hint rule on our own code.  Doing a full build with 3rd party code in the mix will toss out all sorts of warning/hint messages that we don’t need to see.

We also have a dedicated build PC.  The IDE settings on that machine provide the baseline for the wiki article and ensures that a QA-ready build will be compiled with the right settings and the right components.  When one of our developers needs to verify that his settings are correct, they can remote in to the build machine and compare the settings.  We let our developers deviate from our team standard, but not the build machine.  It’s our “Gold Standard“.

Marshall suggested that CodeGear should define an API the provides a mechanism for 3rd party vendors to install their components to a shared repository.  The IDE would then pull the components from the repository to the locally installed IDE.  That sounds intriguing, but I just don’t see everyone getting on board with this one.  Writing an installer to add Delphi components isn’t rocket science, but it can be a little tricky.  Adding a new API to that process adds a non-trivial amount of work to the component vendor. 

A lot of what goes under the hood of a component installer is determined at run time for the installer, based on the settings of the IDE that it is installing into.  The DevExpress installer is pretty intricate.  They use a single executable to install their any and all of their Delphi VCL components.  It handles all of the currently supported compilers and the packages that get installed are determined at runtime, based on your registration code.  In addition to installing or repairing the Delphi components, it will also remove the older versions of those components.  It has some fairly tricky logic, but it works very well.

To include support for a component repository API, a bunch of issues is created for the component vendor.  Most component vendors provide their license is by the user.  The API would need a mechanism to store individual licenses and install counts for group license.  The component vendors would have to come up with a standard mechanism for handling registration or license codes.  DevExpress validates their registration codes online against a user account and email address.  This new API would have to handle that.  I just don’t see that happening.  There would issues with components that are add-ons to other components.  You would need to implement the logic for the API to address version conflicts between the component vendors.

The idea of using a repository to manage 3rd party components sounds intriguing, but I just don’t see the component vendors getting on board.  There would be a lot of work adapting installers to the new API and I just don’t see the ROI in it.  For the most part, this would be a feature used infrequently.  It’s not like you are installing your Delphi components every day or even every month.  I used to write the QuickReport installers and while the Delphi versions were pretty easy to install, the C++Builder (this goes back 8 years) were just a nightmare to get right.  The last thing you want to do is to make that process anymore complex than it already is.

We started using the wiki approach when we migrated to Delphi 2007.  The first person sailing into the void (usually me) would write the installation instructions as each step was performed on his box.  The next step would be to update the build machine using the Wiki instructions.  This allows us to perform a sanity check on the wiki instructions and make any corrections as needed.  That made the process for the rest of the team pretty much a trouble-free experience.  We do the same thing with our Visual Studio environments. 

The wiki method also lets us document which service packs or hot fixes are required for each IDE.  It also list optional components or packages that, while not required, provide for a better experience with IDE.  Stuff like the DelphiSpeedUp IDE plugin or the GExperts tools are handy, but not required.