Continuous Integration for Operation Orchestration Developers
With devops becoming a hot topic this days, and the nice new features of OO 10 I was wondering whether I can automate my Operation Orchestration content pack builds with Jenkins. As OO Developer working in a big team I also wanted to have an artifact repository, where I could keep my successful builds and automate the content upload to be triggered by the developers an automated fashion when they decide they are ready with a feature.
Building The Platform
I chose to do that using some open source products I was already familiar with. Those were Nexus, to store the compiled artifacts (content packs), SCMManager (to store the SVN and GIT repositories and trigger the build) and Jenkins, as the continuous integration tool, that orchestrates the solution. I installed them on an Ubuntu box and was ready for action.
For HPOO I was using version 10.20 of the studio and central, although it should work also for later version using svn, and with slight modifications git.
Setting up your source code repository
Setting source code repository with SCMmanager is relatively easy, compared to any other Subversion software I’ve been running lately.
The first thing you do with is to create some usernames and groups you would like to use with it. I gathered all my team emails, and created separate username and password for them. I put them later in a group, so it is easy to give them access to the repository. Put proper emails there to be able to send later on commit emails on every commit. After that it is good idea to have some groups for all your users. Both those actions are executed under the Users and Groups Menu.
Create an SVN repository by going to Repository Menu under Navigation and choosing Add. Supply the necessary information and after you are good to go open permissions tab of your repository and add your group.
After your repository is ready, you can integrate your HPOO Studio with it, and do the initial commit of your project.
Notifications on commit
To enable mail notification go to Plugins menu, and click install on the scm-notify-plugin. I found commit emails quite useful when I want to notify lots of people there is new version and they need to refresh their local copies from the central repository.
In order for the messages to work the Mail Configuration section in the Config->General Menu has to be filled in with working SMTP server that allows relay of your domain. After Plugin installation you will get under the repository a new tab called Notification. There you go and setup all users you want to notify on commit.
Setting up your Artifact Repository
After successful build and deployment to HPOO we want to keep somewhere the successfully deployed artifact. For this we will use the Nexus Artifact repository where we can create separate repositories for all different stages (DEV/QA/PROD). Create one artifact for the build stage of type Maven2. If you want to be able to redeploy one and the same artifact version set the deployment policy to Redeploy. I named my repository mpc-build but you can name yours as you like.
Connecting them all together with Jenkins
After having working SCM and Nexus it is time to connect them together. The basic process we are trying to automate looks like this:
- Developer commits code in SVN with a specific message
- SCM runs a post-commit script that kicks in a build job inside Jenkins
- Jenkins job builds content pack and uploads it to Operation Orchestration
- If Upload was successful it uploads the content pack to Artifact Repository
- If Upload was not successful it sends a build failure notification
Creating the Jenkins BUILD job
Log in to Jenkins and create a Free Style Project. Click on the “This build is parameterized” and create the String Parameters:
MAJOR_VERSION, MINOR_VERSION, NEXUS_USER, NEXUS_PASS, NEXUS_URL and NEXUS_REPOSITORY. As my project had MAJOR and MINOR version set to 4.1 and adding just the SVN revision number to it, i had hard-coded them. The same applies also to the NEXUS_URL which i set to http://localhost:8080, NEXUS_REPOSITORY which in my case was named mpc-build and NEXUS_USER and NEXUS_PASS.
After you finish with the initial parameters for the job move to the “Source Code Management” section and configure your Subversion repository you have created in SCM.
Next step is to tell Jenkins to poll SCM for changes. That is workaround to be able to use a post-commit hook — we are not going to actually really poll the SCM on a regular basic. Go down to the Build Trigger section and configure the Poll SCM interval. The interval syntax is very similar to the one used by cron, so everyone that works with Unix like systems will be very familiar with it. There is a good help section so make sure you read that one first and don’t configure the poll interval too often.
We have finished with the SCM section and can now checkout the code to the Jenkins job workspace. Next step is to create a content pack out of it. I tried to find out how to do that with maven, the same way the Studio does it, but was unable to find a good guide, apart from the HPOO @Action developer guides. (There is a separate build tool that was developed around HPOO 10.60 called oosha, check it out). As I was not making any java or .net operations, just packing up simple flows that refer to existing operations I did some tests and found out, all i need is to create a zip file, with one properties file inside. So far so good that can be easily done with 2 simple commands. One to create the properties file and another one to zip the content pack.
In the Build section create 2 shell operations that will create the properties file and zip the content pack.
The first operation:
It enters the project folder I checked out (MPC) and recreates the contentpack.properties. The best way to proceed here is to create first one content pack with HPOO Studio, rename it to zip and look inside the contentpack.properties file. The thing I carry from there and you can see hard-coded is the content.pack.uuid.
The rest of the data is up you you to configure, depending on your project requirements and guidelines.
The second operation creates a content pack (excluding some of the folders you don’t need).
After that you are ready to upload your content pack. We run again a shell command, this time using curl and upload the content pack in HPOO.
Next step is to upload the content pack to the nexus repository too. As we want to do that only if the upload to HPOO was successful we will create conditional step, that gets executed only if the overall job build status is success. You will have to install the “Run Condition Plugin” in Jenkins.
The final step of our Jenkins job will be to send a build failure message. This is done in the post-build section using the E-mail Notification plugin.
You can run some builds manually to test the setup, and after everything works smoothly you can proceed to
SCM post-commit-hook configuration
We would like the developers to be able to kick in the whole process from their IDE (HPOO Studio). However we don’t want to create build on every commit, but only when we are ready with a feature and want to test. This is done by using a post-commit hook script, that triggers the Jenkins build only if the code word RUN_BUILD is somewhere in the commit message. For this we use the following script.
The script should be placed in the repository hook folder and marked as executable.
Testing all together
Change something in your HPOO job and commit your change. Put the keyword RUN_BUILD somewhere in your commit message:
Log in to Jenkins and see if the build process is triggered.
Log in to HPOO and see if the content pack is uploaded.
As my next step in my plans sits testing.I have developed a tool to do OO unit testing and need to integrate it as part of my build job.