Agile and Structural modularity (iii) real-world challenges

Real-World challenges: Workflow based on Osgi/bndtools development, release, and Versioning

The first article in the series introduced the fundamental relationship between structural modularity and agility, and in the second we learned how to use OSGi to implement highly agile and highly maintainable software systems.

The third article is based on the title "Real-World challenges: workflows based on Osgi/bndtools development, publishing, and Versioning" (Workflow for Development, releases and Versioning with OSGi/ Bndtools:real World Challenges,http://www.osgi.org/communityevent2012/schedule's speech. In this speech, the Siemens team demonstrated these business-driven solutions. These scenarios enable a highly agile, continuous integration environment based on OSGi.

Demand

The Siemens Technical Research department consists of a number of engineers with different skills, including computer science, mathematics, physics, mechanical engineering, and electrical engineering. The department provides Siemens business units with solutions based on neural network technology and other machine learning algorithms. Compared to idealized concepts, Siemens's business unit needs a sample product that can be run. So the department needs to quickly build a prototype of the solution for the business unit.

Figure 1: Siemens ' product Library

To build a prototype quickly, the ideal solution is to build a software component library that is at the core, so that the Siemens development team can quickly release new features and the business unit can quickly deliver new products.

The solution to achieve this goal must meet the following requirements:

Repeatable builds: The solution must be able to ensure that, even after many years, it can be rebuilt based on exactly the same source and dependencies. This allows Siemens to continuously support multiple distributions that are used by different customers.

A reliable version: by naming with the semantic version of OSGi, all of the published component versions of the build process will always correctly correspond to their semantics, and Siemens can quickly and reliably assemble components (including their own software, Third-party software, and open source software) and are highly confident that they will function properly.

Full traceability: All components released by the software are always identical to the components that QA tested, and can be traced back to their source and dependencies. This makes it no longer necessary to rebuild from the test state to the published state.

Finally, separate software components and final products must have a unified application start-up, lifecycle and configuration.

Solving method

They chose OSGi as the framework for implementing modularity, based on the maturity of OSGi technology, the Open industry specification that supports OSGI implementation, and the technology management of the OSGi Alliance. This continuous integration solution is based on the OSGi Bundle Library for development and publishing/products (Development and release/production OSGi Bundle Repository, OBR). Because the components of OSGi are completely self-describing (requirements and functionality metadata), specific business functions can dynamically load from the relevant libraries based on dependencies between modules.

The Siemens team also wants to implement the best Practices for "published as measured" (What you test are What you release, Wytiwyr). Software for publishing should not be rebuilt after testing, and the build environment may change during testing. Many organizations do reconstruct software products during the release process, from 1.0.0.BETA to 1.0.0.RELEASE. This common but not too good method is because the dependencies are implemented by the name of the component.

Finally, from a technical point of view, the solution must have the following characteristics:

Can be used in conjunction with standard development tools, such as Eclipse in Java;

Strong support for OSGi;

Support the concept of different software libraries;

Supports automatic semantic versions (that is, automatically calculating the version range that needs to be imported, and automatically increasing the version number of the output)--because this process is too cumbersome for humans!

For these reasons, Siemens chose Bndtools.