|
The complexity of software development is often underestimated, resulting
in inadequate processes that jeapoardise product schedules, writes Matthew Herrmann.
Software development encompasses many activities, including requirements elicitation,
database development and conversion of legacy data. While version control for source
code is paid at least lip service, other aspects of the process are usually not even
considered.
This view is due predominantly to the rise and rise of graphical tools. Most development
occurs in integrated development environments, which provide a graphical view of many
development artifacts, such as relational database diagrams and documents. While such
tools greatly increase productivity, they often store information in binary formats,
alienating the developer from a complete understanding of the document that is
being created, and limiting prospects of software configuration management. Still worse,
the integration of version control into these programs often makes users reluctant
to version control anything existing outside the IDE.
I am a strong advocate of graphical tools for development, and am a long-term
user of Visual Basic, and database modelling applications. However, a key step in using
these tools is being able to export and import data via a canonical text format.
There is no special magic in the selection of text as a storage format, except that
it is well supported by version control systems. Such support makes the following
demands a reality:
- The software should always be built on a machine with identical versions
of software installed.
- Features added to a customer's branch should carry all of the additional
deployment requirements and updates to documentation. When this feature
becomes part of the mainstream product, all documentation, deployment
and computer configuration information should be automatically carried
across.
- If one line of code is changed to correct a bug in software 6 months ago,
the only change in the package given to the customer should be that
particular line of code.
These demands are not controversial, but can be difficult to attain. For
long-term systems development they are worth achieving, as they allow elimination
of spurious factors when troubleshooting issues. The utility of custom-built scripts
to manage the software process can be illustrated by a number of success stories:
- An automated deployment system verified that a recent rise in
instability in a series of customer computers was unrelated to a software
upgrade. The problem was a Windows XP system DLL component that had been
modified by other software. This was achievable by tracing all changes to
the exact libraries deployed, the software changes and the impact of those
modifications.
- Complete version control of SQL Server schemas and data
allowed a preliminary version of the software to be deployed at a customer
site while development continued. The changes to the data at the
customer site were automatically patched into the development version,
along with bug fixes to stored procedures, when it was time to release the
development version.
As XML continues to become the standard document storage format, taken up
by newer versions of Microsoft products and other vendors, a complete
SCM-controlled environment will become easier to attain. Until then, scripts
and custom tools will be needed to take bridge the gap between
project artifacts and version management systems.
Matthew Herrmann is a director of Far Edge Pty Ltd, and an active member
of CVS and SCM-related newsgroups. |
