Continuous Integration: Hudson Setup

What Is Continuous Integration?

As anyone that has worked in a team of developers can attest, managing code repositories and code conflicts can be a huge pain. Developers can spend several hours after a merge managing and cleaning up conflicts.

As well as working with conflicts, manually building apps for testing or enterprise distribution can take a significant amount of time. Someone has to be responsible for keeping their repository up to date, managing the developer certificates and provisioning profiles, archiving the code, and uploading the IPA file to a server for distribution.

Because of the complexities involved in these procedures, developers are sometimes loathe to commit and build their code and will manage to make a build of the full project only once or twice a week.

CI allows the builds to be automatically started after every commit to the repository. This allows errors in the code and conflicts to be easily identified and resolved quickly and effectively. Although this is useful, by far the most useful feature that we can get from setting up a CI server is automating and distributing our builds. Imagine if all you had to do was type svn commit -m “Fixed the customer ID bug” and 30 seconds later the build was sitting on a website waiting to be downloaded by a tester. Setting up a CI can make that happen!

How It Works

For CI to work effectively, developers need to commit early and commit often (at least once a day). The CI server continually polls the repository to check if there has been an update. If it detects a change, it will begin building the project and performing any associated tasks.

If the build is successful, the team is notified of the successful build. If the build is not successful, the team is notified of:

• Who on the team broke the build
• What changes caused the build to break

In the event of a broken build, the team can quickly asses how the build broke and go about resolving the problem, and the problems that need fixing are small and easy to manage because we are committing every day instead of every week.

The Main Advantages of Continuous Integration

• Problems with the build are identified early.
• Identified problems are usually small issues that are easy to resolve.
• Automated building, signing and distribution of the app saves time.
• Constant access to the ‘latest’ build for testers.
• Unit tests can be run on every build, allowing developers to detect functional issues as well as compilation errors.

Unit testing is a world onto itself and unfortunately will not be covered in this tutorial. I encourage you to read up about using unit tests as not only part of your CI but a part of your development process.

Read More: Continuous integration with Jenkins

The Main Disadvantages of Continuous Integration

CI is certainly not for everyone. It can take a significant amount of time to set up a server for your needs. The CI server software is best installed and set up on a separate machine to that being used for development and the hardware requirements. That means extra costs for hardware.

Apache Tomcat

Apache Tomcat (or just Tomcat) is an open source web server that supports Java Servlet and JavaServer Pages. Tomcat is required because our CI software of choice (Hudson) is written in Java and needs a web server to run on. As you will soon find out, Tomcat is relatively easy to set up but configuring it for proper use can be a little tricky. We’ll go through it step by step.

Before proceed, make sure java is installed,

# java –version

Once you make sure java is installed, proceed to install tomcat, to download visit, https://tomcat.apache.org/download-90.cgi, pick tar.gz file.

# wget http://redrockdigimark.com/apachemirror/tomcat/tomcat-9/v9.0.6/src/apache-tomcat-9.0.6-src.tar.gz

Then create /usr/local/tomcat or /opt/tomcat and extract the file to this directory. (I am pick /usr/local/tomcat/)

Configure Tomcat

Now set user permission to the tomcat directory.

# chown –R username tomcat

Making changes like permissions or file ownership requires administrative privileges. Typing “sudo” before the command tells terminal we are an administrator. If we can prove it by entering a valid password, then the command is executed.

We also need to make some scripts executable, so the server can do its thing:

# chmod +x tomcat/bin/*.sh

This makes all the files that end in ‘.sh’ in tomcat’s bin folder executable.

Finally, before we start we need to increase the amount of virtual memory that tomcat can use. Its default amount is 64 mb and this is sometimes not enough, especially when we are working with large projects.

Find the “cataline.sh” file and open it in a text editor.

export JAVA_OPTS="-Xms128m -Xmx512m"

This line sets two variables. Xms defines the memory that your tomcat server starts with. Xmx sets the maximum amount of memory that your server can use.

We’re ready to start Tomcat up! To start the server, we need to execute a startup script found in tomcat’s bin folder. So, open a terminal and run the follow command:

# /usr/local/tomcat/bin/startup.sh

You can access it via http://Your_server_IP:8080, it will show you tomcat default page. And If you ever need to stop tomcat (restarting after a config edit for instance), all you need to do is run this script from the terminal:

# /usr/local/tomcat/bin/shutdown.sh

Hudson

Hudson is an open-source Continuous Integration server written in Java. It is one of the more popular CI servers used alongside Jenkins and Atlassian’s Bamboo. We’re using Hudson because:

