Posts Tagged ‘build’

Continuous Integration for Agile Project Managers (Part 2)

April 27, 2010

In part 1 of this series, I described the essential elements of Continuous Integration within the context of agile development and briefly discussed the software options for a CI server. I explained that the building blocks of CI are a version control system and a build management tool. The former creates the foundation, by giving the CI process access to the latest copy of project source code. The latter then takes the source code and, in most scenarios, transforms it into the deployable binary artefact that represents the software application being developed.

It is useful to consider this transformational process as a series of steps or life-cycle phases. By analyzing our build in this conceptual way, we can better understand how to ‘bind’ or attach actions to each distinct life-cycle phase. Why is this important? Well, using this simple idea I can demonstrate how you can hardwire quality checks into to your CI process. Performing such checks, and publishing their results, means that we can really start to take advantage of the significant benefits CI can bring to your agile projects.

I actually prefer the term ‘quality gate‘ as opposed to ‘quality check’ as it better fits the idea that you must pass through one gate before entering another. In each case, if we are unable to pass through the gate, we can choose to fail the build and our CI system should dispatch a notification to us. In addition, a good CI process will publish the metrics and ‘violations’ concerning each gate, so that they can be reviewed in detail after each build has occurred.

Build Life-Cycle Phases and Quality Gates

Phase 1 – Resolve component dependencies

Often our projects will have dependencies on other internal or third-party components. This is very common for example, in the Java or Ruby programming language worlds where the re-use of packaged binary artefacts (JAR’s for the former and Gem’s for the latter) is considered best practice. One key attribute of a released component is its version (e.g. 2.1.1) and it is here we can apply our first simple gate – ensure that we are using the correct versions of our dependent components.

Phase 2 – Static Analysis of the source code

Source code inspection is (or should be) a integral part of your software development process. Often this requires human beings(!) to perform formal code reviews who possess an understanding of the software requirements and application design. However, we can automate much of this using tooling integrated into the build process. Some examples of inspection that we can perform are

  • Adherence to organisational coding standards (e.g. all source files must start with a copyright statement, all functions should be commented)
  • Finding duplicated, or copied and pasted code statements.
  • Finding garden variety programming mistakes.
  • Adherence to architectural design rules.

Phase 2 – Compilation of the source code

If you are writing software using a programming language that needs to be compiled, such as Java or C++, this is obviously a very basic and essential gate to pass through.

Phase 4 – Execution of unit tests and test coverage analysis

We should always seek to execute the unit tests. Indeed, for some build management tools, this is the default setting and we can impose a gate that fails the build if unit tests do not pass.

The ability to write robust unit tests, that can be repeatedly executed in an automated fashion, in different environments, is one of the hallmarks of a good software developer IMHO. Wiring the execution of these tests into the CI process via the build tool, helps us to ensure that the tests do not contain dependencies on a developer’s local environment – a mistake more junior team members often make. However, how can we determine that the tests are actually doing something useful, and exercising appropriate functions or routines within the application code? This is accomplished using a code coverage analysis tool (such as Rcov), which can highlight those areas of the code-base untroubled by testing. Gates can be set as course-grained thresholds, e.g. trigger a build failure if less than 80% of all application code is being tested, or more granular configurations can be applied.

Phase 5 – Packaging the application

Although we normally don’t attribute a quality gate to this phase, it is often useful during the CI process to embed information into the packaged application for the purposes of traceability and provenance. For example, this can help identify the source code origin or ‘tag’ of an application deployed to a testing environment when defects are found.

Quality Gates

Quality Gates and Lifecycle Phases

Summary

Hopefully, I’ve demonstrated how CI, in addition to continuously integrating the source code developed by your team, can also provide a valuable feedback loop with respect to the quality of the software being created. In the next part, we’ll look into some options for applying ‘functional’ quality gates within the CI process using advanced testing automation.

Eclipse Metadata Redundancy and Build Tools

