This blog item gives you an inside scoop into the continuous integration environment at JTeam. You’ll learn about the why, what and how of continuous integration. The tools we use are mainly open source.
Why continuous integration?
A number of years a go not many people new the term continuous integration. That has changed a lot. All people at JTeam know what it is about and all projects use an environment that is set up to actually do continuous integration. For those that do not know what continuous integration is and those that need a short recap, we briefly explain what we think continuous integration is. Let’s start with the definition from Martin Fowler:
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least dail￼y – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly
Key to continuous integration is delivering high quality artifacts. It is not the silver bullet, developers still need to create great code, but using a good continuous integration process helps finding bugs. Checking your quality standards a long the way increases the effect. Of course extra actions are still necessary. You can think about actions like: manual code reviews, performance tests, functional tests, etc.
JTeam has been using continuous integration from the start. Recently we implemented the second version of our continuous integration environment. We introduced new tools, the process however stayed the same.
What do you need?
Continuous integration is about a lot of different things. So lets review them here. First of all, we have sources and a build. We tend to write a lot of java code, but we also need configuration files, html, style sheets, etc. With maven the way to structure your files has been standardized. We are using ￼maven 2 for all our projects. Maven makes the life of a developer a lot more efficient while doing the normal tasks. Team leads and project leads also have reasons to implement maven in there projects. Maven has a lot of plugins that enable the projects spectators to see what is happening at the project.
Most of our projects are executed by more than one person, therefore a good source repository becomes very important. The source repository gives us more advantages, which I’ll talk about later. Within JTeam we have chosen to use subversion for storing the sources of the projects.
You can share sources and you have an automated build. Of course maven integrates very well with some IDE’s and it integrates kinda with some others. One of the important features of Maven is that it downloads dependencies from an online repository. Dependencies are libraries your project depends on. To limit network bandwidth, to store locally created libraries and to make libraries that are not available in an online repository accessible, you can connect to an internal repository. In maven this is called a proxy or a mirror. At JTeam we use a repository called Artifactory. Artifactory is a product from jfrog.
Having an automated build is not enough for good continuous integration. The automated build must be a continuous build. There are a lot of tools available that can give you continuous build. Some examples are : Hudson, CruiseControl and Luntbuild. We use Teamcity from Jetbrains to integrate all subversion checkins, run all the tests and every night run the maven reports. These maven reports are then published on a server so everybody can check the current status of the project. Teamcity is not open source and, there is a free license available, we use the commercial license. I explain later on why.
The following image gives you an overview of all services you need to have available for you to use in your project. The image shows more tools then I have discussed so far. They are not directly related to continuous integration, still they are very important for you when doing projects. Jira is about keeping track of requirements, issues and time estimations as well as time spend. Confluence is our knowledge base in which we document all our knowledge we gather while doing projects. Both jira and confluence are products from atlassian and very well known.
A last thing I would like to mention is a plugin for maven, the dashboard plugin. We are using this plugin now for a few projects and it gives some nice overviews. Graphical views of checkstyle, pmd, cobertura. When combining it with a database there is also the possibility of historical data, which is working very nice as well. You can find more information on the website including a lot of sample reports. http://mojo.codehaus.org/dashboard-maven-plugin/
2 thoughts on “Continuous Integration (Again)”
Hi Koen, great that you like the new layout. I just love the way this works in wordpress 🙂
As for the question about TeamCity, for me the biggest advantage is the pre-commit build. You can perform a build on the server without actually committing your code. I also like the integration with intellij (and eclipse) where you can click a test in the teamcity website and open that test in your IDE. Furthermore, the interface just works right, the options are good and not to extensive. But to me Hudson is by far the second best, in our environment Teamcity with it’s pre build commit just wins.
First nice new layout it looks very cool.
Afther reading your blog I googeld around for information abound teamcity, I found a lot but not a real advantage compare to Hudson. Why you are using teamcity in state of hudson? I’m a big fan of Hudson.
Comments are closed.