Did you now that Developer Studio could be used jointly with a continuous integration system, in order to improve your software quality? When multiple developers work on the project, this is a great way to ensure consistency and robustness for your "official" builds.

Integration environment is indeed separated from multiple developers configurations, making sure that integration builds are always performed the same way, with a stable system configuration.

 
Here are the main steps to easily reach a functional Continuous Integration system for your Open AT app:

 

Step 1: Setup your Continuous Integration environment
 
There are many of them; at Sierra Wireless we're using Hudson and Jenkins systems. They just install and run in one click -- easy and powerful.
On the same system, install Developer Studio. You can even do it on Linux systems, even in a console. Just follow the release notes instructions.
 
Step 2: Share your project in Configuration Management.
 
Choose your SCM system (SVN, Git or whatever...). But just be careful to choose one which can easily integrates with both Developer Studio (Eclipse) and the Continuous Integration system. Git and SVN are good examples.
Then share your project on the source repository, entirely, with the (hidden) configuration files, but without the build output directories.
 
Step 3: Setup your job to fetch source code
 
Create the build job on the CI server, and configure it to fetch the source code from the repository. This can be done pretty easily, most of time by just entering your repository URL, your credentials and the path to the Open AT project source code.
 
Step 4: Check packages dependencies
 
Open AT projects need a set of packages to build correctly. These packages have to be installed in the Developer Studio instance which has been setup on the CI server.
You have two options:

• either you do it manually, with Developer Studio GUI
• or you automate packages installation in the build job itself.

This second option can be achieved by using the Package Manager headless application (refer to Developer Studio online help for more information on how to use this application).

E.g. you can imagine persist a shell script in your Open AT project source code repository, invoking the Package Manager to install the required packages: just add a build step in the job to launch the script, and the Package Manager will ensure (on each run) that the requires dependencies will be installed in Developer Studio scope. Obviously, once packages are installed a first time, they won't be installed again each time the build is triggered.

 
Step 5: Build the project
 

You can now configure your job to ask Developer Studio to build your project, by simply invoking the Build Manager headless application (refer to Developer Studio online help for more information on how to use this application). You should use before a shell command to clear the workspace directory, and then invoke the manager to make it import the project from the fetched source code, and build it using the required configuration.

Note that you can also add the build command in the same shell script you used to configure the package dependencies.

Please find below an example of shell script you could persist in your project, ready to be invoked by the CI server:
 

#!/bin/bash
 
# Setup environment, assuming that:
# $WORKSPACE is defined by the CI server as the job's workspace,
# $DSROOT is the Developer Studio installation directory
# ${PathToRepository} is the path to the software package repository containing project requirements
srcPath=$WORKSPACE/src
outPath=$WORKSPACE/out
 
# Clear workspace
rm -Rf $outPath
 
# Setup package dependencies
$DSROOT/m2mstudio -data $outPath -nosplash -consoleLog -application com.wavecom.spm.headless.packagemanager -installPacks jar:file:${PathToRepository}!/
 
# Trigger build for MyProject
$DSROOT/m2mstudio -data $outPath -nosplash -consoleLog -application com.wavecom.openat.ide.ebs.build.core.buildmanager -import $srcPath/MyProject -build MyProject -config [Target]_ARM_EABI_GCC_Debug

Here we are: the CI server is now configured to build your Open AT application directly from the source code shared in the Configuration Management repository.

 

In order to go further on the topic, you'll have to wonder how often you want to poll the source code repository (hourly, nightly, or every 5 minutes if you want), knowing that a build will be actually triggered only if source code have changed since the last build!

You can also imagine to setup several jobs if your application is composed of several libraries, (re)building each part only when necessary (you can configure dependencies between jobs, e.g. to trigger the application build when one of its component has changed).

Enjoy using CI systems with Developer Studio!

 

---

Comment on Forum