Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼


Improving the Development Process

Eric J. Bruno is a contributing editor to Dr. Dobb's. He can be contacted at [email protected]

For an application's long-term success, it's just as important to have good development processes as it is a good system architecture. In my experience, even the best development organizations -- those who manage their design and coding tasks well -- tend to leave application deployment and management until the end. This includes the proper use of a source code repository such as CVS, where multiple development projects may be working in parallel. Additionally, the source code repository should be used, along with a scripted procedure, to pull and deploy code to production environments.

Too many organizations rely on developers or system administrators to build software releases by hand, and then manually deploy them to the appropriate servers in production. This manual process applies to both new software releases, as well as the provisioning of new servers. Further, they also rely on developers or other build specialists to manage parallel programming projects in the same code base, again by hand. These approaches are fraught with danger because they rely on manual processes, as well as specialized knowledge only a few people in the organization may possess. To remedy this, I suggest the following:

  • Parallel development: Use source code branching along with a process that I've found to work well (described below).
  • Controlled builds: Use an automated build process that pulls code from a repository by label and compiles on a dedicated build machine.
  • Software deployments: Use a combination of Ant scripts and source code repository labels to deploy the proper artifacts to different types of servers (i.e. web server, application server, database, and so on).

Before getting into the details, let's cover some basics that, hopefully, you're already following. When developing code for any system, it's best to adhere to the following development process principals:

  • Ensure that all code is kept in a source-code repository (i.e., CVS or Subversion).
  • Perform system builds on a regular schedule that may change according to development phase (i.e. once per week early in a development cycle, or once per day towards the end).
  • Ensure that all code checked into the repository compiles, is unit tested to some degree, and does not break the build in anyway.
  • Any build that is a candidate for release and is either deployed to a test system or a production system is built with the latest code, and is tagged (labeled) in the source-code repository. The build should then be "pulled" from the repository bytag to ensure consistent releases across time and servers.
  • Use branching to ensure that changes to a particular release can be made to that release's specific code base, even when development has begun on the next release; i.e. parallel development.

Although I use CVS for examples in this article, most of the concepts should apply to other source-code repositories as well, be it Subversion, Git, or Mercurial. Let's examine the procedure for handling parallel application development first.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.