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.
Configure Version-Control Repository
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.
Set the Polling Frequency
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.
Configure the Build Target and Build File Location
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.
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.