Integrate Button: Continuous Integration, Deployment, Testing, Feedback

Code Metrics in Minutes using Panopticode

One of the primary goals of every developer should be to prevent or drastically limit the number of bugs or defects from being introduced in their source code. It is also our responsibility to write good, extensible, testable, and maintainable code. This however seems like a herculean task to many.

John Smart, has very well said in his latest and greatest "Java Power Tools" book:

When used well, software metrics can provide valuable feedback on the quality of the code being written, and allow the development team to learn and progress. To be successful, software metrics should be considered a team sport.

So, lets automate the task of finding defects early by using open source tools which can look at your source code and in most cases find, if not all, at least some potential defects. There are numerous open source tools like:

1. CheckStyle - is a development tool to help programmers write Java code that adheres to a coding standard.

2. JDepend - traverses Java class file directories and generates design quality metrics for each Java package.

3. JavaNCSS - cyclomatic complexity tool.

4. Simian - identifies duplication in Java. Not open source.

5. Emma - Code coverage tool.

There are several other open source tools as well, like PMD, Cobertura, FindBugs and many more. All these tools are highly configurable as well. I mentioned the above five for a reason. I will get to it soon.

Imagine how much work it is to setup, configure, and run these metric tools as part of your continuous integration. It really is a huge task doing it for each and every project you have.

However, there is just one tool which you need to download: Panopticode. Panopticode includes all the above mentioned tools preconfigured. If you have read Neal Ford’s "The Productive Programmer", chapter 7: Static Analysis" page 113, the author talks about "Generating Metrics with Panopticode". That’s how I got to know about this amazing tool. There is no detailed instructions in the book on how to get this up and running, the web site does have.

So, I decided to give it a try and here are the steps I followed.

Rather than creating a new project, I re-used the PetStore project which I have been using for a long time for all the articles I write.

Follow these steps to get Panopticode up and running:

1. Download Panopticode from here.

2. Unzip and copy to your project folder.

The folder structure will look like this:

3. Make changes to the build.xml file.

In the Panopticode web site, there are 4 steps listed which you can follow. However, rather than copying the entire build file, I modified my existing build file, and ran the new target metrics within the Hudson(Continuous Integration Server) Job .

Add the following lines from the panopticode/build-example.xml to your build file.

3.a

<import file="panopticode/panopticode-imports.xml"></import>

3.b

<target name="metrics" depends="clean">
		<panopticode projectdir="${basedir}" projectname="${ant.project.name}"
              projectversion="${version}" srcdir="${srcdir}"></panopticode>
	              </target>
       

In the above target, specify the path to your source directory.

3.c Modify your target which compiles and runs your unit tests to include the following lines:

<panopticode-junit unitTestClasspathId="unittest.path"
	              outputDir="target">
	      <batchtest todir="target/rawmetrics/xml/junit">
	        <fileset dir="target/classes" includes="**/*Test.class" />
	      </batchtest>
	    

Make changes to the unitTestClasspathId to include the libraries required to run your tests. In my case, I included the JEE libraries required for my EJB application.

4. Run the metrics Ant target.

Run the metrics target either from the command line. You should see an output like this:

[junit] Testcase: validNumberOfLifecycleAnnotations took 0.008 sec
[report] processing input files …
[report] 2 file(s) read and merged in 4 ms
[report] writing [xml] report to [../CodeMetricsProject/target/rawmetrics/xml/emma.xml] …
[report] writing [html] report to [../CodeMetricsProject/target/rawmetrics/html/emma/emma-coverage.html] …
[emmaPanopticode] Loading panopticode structure: panopticode.xml
[emmaPanopticode] Loading supplement: org.panopticode.supplement.emma.EmmaSupplement
[emmaPanopticode] Writing back to panopticode structure: panopticode.xml
[mkdir] Created dir: ../CodeMetricsProject/target/reports/svg
[echo] Building Static Reports
[echo] Building Interactive Reports
BUILD SUCCESSFUL
Total time: 8 seconds

5. Force a Build.
Now that we have all the xml files generated for the metrics tool, we need to make sure run the above target metrics from the Hudson Job, and force a build. You should be able to see the following xml as well as HTML files generated:

6. Configure the XML files.
Finally, configure all these xml files within the Post-Build actions of the Hudson Job, and you should be able to force a build and see the reports in your dashboard. See screen shots below for various metrics:

