When implementing automated Continuous Integration (CI), you have a number of CI servers and tools from which to choose. Here, one server (Hudson) and many tools/platforms (e.g., Linux, Java, Ant, Subversion, MySQL and Sonar) are covered and linked to CI Patterns and Antipatterns (see CI Patterns and Antipatterns Refcard #84). The goal is to demonstrate how you can use a CI server to create working software with every change. Furthermore, team members need to be notified when something goes wrong, a vital element to CI. It is important to note that while this Refcard uses the Java platform and Linux for example purposes, servers and tools do exist that support other development platforms (e.g., CruiseControl.NET, cruisecontrol.rb, MSBuild and so on).
The patterns below are from the CI patterns and anti-patterns Refcard (#84) that are relevant to ci servers and tools and are covered in this Refcard.
|Repository||Commit all files to a version-control repository|
|Automated Build||Automate all activities to build software from source without manual configuration|
|Minimal Dependencies||Reduce pre-installed tool dependencies to the bare minimum|
|Label Build||Label the build with unique name|
|Continuous Feedback||Send automated feedback from CI server to development team|
|Independent Buil||Separate build scripts from the IDE|
|Dedicated Machine||Run builds on a separate dedicated machine|
|Continuous Inspection||Run automated code analysis to find common problems|
|Build Threshold||Use thresholds to notify team members of code aberrations|
|Headless Execution||Securely interface with multiple machines without typing a command|
|Protected Configuration||Files are shared by authorized team members only|
|Automated Tests||Write an automated test for each unique path|
Minimal Dependencies Pattern: Reduce pre-installed tool dependencies to the bare minimum. Reduce required environment variables from the Automated Build and Scripted Deployment to the bare minimum.
Antipatterns: Requiring developer to define and configure environment variables. Requiring developer to install numerous tools in order for the build/deployment to work.
Configuring Environment Variables
Download the Java development kit zip distribution to a temporary directory on your workstation and extract the file to a directory such as /usr.
Download Ant build tool zip distribution to a temporary directory on your machine and extract the file to a directory such as usr/local.
Create or open your user profile by using the vi editor as shown below to open/create a .bash_profile file.
Add environment information to the .bash_profile file. Examples are shown below.
ANT_HOME=/usr/local/ant-1.7.0 JAVA_HOME=/usr/jdk1.5.0_10/ HUDSON_HOME=$HOME/hudson_data export ANT_HOME JAVA_HOME HUDSON_HOME export PATH=$ANT_HOME/bin:$JAVA_HOME/bin:$PATH
Save the profile to the system by sourcing the profile as shown below.
Test Java and Ant were installed by typing:
java version ant -version
Install MySQL using yum as shown here. If you are using another flavor of Linux that doesn't support yum, you can use rpm. Or, if you're using Windows, you can download the MySQL installation from http://dev.mysql.com/downloads/ and ensure MySQL is available in your system path.
yum -y install mysql mysql-server
Start the MySQL server. An example is shown below.
Test MySQL was installed by typing:
Install Version-Control System Client
Install Subversion client software using yum.
yum -y install subversion
Test svn client installation by typing:
Install Tomcat Web Container
Download Tomcat by visiting Apache Tomcat's download site at:
Save the zip file to the machine where Tomcat will be hosted (e.g. apache-tomcat-6.0.20.zip). Go to the command prompt on the machine and type:
Start the Tomcat server by typing:
cd [tomcat-download-location]/apache-tomcat-6.0.20/bin chmod ugo+rx *.sh ./startup.sh
Test Tomcat is running by launching your browser and typing:
Dedicated Machine Pattern: Run builds on a separate dedicated machine.
Antipatterns: Existing environmental and configuration assumptions can lead to the “but it works on my machine” problem.
When considering which CI server to use, consider the following server evaluation features:
|Version-control system integration||If a tool doesn't support your particular versioncontrol system, do you really want to write a custom integration for it?|
|Build-tool integration||In choosing a CI server, you need to consider which build tools you already use or will be using. For Java™ programming, there are a couple of clear favorites, Ant and Maven, and most all CI tools support them. If your build system isn't either Ant or Maven, does the CI tool support the ability to run a program from the command line?|
|Feedback and reporting||Consider the old adage, “If a tree falls in the forest, does anyone hear it?” If a build fails, does anyone hear about it? If no one does, what's the purpose of having a CI tool? All CI tools offer some notification mechanism, but which one will work best for you? E-mail? Instant messenger? RSS?|
|Labeling||Some development teams like to track builds by giving them unique labels so they can refer to a particular build instance at a later date. If this is important to you, be aware that only some CI servers provide this capability.|
|Project dependencies||In some cases, after you build one project, you may need to build another dependent project. Certain CI servers support this feature and some don't.|
|Ease of extensibility||How easy is it to extend the current functionality of the tool? Are there plug-ins that allow for simple extension or is it always a code change?|
One CI server that satisfies these criteria well is Hudson, which will be the focus here. Below you will learn how to download, install, configure Hudson, and configure a Hudson job with CI patterns in mind.
Download the latest from the website to your machine where Hudson will be hosted. An example is shown below: http://hudson-ci.org/latest/hudson.war
To install Hudson you will need Java version 1.5 or higher and the Hudson installation file, which is a Java EE Web archive (WAR) file. Typically, you can use a web container, such as Tomcat, and deploy the hudson.war file to the web container.
Copy the Hudson.war to Tomcat.
cd ~/hudson/application/webapps/apache-tomcat-6.0.20/webapps cp [hudson-download-location]/hudson.war ~/hudson/ application/webapps/apache-tomcat-6.0.20/webapps
Restart the Tomcat container
cd ~/hudson/application/webapps/apache-tomcat-6.0.20/bin ./shutdown.sh ./startup.sh
Verify the Hudson CI server is running by launching a web browser and typing:
The Hudson server dashboard should be displayed and look similar to the following figure.
You will need to configure Hudson to refer to the Java JDK and Ant installation on the machine where you have installed Hudson. Go to the main Hudson page and click on the Manage Hudson link. Click Configure System. To configure JDK and Ant instances click on the Add button under the relevant sections, which will display a set of fields for configuration.
Configuring the Email Server Information
An example of configuring how email is sent from your Hudson server for all jobs is shown below. After applying the changes, click the Save button.
After installing and configuring a Hudson server, you can create one or more Hudson jobs. A job polls a version-control repository for changes and runs a build to create software. The corresponding CI patterns are described below.
Automated Build Pattern: Automate all activities to build software from source without manual configuration. Create build scripts that are decoupled from IDEs. Later, these build scripts will be executed by a CI system so that software is built at every repository change.
Antipatterns: Continually repeating the same processes with manual builds or partially automated builds requiring numerous manual configuration activities.
Headless Execution Pattern: Securely interface with multiple machines without typing a command.
Antipatterns: People manually access machines by logging into each of the machines as different users; then they copy files, configure values, and so on.
Independent Build Pattern: Separate build scripts from the IDE. Create build scripts that are decoupled from IDEs. Later, these build scripts will be executed by a CI system so that software is built at every repository change.
Antipatterns: Automated Build relies on IDE settings. Build cannot run from the command line.
Protected Configuration Pattern: Using the repository, files are shared by authorized team members only.
Antipatterns: Files are managed on team members' machines or stored on shared drives accessible by authorized team members.
Continuous Inspection Pattern: Run automated code analysis to find common problems. Have these tools run as part of continuous integration or periodic builds.
Antipatterns: Long, manual code reviews or no code reviews.
From the Hudson dashboard, select the job you are configuring, then select the Configure link. One of the configuration options is called Source Code Management. From this section, select the Subversion radio button. Then, you will enter the Subversion URL where that contains the build file you're using to run your build in the Repository URL field. To indicate the directory name where this repository will be represented locally on the Hudson server, enter a value in the Local module directory field. Enter this information and click the Save button. The figure below demonstrates these actions.
From the Hudson dashboard, select the job you are configuring, and then select the Configure link. One of the configuration options is called Build Triggers. Select the Poll SCM checkbox and enter the 0,10,20,30,40,50 * * * * in the Schedule text area and click the Save button. This means that Hudson will check for any changes to your Subversion repository every 10 minutes. If no changes are found, it won't run a build. If it discovers changes, it runs the build file and targets described in the next section.
From the Hudson dashboard, select the job you are configuring, then select the Configure link. One of the configuration options is called Build. Under Invoke Ant, enter values in the Targets and Build File fields. The targets are a space-delimited list of targets you wish to call for a particular build file the build file name is relative to the Repository URL you configured in the configure version-control repository section above. Enter this information and click the Save button.
The Continuous Inspection pattern is an approach to running automated code analysis as part of a build in order to find code quality problems. Continuous Inspection can help reduce the time spent in Long, manual code review sessions. While there are numerous tools you can use to implement this pattern, this example shows a tool called Sonar, which collects the information from several code quality analysis tools into comprehensive graphs and reports.
Sonar provides code quality reports and graphs using several of the widely used open source static analysis tools on the market. The benefit is that Sonar aggregates the data and displays it as information in an easy-to-understand way. Using Sonar is quite simple in Hudson by downloading Hudson's Sonar Plugin.
Add the Sonar plugin to Hudson
From the main Hudson dashboard, Select the Manage Hudson link, then Manage Plugins. From Manage Plugins, select the Available tab. From the numerous plugins, select the Hudson Sonar Plugin checkbox and select the Install button.
Restart the Tomcat container
Go back to the Manage Hudson link and select the Prepare for Shutdown option. This prevents any other jobs from running while you restart the server. Because the Tomcat server is hosting the Hudson CI application, you will access the host where Tomcat is installed and go to the Tomcat bin directory.
cd ~/hudson/application/webapps/apache-tomcat-6.0.20/bin ./shutdown.sh ./startup.sh
To verify the Sonar Plugin was installed. Go back to the main Hudson dashboard and Select the Manage Hudson link, then select Manage Plugins. From here, select the Installed tab. You should see the Sonar Plugin listed on this tab.
To configure Sonar for a particular job, select a specific Hudson job and then select Configure. From the Post-build Actions section on this page, you will see a Sonar checkbox. Select this checkbox and click the Save button. Typically, you will also need to configure other project-specific options as well. This is illustrated in the screenshot below.
An example of a dashboard report provided by Sonar is shown below.
Automated tests Pattern: Write an automated test for each unique path.
Antipatterns: Not running tests, no regression tests, manual testing
Once you've written some texts, you can configure your CI server Hudson, in this case to display the unit test results. The figure below shows the checkbox to select and an example of the fileset include it uses the xml file to display the test reports on the Hudson dashboard.
Once you've written some automated tests, you can use a CI server tool like Hudson to determine your overall code coverage - either in the form of line or branch coverage. There are several code coverage tools including Emma, Cobertura, NCover, Clover, etc. This example shows how to configure Hudson to run your existing Cobertura reports. The example below assumes that you have already installed the Cobertura plugin for Hudson. Once this plugin has been installed, the Publish Cobertura Coverage Report checkbox is displayed. NOTE: Sonar aggregates Cobertura results as well.
Build Threshold Pattern: Notify team members of code aberrations such as low code coverage or high cyclomatic complexity. Fail a build when a project rule is violated. Use continuous feedback mechanisms to notify team members.
Antipatterns: waiting for numerous code quality issues to go undiscovered or build up to the point where software maintenance increases or functional features are affected.
Hudson provides a way to fail the build based on specific thresholds. This is an implementation of the build threshold pattern. In the example below, you can see that Hudson lets you configure method, line and conditional code coverage targets. If the code in the build doesn't meet these criteria, the build fails. This is an effective to discover and fix potential problems earlier in the development process.
Continuous Feedback Pattern: Sending automated feedback from CI server to development team. Setting up the server to send email notifications will be covered here, but there are other notification mechanisms available (e.g., RSS, SMS, X10, Monitors, Web Notifiers).
Antipatterns: Minimal feedback, which prevents action from occurring. Receiving spam feedback, which causes people to ignore messages.
From the Hudson dashboard, select the job you are configuring, then select the Configure link. One of the configuration options is called Post-build Actions. Then, select the E-mail Notification checkbox. Here you can enter the email addresses for the people who will receive emails after builds are run. You can choose to send an email for every unstable build and/or to send separate emails to individuals who broke the build. The latter option requires you configure your domain suffix in the Hudson system configuration (See the configuring the email server information section above).
The following are not recommended tools, but recommended tool types - with example tools that you might use. There are many more tools available than the list provided here. It's important to realize that you need numerous types of tools to effectively create working software in a single command with every change applied to the version-control repository.
|Tool Name||Tool Type||Platform|
|Continuous Integration Server||
|Code Quality Static Analysis||
|Automated Unit, Database Seeding, Functional, Build, Load, Web Services Testing||Java|
|Dependency Manager, Repository||
|Liquibase||Automated Database Upgrades||
|Java Secure Channel||Deployment||Java|
|Sonar||Code Quality Reporting & Aggregation||Java|