Agility & CI – An OSGi Use Case

Back to Contents

The following real-world use case demonstrates a successful realization of these principles.

Siemens Corporate Technology Research group is comprised of a number of engineers with diverse skills spanning computer science, mathematics, physics, mechanical and electrical engineering. The group provides solutions to Siemens business units based on neural network and other machine learning algorithms. As Siemens’ business units require working examples rather than paper concepts, Siemens Corporate Technology Research are required to rapidly prototype potential solutions. The resultant business solutions are composed from the repository of re-usable components.

Agility & Modularity: Siemens’ Product Repository

Figure 9: Siemens’ Product Repository

In a presentation entitled “Workflow for Development, Release and Versioning with OSGi/Bndtools: Real World Challenges,”17 the Siemens team presented both the business drivers and the resultant solution that met these objects via a highly agile OSGi based continuous integration environment.

The Siemens’ team stated the following business objectives:

  1. Build Repeatability: It must be possible to ensure that old versions of products can always be rebuilt from exactly the same set of sources and dependencies, even many years in the future. This would allow Siemens to continue supporting multiple versions of released software that have gone out to different customers.
  2. Reliable Versioning: Siemens required the ability to quickly and reliably assemble a set of components (including their own software along with third party and open source) and have a high degree of confidence that this assembly would work.
  3. Full Traceability I: It must be possible to ensure that the released software artifacts are always exactly the same artifacts that were tested by QA. Specifically, the solution must avoid the necessity to rebuild in order to advance from the testing state into the released state.
  4. Full Traceability II: It must be possible to trace the artifact’s heritage back to its original sources and dependencies.

To achieve rapid prototyping, Siemens required a repository of software components, including a generic framework and an algorithm toolbox. OSGi was chosen as the enabling modularity framework, this decision based upon the maturity of OSGi technology, the open industry specifications that underpin OSGi implementations, and the technology governance provided by the OSGI Alliance. Also, OSGi semantic versioning, fully leveraged within semantic version aware development and build processes, would be critical for achieving the stated business objectives.

The solution needed to work with standard developer tooling, i.e. Java with Eclipse, have strong support for OSGi, support the concept of multiple repositories and provide a basis for continuous integration (via Jenkins) to build, test and create deployable artifacts.

For these reasons, the Bndtools project was selected (see

Agility & Modularity: Siemens’ OSGi/Bndtools based continuous integration environment

Figure 10: Siemens’ OSGi/Bndtools based continuous integration environment

The resultant Bndtools based continuous integration solution is shown in Figure 10.

  1. Via the Eclipse/Bndtools IDE Siemens’ developers maintain their own local workspace and check results into their local SVN source repository; this SVN repository contains only work in progress (WIP).
  2. Siemens’ developers are able to include one or more read-only OSGi Bundle Repositories (a.k.a. OBR) in their development environment. The primary repository is the team’s Read-Only Development Repository, but repositories used by other development teams, a repository containing standardized Siemens’ components and approved third-party and/or OSS repositories, might be included.
  3. At the point the WIP item is completed and ready for release to the local development repository, Bndtools automatically calculates the correct semantic version update based on the delta of changes in the current code base (N) with respect to the previous released version (N-1). The Jenkins build server builds and releases the correct semantic-versioned artifact to the development repository.
  4. Once released to the Read-Only Development Repository, the OSGi bundle is available for use by all developers with access to that repository. While the bundle remains unreleased, subsequent code updates can be applied, the bundle re-built with the semantic version again calculated against the same N-1 baseline.
  5. At the point the artifact is released from the development repository to QA, it now defines the new baseline. All subsequent updates to the N+1 version of the OSGi bundle are now baselined by Bndtools against the newly released version.

Bndtools’ sophisticated semantic versioning behaviors mean that appropriate semantic version changes are automatically calculated, so conveying the nature of the change and offloading this concern from the developer.

This strategy proved successful in delivering a highly agile development and continuous integration environment for Siemens’ developers that also met the business’ re-use and governance objectives.

17 The 2012 OSGi community event (

Next page