a. Hudson Dashboard:

b. Emma Coverage Trend:

c. Check Style

d. JavaNCSS

7. Troubleshooting.
A few problems I found getting this up and running:

If you see the build failed with the following exception, copy the JDepend library to your ANT_HOME/lib folder.

compile:
  [mkdir] Created dir: /Users/meerasubbarao/Development/ci-jobs/jobs/CodeMetricsProject/workspace/CodeMetricsProject/target/classes
  [javac] Compiling 22 source files to /Users/meerasubbarao/Development/ci-jobs/jobs/CodeMetricsProject/workspace/CodeMetricsProject/target/classes
  [javac] Note: Some input files use unchecked or unsafe operations.
  [javac] Note: Recompile with -Xlint:unchecked for details.
   [echo] Panopticode - Using JDepend for OO metrics
   [echo] If you get an error stating 'Could not create task or type of type: jdepend' then you need to copy the jdepend-2.9.1.jar file to your ANT_HOME/lib directory.

BUILD FAILED
/Users/meerasubbarao/Development/ci-jobs/jobs/CodeMetricsProject/workspace/CodeMetricsProject/build.xml:54: The following error occurred while executing this line:
/Users/meerasubbarao/Development/ci-jobs/jobs/CodeMetricsProject/workspace/CodeMetricsProject/panopticode/panopticode-imports.xml:125: The following error occurred while executing this line:
/Users/meerasubbarao/Development/ci-jobs/jobs/CodeMetricsProject/workspace/CodeMetricsProject/panopticode/supplements/jdepend/jdepend-imports.xml:38: Problem: failed to create task or type jdepend
Cause: the class org.apache.tools.ant.taskdefs.optional.jdepend.JDependTask was not found.
    This looks like one of Ant's optional components.
Action: Check that the appropriate optional JAR exists in
    -/usr/share/ant/lib
    -/Users/meerasubbarao/.ant/lib
    -a directory added on the command line with the -lib argument

Do not panic, this is a common problem.
The commonest cause is a missing JAR.

This is not a bug; it is a configuration problem

Total time: 5 seconds
Publishing Javadoc
Recording Emma reports CodeMetricsProject/reports/emma.xml
finished: FAILURE

In the Panopticode-imports.xml file, you see the following comments:

  <!--
    Panopticode supports multiple competing code coverage tools. You can switch which tool you use at will and your
    build files will not change. You must choose exactly one though. If you do not want to collect coverage data
    then choose the 'nocoverage' import. You choose your coverage tool by using exactly one of the following import
    statements:

      <import file="plugins/emma/emma-imports.xml" />
      <import file="plugins/cobertura/cobertura-imports.xml" />
      <import file="plugins/nocoverage-imports.xml" />

    The default is Emma. Try them all to see which one you prefer.
  -->
	<import file="supplements/emma/emma-imports.xml" />

However, if you try to comment the import for emma and use cobertura import definition, you get an error as shown below:

Buildfile: ../CodeMetricsProject/build.xml

BUILD FAILED
../CodeMetricsProject/build.xml:3: The following error occurred while executing this line:
../CodeMetricsProject/panopticode/panopticode-imports.xml:42: Cannot find plugins/cobertura/cobertura-imports.xml imported from ../CodeMetricsProject/panopticode/panopticode-imports.xml

Total time: 223 milliseconds

Now, if I go back and change it to the directory where I found the cobertura-imports.xml file (supplements), I get an exception like this:

[cobertura-report] Report time: 263ms
   [move] Moving 1 file to /Users/meerasubbarao/Development/ci-jobs/jobs/CodeMetricsProject/workspace/CodeMetricsProject/target/rawmetrics/xml
  [delete] Deleting directory /Users/meerasubbarao/Development/ci-jobs/jobs/CodeMetricsProject/workspace/CodeMetricsProject/target/rawmetrics/xml/cobertura
  [delete] Deleting: /Users/meerasubbarao/Development/ci-jobs/jobs/CodeMetricsProject/workspace/CodeMetricsProject/cobertura.ser

BUILD FAILED
../CodeMetricsProject/build.xml:54: The following error occurred while executing this line:
../CodeMetricsProject/panopticode/panopticode-imports.xml:145: emmaFile emma.xml does not exist

Total time: 7 seconds

