Tools and Artifacts
At the core of the ApleT framework is the feature model, which outlines the variability for the product line. The Variability Modeller role uses the feature modelling tool to produce the feature model, using the requirements gathered from customers. With ApleT the variability evolves over time and does not need to be specified fully up front. The Product Configurer uses the feature modelling tool to produce product configuration files – the individual configurations of the product for each customer. The framework makes use of these configuration files in many places. The Specification Mapper takes the requirements of the products and converts them into variability-enabled specifications. This is currently a manual process. The Specification Mapper runs the templates through the template processing tool and this produces the specifications for each customer. The Test Developer writes the test code that exercises the applications based on the executable specifications. For each customer, the CI Administrator adds a job configuration to the CI software. The CI Developer maintains build scripts that builds the software and runs the executable specifications against the applications. The CI software pulls in the source code and making use of the Build Scripts produces the applications. The CI software pulls in the variability-enabled executable acceptance tests and runs them on the web applications, making use of the test runner tool. The test Runner produces specification progress reports for each product. The Developer implements the software against the specifications using BDD. The Business Stakeholder reviews the specification reports to monitor application development progress, and can use this information to update the Customer. The Developer is alerted to regressions by the CI software as soon as they occur.
For feature modelling, we make use of the Eclipse plugin FeatureIDE. FeatureIDE allows us to build feature models with automated checking of mandatory, optional and alternative features and constraints. It provides an integrated product configuration system that provides a checkbox mechanism for producing valid configurations of the product line’s variability model. FeatureIDE outputs this configuration file in a textual format that can be easily parsed by a build script. We observed that FeatureIDE suffers from a scaling issue – large feature diagrams soon become unwieldy and difficult to navigate. Improvements to the tooling would be beneficial. However, the product configuration tool does not suffer from this issue and is easily navigable.
Any source control system that can be accessed by the CI server can be used as part of the process – e.g. git or svn.
We make use of Jenkins as the CI software. A key benefit of Jenkins is the concept of parameterised builds. This allows for reuse of the job configuration. The customer name is provided as a parameter, and can then be used throughout the build pipeline and within scripts. Jenkins sets the parameter as an environment variable. For example, in figure 5, the %CUSTOMER% environment variable is passed to the build.fsx build script. Originally we made use of a job configuration for each concrete product instantiation, simply copying one job configuration to a new job configuration in Jenkins – however this fell into the same clone-and-own paradigm that SPLE is designed to avoid. Parameterised builds get around this problem. We use the Build Flow4 plugin in or- der to trigger a number of parameterised builds automatically.
The main parameters we configured in the Jenkins build are: source code location – we observed this may or may not always be the same within a product line, depending on the refinement of the product line implementation (i.e. is source cloned-and-owned or is it variability-aware); the name of the customer; and the feature configuration for the customer.
We make use of FAKE, a DSL for writing build scripts with F#. Other build languages would work equally well for other platforms.
We made use of SpecFlow, due to the close integration it has with the .NET development environment. SpecFlow provides Visual Studio integration for writing BDD specifications in Gherkin, and integrates with multiple test runners such as NUnit or xUnit. It also produces test execution reports.
The BDD feature files are generated with code generation tools. We made use of the T4 Text Templates tool, which allows for C# as the control language. Other possible examples to use could be the ribosome, which allows for using Javascript, Ruby or python as the control language. The files are generated through parameterisation of the template files.