I was talking to Dan Miser
awhile back and he mentioned that it might be cool to blog about how the Delphi R&D team actually
develops Delphi itself. I've been on the team a long time, well before D1
shipped and I've seen a lot of changes to our development process over the
years, some gradual and others not. Right now, as we work on the next release I
think we're in a very interesting phase of the evolution of our development
process and I'll write about a few specific areas and mention some of the tools
we're using. Perhaps a few other R&D folks will chime in and offer some
additional "color commentary".
Building the IDE
You might wonder, does Borland actually use the tools they produce
for their own development efforts? The answer is a resounding "YES!". The Delphi
team in particular has always been a huge proponent of what Microsofties call
"dog
fooding" which is the act of using what you produce. Not only is the IDE
itself written in Delphi, QA's patented automated
testing framework is written in Delphi, our Bug Tracking system (RAID) both the
SOAP client and server are written in Delphi (running against an Interbase
server) and prior to StarTeam our version control client was an application
written and maintained by the Delphi R&D team. In fact, there are numerous
utilities used in our build process also written in Delphi as well as countless
little personal utilities that nearly everyone in QA and R&D have developed
for themselves over the years.
Anyway, the product is built using a typical "make" process from the command
line which supports mutliple targets allowing us to build the multitude of SKU's. Once built day
to day development work is performed using a "working" build of the IDE and a
convienent "make work" target updates this local "working" build. Currently, the
build takes about 20 minutes for a debug developer build on my 2.4GHz machine
(with 1GB of RAM although that's not really critical when building from the
command line) and is made up of over 25,000 files.
Delivery to Integration and QA
We have an automated build server which sends out email notifications to
everyone who checked in since the last successful build in the event the build
breaks. Since we now have developers around the globe working on the build it's
incredibly important to keep it building successfully and any build breaks are
usually tracked down very quickly. Once a the build is successful it is then
promoted to the Integration team where they build the product into a complete
installation for delivery to QA. Most of the time QA tests the product using the
Architect SKU since it has all the "bells and whistles" and as we near certain
milestones they'll run various SKU tests to ensure that all the different
versions include all the necessary parts.
What's New and Interesting
To me the "new and interesting" parts of our
development process which is still evolving is how we're leveraging the
technology that Borland has acquired over the past few years, namely StarTeam
and Caliber. Since the acquisitions we've been slowly working both products
(change management and requirements management) and processes into our, let's
call it, experience laden development process. We've made some great strides and
I think we've come a long way since Anders Hejlsberg's Notepad based list of
work items with dashes and "X's" and Gary Whizin's spiral notebook.
Using CaliberRM to develop and maintain our list of product requirements has
given us a much better process of scoping product development and assigning work
to individual engineers. I think it's measurably improved the transparency of
our development process for our management team so that they can more
effectively guide product development. Additionally, CaliberRM has provided a
great place for us to capture requirements for features we don't have time for
in the current release allowing us to maintain a list of good ideas from one
version to the next. If only we ship a product with all the features we
currently have scoped in Caliber. :)
Then there is StarTeam which not only allowed us to free up valuable Delphi
R&D resources used maintaining an old tool but has also given us a bunch of
features we'd all been wanting for years. It's nice to have a full development
team working on a tool that your team uses everyday. Besides I don't think the
StarTeam folks could ask for better "dog fooding" of their code so Borland get's
double benefit from the Delphi team using it.
That's all for now. Let me know if you find this at all interesting and I'd
be glad to share more about the inner workings of our team