Next, I changed the report file to cobertura.xml, and the build complained about:

[cobertura-report] Report time: 264ms
   [move] Moving 1 file to ../CodeMetricsProject/target/rawmetrics/xml
  [delete] Deleting directory ../CodeMetricsProject/target/rawmetrics/xml/cobertura
  [delete] Deleting: ../CodeMetricsProject/cobertura.ser
[emmaPanopticode] Loading panopticode structure: panopticode.xml
[emmaPanopticode] Loading supplement: org.panopticode.supplement.emma.EmmaSupplement

BUILD FAILED
../CodeMetricsProject/panopticode/panopticode-imports.xml:145: null

Total time: 8 seconds

Finally, I downloaded the source code to see the classname for this taskdef, couldn’t find one and just gave up at this point.
You should be able to generate coverage report for Emma with no problems at all.

As you can see from this article, it is just a few minutes to setup and start using Panopticode. As I mentioned earlier also, there are many open source tools available, that can improve the quality of your code and also keep track of the same if they are automated and are part of your continuous integration. I am sure once you have these open source tools integrated, you will keep wondering how you developed code without them.

Authored by Meera Subbarao

5 easy questions for Paul Duvall

Jurgen Appelo who writes a blog on Understanding Development & Management asked me to answer 5 easy questions about my toughest challenge, software development and other interesting topics.

My answers join a list of software luminaries such as Steve McConnell, Grady Booch, Mike Cohn, Ron Jeffries, Mary Poppendieck and Alistair Cockburn

Ant or Gant?

Yes, this is exactly what I am frequently asked by my clients and many developers. It isn’t easy to answer this question. There are several projects using Ant. Should you run away from Ant just because there is a new cool tool out there called Gant? Should you switch to Gant just because you dislike XML? Not at all. Let’s take a closer look and see what might make you switch to Gant.

When to choose Gant?

1. Complicated Build Files. If your ant build files are becoming too complicated, and hard to manage, it’s time to see if using Gant can help. Let me explain what I mean by complicated build files. If you have too much of conditional logic within your build files, say something similar on the lines shown below in Listing 1:

Code Listing 1:

 <if>
  <isset property="sqlserver"/>
  <then>
  <do something here/>
  </then>
 </if>
 <if>
  <isset property="oracle"/>
  <then>
  <do something else here/>
  </then>
 </if>
 <if>
  <isset property="derby"/>
  <then>
  <do something for derby here/>
  </then>
 </if>
 <if>
  <isset property="db2"/>
  <then>
  <do something for db2 here/>
  </then>
 </if>

Or even something like this where you might be supporting deployment to different application servers based on some property in your build.properties or by the user as shown in listing 2.

Code Listing 2:

 <if>
  <isset property="server.jboss4"/>
  <then>
  <deploy to JBoss 4/>
  </then>
  <elseif>
  <isset property="server.weblogic10"/>
  <then>
	<deploy to web logic/>
  </then>
  </elseif>
  <elseif>
  <isset property="server.glassfish"/>
  <then>
   <deploy to GlassFish/>
  </then>
  </elseif>
  <elseif>
  <isset property="server.someother version"/>
  <then>
   <deploy to this some other version/>
  </then>
  </elseif>
 </if>

Things get out of hand when you have conditional logic as shown above in your build scripts. The listings I have are just the skeleton, imagine what happens when we start adding the actual deployment logic for all these application servers. It doesn’t matter how you refactor this, it is still going to be very complicated. Trust me, I have written build scripts which were several thousand lines, and refactoring them was not a trivial task.

2. Custom Ant Tasks. I myself am guilty of writing many of these. There are many situations which arise in projects where we create custom ant tasks. It is simple once you know how to write one, and than for every complicated task you need to perform, you involuntarily will start writing custom ant tasks.

Anyone writing a custom ant task will:

1. Create a new class that extends Ant’s org.apache.tools.ant.Task class.
2. For each attribute, write a setter method.
3. Write an execute()method that does what you want this task to do.

There isn’t anything wrong in doing the above, but imagine each time you want to make a small change you will have to make changes within your Java source code, compile, test, re-package.