November 10, 2009

As this recent blog post and subsequent discussion illustrates, the choice of build tool for Java projects can still provoke furious debate. As a long time user of both Maven and Ant, I’d like to think I have a good perspective on the various pros and cons of both of them. In fact, this perspective led to the creation of Kundo, an alternative open source build tool that sought to scratch both mine and others particular build management itches.

To use either Ant or Maven in anger you need a decent level of experience and understanding – particularly in the case of Maven. I’ve always viewed Maven as a ‘platform’ rather than a simple build tool as it aggregates/conflates a great many features. This means that the learning curve can be quite steep. I often encounter less experienced Java developers who wonder why working with these tools is so problematic – why do they need to contact the designated ‘build guy’ (or girl) when things don’t go according to plan?

More Data Than We Need?

lots of data!

Those who are familiar with the build tool domain will be aware of the ‘impedance mismatch’ that can occur between the metadata model used by Eclipse and that used by Ant, and especially Maven. In the case of Maven, this is because a POM file effectively needs to be the ‘master’ for project dependency metadata. Both the maven-eclipse-plugin and m2eclipse are good tools that seek to address this problem but I think its fair to say neither have yet completely eliminated the fundamental underlying issue. With Ant, the metadata synchronisation is simpler, but it still requires awareness from developers and they often have to be comfortable with Ant references and simple types to ensure changes in the IDE do not break the Ant build. Often Ant builds these days use either¬†Ivy or the Maven Ant Tasks for dependency management anyway, so the problem can be much the same as with vanilla Maven in these types of projects. It is often not clear what the canonical metadata format should be and which tool ‘owns’ it.

Before I continue it is important to stress that I am focusing here solely on Eclipse, not alternatives such as NetBeans, IntelliJ etc that seek to address the problem in different ways.

Part of our mission with Mike is to lower the barrier of entry to using Continuous Integration (CI), so we have sought to include features that mean you don’t need to be a build tool guru to use our platform. Our ‘Eclipse build’ feature is a great example of this. It allows developers to simply add an Eclipse project to our hosted CI service without the need for an associated build.xml or pom.xml file. Then, at build time, Mike parses the project metadata and uses this within a vanilla life-cycle that processes resources, compiles production and test code, runs JUnit tests and creates an appropriate artefact. There are some constraints and conventions that need to be applied with this approach – at the time of writing the feature only supports the Dynamic Web project type using Apache Tomcat 5.5 or 6.0 runtimes – but here at Mike HQ we feel it allows you to be up and running with CI in very short order and we will be seeking to extend the range of project types, natures, builders etc that are supported. Of course, should you wish to subsequently own greater control over your CI build you can always add the appropriate Ant or Maven configuration at a later date and Mike will build that too.

From a pure CI perspective, this may seem to contravene the suggested approach in Martin Fowler’s original article – specifically the statement about IDE data being ‘fragile’. However, if all your developers are using a standardised version of Eclipse and apply a sensible approach to modifying the state of a project, many of the supposed issues can be avoided.

Aside from the Maven-specific tools mentioned above, it’s only fair to point out that there are other open source initiatives and projects that seek to address this same problem. In Kundo we sought to provide a ‘pluggable’ dependency management solution with one option allowing the use of Eclipse metadata as the source of your binary dependency locations. For this feature Kundo delegates to ant4eclipse. The aim of the ant4eclipse project is to avoid (or at least to reduce) the redundancy of Eclipse and Ant configurations and it consists of Ant tasks that are able to parse Eclipse metadata. More recently, the headlesseclipse project has emerged which seeks to solve the same problem by using the built-in AntRunner of Eclipse.

Finally, there is the B3 project proposal from the Eclipse community itself which, in their own words, has a goal to “develop a new generation of Eclipse technology to simplify software build and assembly”. I will be closely watching that proposal with interest to see if it finally addresses the build management metadata redundancy/synchronisation issue with Eclipse.