• It’s easy to install and configure.
• It’s easy to use.
• Robust plugin support is available.
• It’s free!

Hudson is currently maintained by Oracle, who has stated that they intend to continue support and development for Hudson with the community.

What Does Hudson Do?

Hudson plays an important part of the CI process. It monitors the code repository and continually checks for updates. Once it determines there has been an update, it will do an update/pull and start the build. It is important to note that Hudson is not responsible for the build action itself. It can only call a script (which we will write) that will do the building and archiving. Once the script has started, Hudson will monitor the script. If it fails, it will report a broken build.

Download and Install Hudson

Setting up Hudson is very easy. First, navigate to Hudson’s website at http://hudson-ci.org/, and then click the download link for the latest production version (3.3.3 at the time of writing) this will download a *.war file.

Once the download is finished, rename the file to “hudson.war” and put the file into Tomcat’s “webapps” folder:

# wget http://ftp.jaist.ac.jp/pub/eclipse/hudson/war/hudson-3.3.3.war
# mv hudson-3.3.3.war /usr/local/tomcat/webapps/

If the server is currently running, restart it by running the shutdown script, wait a few seconds, and then run the startup script again. When that’s done, open a browser and navigate to:

http://localhost:8080/hudson

Hudson will tell you that it’s setting up. Once it’s done, you’ll see the main screen of Hudson.

 

First Time Startup

The first time you start Hudson, go to the home page to complete the installation:

1. Open a browser and go to http://localhost:8080 (change the port if you modified it during installation).
2. In the list of plugins that is presented, scroll down to find the Subversion, Maven and Maven SNAPSHOT Monitor options and select these options.
3. Scroll down to the bottom and click Install.
4. Click Finish to move to the Hudson home page.

The rest of the configuration in this section is continued from the Hudson home page.

Configuring the JDK

You must configure the JDK you intend to use it for direct Java build configurations. To configure:

1. Log in to Hudson: http://HOSTNAME:HUDSON_PORT

2. Navigate to Manage Hudson, then Configure System.
3. In the Configure System screen, scroll down to the JDK section and click Add JDK, uncheck the option Install automatically and then enter a name, for example, jdkx.x.x. and add the complete path of your installed JDK.

For ex: /ciroot/product_binaries/jdkx.x.x.xx.

4. Scroll down to the bottom of the page and click Save.

Specifying the Maven Home

You must specify the Maven  location so that Hudson knows where Maven is located. To do so:

2. Log in to Hudson: http://HOSTNAME:HUDSON_PORT
3. Navigate to Manage Hudson, then Configure System.
4. On the Configure System screen, scroll down to the section Maven.
5. Click Add Maven, then deselect the option Install automatically and enter a name and the fill path to the Maven installation, as shown in the following image:
6. Scroll down to the bottom of the page and click Save.

Setting Up Maven for Use by Hudson

To utilize Maven settings from Hudson, embed the settings.xml content into a settings object in Hudson’s global Maven configuration:

1. Log in to Hudson:  http://HOSTNAME:HUDSON_PORT

2. Go to Manage Hudson, then Maven 3 Configuration.
3. Click Add.
4. For Type, select SETTINGS.
5. Provide a name and optional description.
6. Find the Settings.xml on your file system that you have configured and copy the contents into the large text field at the bottom of the page. It is located in the /$HOME/.m2/settings.xml directory.
7. Click Save.

Installing Hudson Plug-Ins

Hudson jobs may require job-specific customization of environment variables. Because Hudson does not support this by default, you must install an additional plug-in. To install the plug-in:

1. Log in to Hudson: http://HOSTNAME:HUDSON_PORT
2. Go to Manage Hudson, then Manage Plugins.
3. Select Available.
4. Select Hudson Setenv Plugin.
5. Click Install.
6. After the installation completes, use the restart option in Hudson to enable the plug-in.

Integrating the Repository

To configure automatic builds when changes are checked in, you must configure Hudson to monitor the artifact repository for SNAPSHOT deployment changes. Such changes trigger builds of affected components that have dependencies on the changed artifacts. To configure Hudson to monitor the artifact repository:

1. Log in to Hudson: http://HOSTNAME:HUDSON_PORT
2. Navigate to Manage Hudson, then System Configuration.
3. In the main system configuration panel under System Configuration, select Maven 3 SNAPSHOT Monitor. In the Archiva configuration instructions, you must have created a continuous integration specific user for continuous integration server access to the repository. Enter the path to Maven repository.
   1. Set the Username and Password for the continuous integration user.