3. Scripting. You can extend Ant further by not writing custom ant tasks, but by using small snippets of code written in an interpreted language like JRuby, BeanShell, or Groovy. These code snippets can be placed within your build files or in separate text files. If you are using Groovy’s Ant task, your build file might look something like this:

 <groovy classpathref="build.classpath">
 import some.package
 import another.package
 def fullpath = "${.basedir}/${defaulttargetdir}"
 def somefile = new SomeFile(projectName:"${pname}",
  buildLabel:"${label}", buildTime:"${new Date()}")
 def xml = "${fullpath}/dashboard.xml"
 new File(path).write(somefile.generateReport())
 ant.xslt(in:path,
 out:"${properties.defaulttargetdir}/some.html",
 style:"${properties.defaulttargetdir}/lib/report-style.xsl")
 </groovy>

Imagine having several lines of XML in your build files which have many of these small snippets of scripts. I myself don’t like mixing and matching build files with code snippets. If you have a team where everyone is in the same page, everything works fine. What if a team member has no clue about any of the Scripting languages? He/She will have no clue how to make minor changes when things go badly. If you have all the above or even one of the above three cases, you seriously need to consider using Gant. To quote Aristotle:

For the things we have to learn before we can do them, we learn by doing them.

So, lets see how easy it is to learn Gant and see how things can improve.

This part covers some very basics of Gant. The next part, will dive deeper into Gant by using it with a sample project to build our application, and we will also see how to use it with our CI Server.

What’s Gant?

Gant is a build tool that uses both Groovy and Ant. With Gant, you describe your build process using Groovy scripts. Stated simply, Gant allows you to specify the build logic using Groovy instead of XML. The next thing you may ask is ” Is Gant a competitor to Ant?”. Let me quote from the Gant web site to make things more clear here :

Whilst it might be seen as a competitor to Ant, Gant uses Ant tasks for many of the actions, so Gant is really an alternative way of doing builds using Ant, but using a programming language rather than XML to specify the build rules.

Download and Install Gant.

In order for Gant to work, you should have Groovy installed. You can download and follow the installation instructions for Groovy here.
As I said earlier also, in order to use Gant, you should have knowledge of Groovy as well. If you have never written Groovy code before, there are many interesting books on Groovy like:

a. Groovy in Action

b. Groovy Recipes

c. Groovy Refcardz

You can also read the getting started guide on the Groovy web site, which should give you a good starting point.

Download the latest version of Gant from here. Gant is currently at version 1.4.0. Unzip it to a folder. If you already have your GROOVY_HOME set, that’s all you need to use Gant.

Getting Started.

Open a console, and type gant. You should see a message as shown below:

meera-subbaraos-macbook-9:~ meerasubbarao$ gant
Cannot open file build.gant
meera-subbaraos-macbook-9:~ meerasubbarao$

You are all set at this point to use Gant in your projects.

Help Information: Open a console, and type gant -h. This will provide you with all the necessary help information you need as shown below:

meera-subbaraos-macbook-9:CodeMetricsProject meerasubbarao$ gant -h
usage: gant [option]* [target]*
-c,–usecache Whether to cache the generated class and

perform modified checks on the file before re-compilation.
-n,–dry-run Do not actually action any tasks.
-C,–cachedir

The directory where to cache generated
classes to.
-D

=

Define

to have value

.
Creates a variable named

for use in the scripts and a property
named

for the Ant tasks.
-L,–lib

Add a directory to search for jars and
classes.
-P,–classpath

Specify a path to search for jars and
classes.
-T,–targets Print out a list of the possible targets.
-V,–version Print the version number and exit.
-d,–debug Print debug levels of information.
-f,–file

Use the named build file instead of the
default, build.gant.
-h,–help Print out this message.
-l,–gantlib

A directory that contains classes to be used
as extra Gant modules,
-p,–projecthelp Print out a list of the possible targets.
-q,–quiet Do not print out much when executing.
-s,–silent Print out nothing when executing.
-v,–verbose Print lots of extra information.

Create a new file called build.gant at the root of your project.

Did a similarity between Ant and Gant strike you here? Ant build files are usually called build.xml, and they are created as a common practice within the root of your project folder as well.

If you have written or even modified Ant build files, you will know that it contains one project element, which in turn contains a name,the default target and the base directory.

Code Listing 4:

<project name="GantSamples" basedir="." default="compile">

So for example, sayHello target in Ant would look something like this:

<target name="sayHello" description="Saying Hello">
	<echo message="Hello from Stelligent"/>
</target>

