|
|
|
Interview with Continuous Integration author Paul Duvall
|
|
Page 3 of 3
The future of CI
One usually associates CI with more mainstream languages like Java or .NET. How do dynamic languages like Ruby or Python fit into the CI world?
Even though I have spent most of my time in these mainstream and
static-type languages such as Java, I actually find that the compile
time check that is provided by the CI build is not the most significant
part of the process. You can't have CI without regression tests. These
tests should run positive and negative tests to ensure your methods are
behaving according to the requirements. In addition, if you want your
developers to adhere to a particular set of standards, you can run some
static analysis tools on the source code (if you can find one for your
dynamic language). The bottom line is that although some tout the
static-type checking of CI as the major advantage, I see it as a small
part of the benefit of CI. You can build Ruby, Python, or virtually any
language in any build tool or environment if you are creative enough.
In fact, Ruby is gaining a following in automation tools as well. For
instance, ThoughtWorks is developing a CI tool written in Ruby called DamageControl, provided through open source. In addition, the rake
build language (written in Ruby) is being used to build software, just
like Ant. I think that dynamic languages such as Ruby and Python will
continue to gain acceptance in the development community, so as a
natural consequence, good practices like CI will follow along with
them.
Where on the CI continuum is the .NET
world in relation to the Java world (i.e. are the offerings equal or
far behind as in the pre .NET days or gaining traction?)
I have spent most of my development in Java, but I have done some
investigation into some of the .NET tools for CI. Most of the .NET
tools in the build and CI space have taken their lead from Java. To
start out with the build, the most popular scripting tool is NAnt. Once
MSBuild
is in wide release, it will probably be the build tool of choice for
.NET. MSBuild is largely based on NAnt and, of course, NAnt is based on
Ant. In the CI space, CruiseControl.NET and Draco.NET are two CI tools that can be used for .NET. There are also a number of commercially available tools such as VisualBuild
and BuildForge. It seems that .NET is gaining momentum in the area of
CI largely because of Java developers making the move to .NET.
Where do you see CI going in the future?
I see CI becoming the center of an automation infrastructure for a
software development project. Name your metaphor, but I consider CI to
be my "12th man" on a project, watching my back whenever I apply a
change to the software. An effective CI system continuously runs
automated processes and I see so much opportunity to add additional
features to this CI system. For example, right now, many development
shops consider running automated regression tests a natural part of
developing software. Just a few years ago, this was not the case.
Running regression tests is just one part of the CI puzzle. As a small
example of additional CI processes, we run automated inspectors (static
analysis) at my company as a part of every build. When, as an industry,
we increase the efficiency of our software and hardware resources,
running automated activities like these will become second nature. It
wasn't that long ago that McConnell, Cusumano, and others discussed the
nightly build best practice and people were skeptical. Most developers
accept this as the only way of doing business (although, only 20-25%
are actually running these daily builds, as indicated before). We
should be automating anything that is repetitive and potentially
error-prone. I think there is much more we can make "automatic for the
people". I foresee future development shops to look like a NASA or
television control room including real-time monitoring of the software
under development, and if anything goes beyond our identified
thresholds, we are notified and can take immediate action. I see the
future of CI increasing the efficiency and quality of software we
develop for our users.
Lastly, you contributed to "The UML 2 Toolkit" - what does the future of UML look like?
The problem with the UML is that for us mere mortals it has gone way
too far and this seems to have caused some software professionals to
throw it out altogether. This is unfortunate because it is a very
useful modeling language. Like any software language, UML runs the risk
of crossing the line between elegant and over-burdened. The 80% of the
UML that most people use is probably 20% of the language, and we find
that whiteboards and whiteboard collaboration is where we make our best
design decisions. I have incorporated many Agile practices at my
company and, yes, we use the UML. We use package diagrams for defining
our architectural layers and sequence diagrams for defining the
reference architecture. We use a tool called Doxygen that creates class
diagrams based on the source code. I know MDA
is a nice target, but for now I'll leave that to the academics and tool
vendors to either make real or reveal as just more marketing gibberish.
|
|
