|
|
|
Interview with Continuous Integration author Paul Duvall
|
Article Topics
What is CI? · The Facets of Infastructure · The Future of CI Page 2 of 3
The Facets of Infrastructure
You mentioned PMD and JDepend as interesting inspection tools- what are some others that you find interesting?
I guess I like to travel in "twos" with my inspection tools, just in case. What I mean is that I also use CheckStyle for coding standard adherence, along with PMD and I use Macker
along with JDepend for architecture/design analysis. On our projects,
if we have any CheckStyle or PMD errors, our build fails. This ensures
that we don't let coding standard problems creep into our source code.
A few other interesting tools include Doxygen for creating class diagrams and documentation, AntGraph for modeling my Ant target dependencies, and PMD's CPD and Simian for duplicate code checks. We use other "inspection type" tools, but they are more in the testing space - such as Cobertura.
You also mentioned Maven. Maven has
the tendency to bring out strong feelings in people- what are your
feelings on Maven? Which tool do you prefer- Ant or Maven?
I tend to use Ant instead of Maven, but not for any particularly good
reason. It's because I've been using Ant for years and I am comfortable
with it. I've used Maven, but not on a for-profit project. I'm an
advocate of Maven's goals. In fact, their goals are somewhat related to
the Kitchen Sink pattern. According to an OnJava survey,
something around 20% of their respondents are using Maven. I'm very
curious as to what will happen now that they significantly changed
their model with Maven 2 and added Continuum as their CI engine.
You have defined an interesting set of Development Infrastructure Patterns, which you regularly talk about on the No Fluff Just Stuff Software Symposium tours. Tell us about the Kitchen Sink Infrastructure Pattern.
I've defined a number of patterns related to the software
infrastructure you create for your fellow developers, not for the
software you design for users. I take special care to use the word
"defined", not "created" because most of these patterns have been
occurring on well-run software projects for years and I have only
applied the pattern semantics to them. In any case, the Kitchen Sink is
one of those patterns. Most of us have heard the saying "everything but
the kitchen sink". Well, this pattern includes the kitchen sink as
well! One of the problems I've typically found on development projects
is that the development environment, well…sucks. This is a technical
term, of course. I jump onto a project and I'm ready to code so I ask a
few seemingly innocuous questions:
- Which IDE do you use and what version?
- Which build tool?
- Where is the build script?
- Which application server and version are you using? Where is it?
- Which RDBMS and version are you using? Where is it?
- Where is the project-related documentation?
- Which libraries (JARs) are you using? Where are they located?
Of
course, the list goes on. As it goes on most projects, I commence a
wild-goose chase attempting to get the answers to these and many other
questions, which usually leads to the inevitable answer: "Did you check
with Joe?" The unfortunate part of this story is that this
significantly drains my productivity in the first week or so of the
project. But, as with most infrastructure issues, it's also the
seemingly "little things" here and there (such as a version upgrade to
a tool) that continues to drain our productivity for the duration of
the project. So, the solution is to create a consistent directory
structure that is incorporated into your SCM tool, such as CVS. Once
this is established, you centralize your software assets in a place
where everyone can access them such as your SCM tool. For me, this
means I place everything in CVS. For example, I add all of my tools
including RDBMS, web framework, ORM, static analysis tools, and
application server. I add any associated configuration files, build
scripts, JARs, system/user documentation, useful UML diagrams, etc. as
well. This reduces the amount of time and effort on accessing these
software assets and keeps me up on the latest tools, versions and
configuration files. A Kitchen Sink implementation also works well in
creating a sandbox environment on your workstation, which can help
prevent the "works on my machine" problem. With the Kitchen Sink, you
know that everyone is working off of the same files, tools, and
versions. As I mentioned, Maven helps to implement the practices of the
Kitchen Sink pattern.
|
|
