Section 3.2. Why Integration Is Helpful


3.2. Why Integration Is Helpful

Regardless of which tools are used in a development environment, integration of all the different kinds of tools is part of what creates an environment that is satisfying to work in. Manually copying information from one tool in order to do something with another tool is an inefficient use of time and is also prone to error. Tools that work well with each other are one mark of a good development environment.

There is another side to the idea of integration, though. Just as with most machines and hardware, the connections in software are often the most fragile part of a system. Upgrading tools can break integration schemes, and unexpected inputs from one tool can break another tool in unusual and hard-to-debug ways.

There is also the problem of how to handle one tool being unavailable for a period of time. For instance, if your SCM tool usually updates your bugs with information about the file changes related to each bug, what should the SCM tool do when the bug tracking tool is unavailable? Stopping work for the whole environment means that any one tool in an environment becomes a single point of failure. However, simply ignoring the bug tracking system means that the information there becomes "best effort" and cannot be relied on to be complete. A reliable distributed environment is a hard thing to achieve. The key question to consider when integrating tools is what the developers most want to know. Effort is often spent on uncommon scenarios just as an intellectual challenge, to see if something could be done.

Two of the simplest ways of integrating existing tools in development environments are through URLs and email. A web server can be a useful place for gathering project information from multiple tools.

Imagine that you want to make emails about changes to source files that are sent from the SCM tool more helpful than just a list of the names of the changed files. You could have the SCM tool insert the details of the changes in the email or send them as an attached file. But that's a lot of text that may hide other information. Adding URLs into the email that in turn point to a web server with the files' differences makes the changes easily available from most mail clients. Another advantage of URLs is that they are relatively easy to generate, since they are just short text strings. The mail doesn't even have to be sent as HTML for this to work with some mail clients.

Email is another common way to integrate different tools in an environment. Many tools can be configured to send email when changes occur, and the content of the email is usually in a standard format. A simple program can be started periodically, read any waiting email, and use the command-line interface for some other tool to make changes. For instance, integrating a bug tracking system and a customer support system could be done using email generated when a bug is changed. Email also has the advantage of being queued up for delivery, so even if one of the tools is not working, the information will be saved until the tool is ready again.

URLs and email are the simplest ways to integrate tools in a development environment. They work well for relatively low volumes of data and when the integration can take minutes to occurthat is, it doesn't have to work in real time. More complex forms of integration include the use of COM, which is one way that Microsoft tools such as Visual Studio are able to add tools from other vendors to their menus, and broadcasting "events" to sockets that are being listened to by many other tools.

Full-scale, reliable, and robust integration of different systems in an environment generally requires much more complex solutions. This is the land of middleware and business process management (BPM). Middleware is technology such as CORBA ORBs or Web Services that is used to send structured information from one system to another, and BPM is what to do with the information. This level of integration is beyond the scope of this book, since development environments (as opposed to bank transfers and trading floors) rarely require such robust and tightly coupled integration schemes.



Practical Development Environments
Practical Development Environments
ISBN: 0596007965
EAN: 2147483647
Year: 2004
Pages: 150

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net