Lets create the sayHello target, and also see how to set it as the default target in Gant as well.

A Gant target has a name and a description:

Code Listing 5:
target ( target-name : target-description ) {
groovy code sequence
}

The above sayHello target in Gant would translate as shown below:
target(sayHello:"Saying hello"){
Ant.echo(message:"Hello from Stelligent")
}
Now, open a command window and type gant at the root of the project where the build.gant file exists. You should be able to see a output like:

meera-subbaraos-macbook-9:CodeMetricsProject meerasubbarao$ gant
Target default does not exist.

Gant is complaining that we haven’t set a Default target. Lets see how to do the same:

Default target: Within Ant, you define the default target from within the project element as seen in Listing 4. The default target is the target called if no target is specified from the command line. There however is no project tag within Gant. There are two ways of specifying the default target as shown below

1. You simply create a target whose name is default.
target ( 'default' , 'The default target.' ) { aTarget ( )
2. or even simply:
setDefaultTarget ( aTarget )

In order to get our sayHello target working, we need to add one of the above scirpts to our build.gant file.

Code Listing 6:
setDefaultTarget(sayHello)
or
target ("default": "The default target." ) {
sayHello ( )
}

Complete listing of build.gant:
target(sayHello:"Saying hello"){
Ant.echo(message:"Hello from Stelligent")
}
/*
target ("default": "The default target." ) {
sayHello ( )
}
*/
setDefaultTarget(sayHello)

And you should be able to see:

meera-subbaraos-macbook-9:CodeMetricsProject meerasubbarao$ gant
[echo] Hello from Stelligent
meera-subbaraos-macbook-9:CodeMetricsProject meerasubbarao$

That was easy! If you have build files and it is becoming unmanageable by your team, there is a tool out there which can convert your Ant scripts to Gant scripts as well. I haven’t used it, but you can try it here.

In this part of the series, we learned when to move over from Ant to Gant, downloaded and installed Gant, and finally wrote a simple gant build file. In the next part of this series, we will see Gant in Action within a simple Java project.

And as always, keep us posted here if you are encountering any problems getting started with Gant. Stay tuned.

Authored by Meera Subbarao

Fire your best people...reward the lazy ones

Fire your “best” people…reward the “lazy” ones

In my experience, what most people consider to be their “best” people are often the root of most problems. It’s the difference between troubleshooters and troublepreventers.

Let me explain…

Bill is a troubleshooter (only). Many consider Bill to be the best employee in the company because he solves almost any problem that comes into the door. However, unbeknownst to many (especially management), Bill is the one causing most of the problems. Bill knows the purpose of every hard-coded lookup value and is the fastest to manually deploy the application to WebLogic using its web console. For instance, he knows that “14″ means a “transaction that is waiting for approval by second-line management”. However, instead of creating a human-readable constant, Bill hard codes the number “14″ in the source code. Therefore, Bill is the only one that can easily maintain these methods. In my personal experience, someone like Bill doesn’t do this for nefarious reasons, he’s just not thinking about how the next developer may need to maintain it. For every time a method is written, it’s read (and maintained) ten times (10:1). Therefore, people like Bill need to be writing source code for other humans, not the computer.

Let’s have a look at Peter…

Peter is a “lazy” developer (a troublepreventer). Because Peter is “lazy”, he hates doing the same thing twice, so he generalizes common functionality into a delegating class, creates interfaces for implementing classes to adhere to, or he writes build scripts that compile, integrate the database, runs tests and inspections, and deploys the software the same way every time. Peter finds it mind-numbing to repeat himself. Again, Peter is lazy so he doesn’t mind spending two hours automating something that normally takes 10 minutes to run manually. Why? Because, he very quickly reaps the benefits of this extra effort since every time the process is run he gets those 10 minutes back and even more importantly, he eliminates the possibility of human error (which, again, saves time and money).

The (”lazy”) troublepreventer thinks ahead. He extracts variable information into common properties files, seeks to reduce complex code, and automates repetitive, error-prone activities such as the build and deployment processes. He also ensures that others can very easily repeat what he has done. Anyone that has worked with me for even a day knows that I often sound like a broken record when I say “Is it in Subversion?” or “Have you updated the Wiki?” To me, if the knowledge is locked in your head, you are a less valuable, not more valuable, resource. Troublepreventers put their knowledge in the system, not just their heads, so that it runs the same way every time.

People like troubleshooters because they can solve a problem when a project is under pressure such as getting that emergency fix out the door immediately. Without question, you need troubleshooters on your project. However, many times the (exclusive) troubleshooters are the ones that cause the problem in the first place, be it a hard-coded value, duplication of code or a large complex method only they can understand.

Before you start thinking that I’m trying to gather together a group of slackers, I’m suggesting the complete opposite of this. I just want people to think about the total time involved, not just fixing the symptom. There are people that are both troublepreventers and troubleshooters. These are the people you want to keep and reward. However, on a given team, I’d opt for more troublepreventers than troubleshooters as they save everyone time, money and headaches.

Originally posted on testearly.com

The Myth of Build Management Servers

From time to time, I come across some who think that Build Management servers automate their delivery processes. There’s a big difference between executing automated scripts (what build management servers do) and writing the scripts that perform the automation (what experienced engineers do). For instance, I’ll hear people refer to the build management server as the tool that’s actually assembling the database or configuring the datasource that connects the application container to the database. The problem I have with this is that it’s not true (Or, if a particular process is "automated" by the server, your build architecture is not sustainable as I'll explain later). It's perpetuated by statements like:

"All three are big, expensive propositions that deliver considerable automation to build processes, as well as the early warning alerts implied by the term continuous in CI." (emphasis provided by me)

Often, it’s not the fault of the vendors selling their tools, but with ignorant managers or developers who vastly overstate or misunderstand the capabilities of the tool. The ironic part is that there’s no need to overstate the capabilities, because there’s great benefit in using a build management server.

Let me give you some examples of some build and deployment processes to illustrate my point that it takes experienced engineers to create effective automation systems.

• Database Assembly - Assembling a database and associated data involves extracting and writing DDL and DML SQL and that a build script of some sort executes these scripts in an ordered manner. A build management server executes the scripts that perform the database assembly. There are also frameworks such as Liquibase that help perform database upgrades, but you’ll need an experienced engineer to configure these tools for a project.
• Automated Tests - Depending on what’s being tested, writing automated tests requires an experienced developer, business analyst, or tester. These tests might be written in something like JUnit, NUnit, Selenium, etc.
• Dependency Management - Defining dependencies using tools such as Ivy or Maven. This requires experienced engineers defining versions, locations, transitive dependencies for each project. Some build management servers provide this capability, but using a build management server to do dependency management will lock you into using their tool just to build your software.
• Deployment Configuration - Automating deployments may involve many processes including configuring datasources (dynamically for each target environment), configuring LDAP and SMTP, configuring other authentication information, web container attributes (timeouts, connections, etc.), memory allocation, remote deployments, and the list goes on and on for any non-trivial project.
• Generating installers - Writing a GUI installer such as with a tool like IzPack or Install Shield. Experienced engineers need to configure and generalize scripts so that the install can work in any target environment (DEV and QA or different platforms such as Linux and Windows). A build management server may call a script that creates the GUI installer.

Other build and deployment processes…

• Code Quality Analysis - Configuring code quality analysis tools to assess code coverage, coding standards, dependency analysis, cyclomatic complexity, security analysis and coding standards may involve a developer to configure the tool and to define build thresholds based on project standards.
• Documentation - Writing scripts to generate documentation such as UML diagrams, ERDs, and developer documentation.

I’ve heard something similar to the following with some teams I’ve worked with:

We’ve already got automated deployments because we just spent tens of thousands on BigBuildManagementServer 2.0

Someone was sold a “bill of goods”! Again, it could’ve been because they didn’t understand what they were getting, not because the vendor misled them. And, they might be right if they’ve got a project where they can copy a file (e.g. WAR) over to a web container without changing anything else (even disregarding the problems you’ll experience trying to do this in a multi-target environment). However, I’ve yet to work on a trivial project like this.

There’s a fundamental principle that I suggest teams I work with should follow: the same scripts should be capable of running in any target environment. And, that means you shouldn’t need to rely upon a build management server to create working software on your local workstation. Moreover, you shouldn’t need to configure myriad environment variables or other manual configuration in each of these target environments - it should be part of the automated scripts that aren’t dependent on the build management server.

When I talk to teams about this in development organizations some will miss my point and incorrectly assume that I’m bashing build management servers. Moreover, as I mentioned before, there are tons of benefits in using a build management server; however, the items I mentioned above aren’t among them. Here are some of the benefits in using a build management server:

• Schedule build to run periodically or with every change
  
• Centralize all build and deployment execution across an organization
• Enforce a process of promotion and release to different target environments (DEV, QA, etc.)
• Manage deployments across multiple target environments and platforms
• Reduce errors attributed to local machine configuration
• Control access to people who are responsible for executing deployments
• Use tools that leverage multiple machines or other optimizations to improve build performance times (horizontal scalability)
• Provide a centralized web console for viewing reports

I’m sure a build management server vendor could provide many other beneficial features for their particular tool.

On projects, we often suggest and use several of the build management servers on the market as part of an overall software delivery automation system. But, I want to dispel the notion that a build management tool is writing your tests or writing the scripts to assemble the database or configure the application container or producing the documentation. It’s experienced engineers writing these automated scripts; these scripts should be capable of running with or without a build management server. The build management server executes these scripts in a controlled manner while optimizing resources and displaying the results of the build and deployment. While I mentioned that the vendors aren’t necessarily culpable, I will say that in reading some of the build management server vendor literature, it can be very easy to walk away thinking that their tool magically performs all of the deployment processes by clicking a button, without the need for anyone to write and customize scripts, and this is sad because it’s not even necessary, as their tools already have so much to offer without giving customers/prospects the impression that people can just install their tool and voila: instant software. The implication is almost like saying that because auto manufacturing plants use robots, there’s no need for people to put the cars together. Last I checked, we’re still a ways from achieving this in auto manufacturing and probably further from this in software development.

I realize there are automated build tools (separate from build management servers) that can be used to define builds using a GUI client. This can work well for non-complex build and deploy environments in which you can make numerous assumptions and treat servers as static assets. Often, the out-of-the-box ‘templates’ provided by these tools encourage hard-coded attribute values. That’s just too much assuming for me. Moreover, these tools limit the type of flexibility we often need when developing automated software delivery systems.

The other problem is getting locked into the vendor build management platform by configuring variables in the tool, hard-coding the datasource or using dependency management capabilities. I’m sure it’s good for a vendor’s business to be locked in to their tool, but probably not for your business. Again, there are many good reasons to use a build management server, but being unable to deploy the software unless you’re running the deployment from the build management server shouldn’t be one of them.

The encouraging thing is that, as an industry, we’re continuing to improve the efficiency of our automation. For instance, there are teams releasing software every 30 minutes, in some cases. It still requires experienced engineers to put together automated systems like these, but I’m optimistic that one day getting software into production will be as simple as pushing a button, without needing experienced engineers to write the automation. We’re just not there yet.

Email this entry

CI with Hudson, Ant, and Subversion tutorial

In case you can't get enough of CI from the book, check out "Spot defects early with Continuous Integration" at IBM developerWorks.

This tutorial guides you step-by-step through the fundamental concepts of Continuous Integration using Hudson, Ant, and Subversion-- when you're done, you'll understand the benefits of Continuous Integration as well as how to set up and properly configure Hudson, Ant, and Subversion to work together. The resulting build process will run both tests and software inspections and will report back violations almost as quickly as they occur.

Video: Use a Continuous Integration server - with Hudson

It's been a while since I posted new videos to http://integratebutton.com/, but here's a new one on Using a CI server (with Hudson). This video demonstrates the Use a CI server practice from the book, Continuous Integration: Improving Software and Reducing Risk.

I don't spend any time in this video "discussing" the why behind CI, just how to get it up and running with Hudson using the example files located at http://code.google.com/p/brewery-ci/.

I cover how to use scripts I provide to download, install and configure Hudson and Tomcat, run an HSQL database, run an Ant automated build, use Subversion to manage source files and administer the Hudson web application. Please note that there is no sound in this video. I've used text throughout the video to describe what I'm doing on the screen. It lasts approximately 7 minutes. Hope you enjoy it!

Continuous Integration on the Kindle

Hot off the "presses" or, perhaps, bit generator?, the Continuous Integration book has been released on Amazon's Kindle platform. I bought the Kindle 2 when it was first released a couple of months ago and am thoroughly enjoying it.

Since I spend quite a bit of time focusing on automation in the CI book, I think that the digital edition is an appropriate medium for it. It's also cheaper than the paperback version, so let me know what you think of it on the Kindle.