Tag Archives: Continuous Integration

Using Jenkins for Tolven Deployment and Continuous Integration

Jenkins is a common tool used for automating building and deploying software.  With a little configuration, Jenkins can be a powerful tool for developing on the Tolven platform (or the Neuron Health platform).  Building and deploying plugins in the Tolven environment is a time-consuming process,  so automating it can provide considerable time savings in the long run.  Plus, setting up a continuous integration instance ensures you always have the current code deployed, speeding up QA.  However, using Jenkins to deploy Tolven requires a little ingenuity and finesse.



Before we begin configuring Jenkins with Tolven, you should have both installed (see our Installation Guide).  As part of the Tolven installation procedure, you should also be familiar with the ant scripts that are used in deploying Tolven.  Finally, to use Jenkins for continuous integration, you will need to have a version control system , such as Subversion, set up to contain your code.  Note that this code repository does not need to be on the same physical machine as Jenkins, but you will need to provide connection information, including credentials if required, to Jenkins when setting up the project.

First, make sure the Ant Plugin is installed in the Jenkins Plugin Manager.  This will allow Jenkins to execute the Tolven ant installation scripts.  Now we will need to create a Jenkins project to build the plugins being developed.  For continuous integration, the project should be configured to poll the source control repository on some interval and check out the entire development environment file structure (there are some supporting ant scripts that must be present for the build scripts to work).  We will use the “Invoke Ant” build step for each task in this plugin.  The project should execute the deploy-to-local-repository target for each plugin being built.  Note that you will need to specify the path for each build.xml file under the advanced section, since there are separate build files for each plugin.


Next, the updateDevLib target from the plugin\managePlugins.xml build file should be triggered.  This target ensures the DevLib gets updated with the newly compiled code.


Now each of the plugins has been built and is ready to be deployed.  Note that in some special circumstances, if you add new code to a plugin and a dependency on that code to another plugin, this build script will fail because the devLib is not updated after each plugin is built.  You could resolve this by adding the updateDevLib target between each deploy-to-local-repository target, but this would be overkill in most situations, and negatively affect the time required to complete the build.

For the second Jenkins project, we will be redeploying the Tolven application with the changes we just built.  It should be triggered by the successful completion of the first project.  Before this project can work, however, we need to perform some configuration on the Tolven instance.  Open plugins.xml in the tolven-config directory, and look for the properties “installLdap,” “configLdap,” and “installAppserver.”  They should all be set to false.  If the properties do not exist, add the following:

<property name="include">

     <property name="installLdap" value="false" />

     <property name="configLdap" value="false" />

     <property name="installAppserver" value="false" />


Now back to the Jenkins project.  The first step in the project is to shut down the Tovlen application, which should already be running.  If it’s not, it should be started manually prior to starting the automatic build.  Add a build step to execute either a batch command (Windows) or a shell script (Linux), then add commands to change directories to the tolven/tolven-jboss6/bin directory, and run the stopTolvenJBoss script (there are both .bat and .sh versions).


Next, add an “Invoke Ant” build step to execute the install-config-tolven target of the build file located in the tolven-installer directory under the current snapshot (for example, tolven/snapshots/V21_20140314_ONC_snapshot/tolven-installer/build.xml).  Note that this project can take quite a while to complete, so be patient.

With these two projects, you have the basis for continuous integration and automatic deployment with Tolven or Neuron Health.  These projects can be further expanded to include automatic unit testing, as well as other tasks you may wish to perform.  I would like to point out that setting up Jenkins with Tolven or Neuron Health on linux does require some additional considerations, mostly dealing with file permissions.  This will be a future topic of discussion.