Continuous Integration can help to find integration issues earlier and to visualize the status of the build to all involved. Integration problems can be detected at build-time in stead of run-time during testing and teams can get immediate feedback on changes that they made and on the impact on components that are developed by other teams.
At the Bits&Chips Software Engineering conference Arnoud Glimmerveen and Erik Schepers from Thales Naval Systems will talk about how they leveraged continuous integration to deliver a stable system.
InfoQ did an interview with Glimmerveen and Schepers about applying continuous integration at Thales, how continuous integration supports collaboration between teams and how agile software development supports them in maintaining their software and dealing with legacy issues.
InfoQ: Thales develops software for combat management systems that are used on naval vessels. Can you mention some of the customer needs and challenges that come with this kind of product?
Glimmerveen & Schepers: The combat management system is part of the larger combat system (which includes the sensors and actuators), this means that there are typically other parties also delivering parts of the system. In order to ensure stability, the customer is reluctant to accept changes on the system after it has passed certain acceptance tests.
This puts restrictions on what is possible when applying continuous delivery concepts in the development this kind of system. Pushing software updates to the ship is at this moment not an option.
An additional challenge is the limited availability of subsystem hardware that we need to integrate with. Often this hardware is delivered by the equipment vendors directly to the customer. The available time to perform integration tests with this equipment is limited and costly.
InfoQ: What made you decide to apply continuous integration?
Glimmerveen & Schepers: Historically we used custom build tools and scripts to build the software. This approach had a number of problems. First the scope was limited to building one product preventing us to find integration issues early on in the process. Second problem was that maintaining the build was complex and the status of the build was not visible to the majority of the team. Continuous integration helps us to overcome these problems.
InfoQ: How did you implement the practices and tools that enable continuous integration?
Glimmerveen & Schepers: We started by selecting a number of standard Continuous Integration tools (Jenkins, Maven, Nexus, Subversion), since there is a lot of information available to set-up and use these tools. Over the years we have gradually extended the use of these tools to address more and more integration aspects that we faced. Examples are the addition of static quality checks (using SonarQube) and more recently the provisioning of integration-test systems. The power of the tools is that they are easy to use and their output is very visible. Teams can create their own dashboard (selection of build jobs) and get immediate feedback. The open character enables anyone in the team to adapt and improve the build.
InfoQ: Can you elaborate about how you do the provisioning of integration-test systems?
Glimmerveen & Schepers: Our integration test systems consist of a dedicated set of hardware. To provision our integration systems, we configured a set of chained jobs in Jenkins (which we already had in place). The first job takes the versions of the product components to install as input parameters, and triggers the next job. Subsequent jobs check the consistency of the selected versions, and prepare the installation. The last job in the chain performs the actual installation of all computers in the test system. After installation, the system is currently used for manual testing to check for integration problems. If the selected set of product component versions works together, then this typically results in a new release candidate. In the future we’d like some automated acceptance tests to be executed as part of the job chain, possibly resulting in a release candidate.
InfoQ: You have multiple teams who are developing and maintaining the software of the system. Can you explain how continuous integration supports them to do this?
Glimmerveen & Schepers: Continuous integration helps development teams to gain insight in the current integration problems. They get immediate feedback on the changes they make and on how these changes impact components that are developed by other teams. The visibility and feedback allows teams to take more responsibility for software integration than they would otherwise be able to do. New found integration issues can be quickly incorporated in the build by the teams themselves.
InfoQ: How did you structure your organisation to support iterative and incremental development of products with multiple teams?
Glimmerveen & Schepers: We have divided the development effort over multiple domains. Every domain has one or more product owners, who provide input to a number of development teams. We have a single feature-backlog, which is used to coordinate the development effort across all teams. Teams are multi-disciplinary and are responsible for integration of the built software into the system. Representatives from each domain coordinate the delivery in order to ensure a consistent set of software components. A separate team performs our internal product acceptance tests on a reference system.
In order to align the teams, various team-crossing communities are in place, discussing subjects like software architecture and test approach.
InfoQ: Can you elaborate how agile software development supports you in maintaining your software and dealing with legacy issues?
Glimmerveen & Schepers: A TACTICOS system is composed of a selection of components, which are developed and maintained rather independent from each other. Some of these components have evolved over a span of 20 years, whilst others are newly developed.
One of the intentions of agile development is to deliver a potentially shippable product at the end of every sprint. Continuous integration allows teams to detect integration problems at build-time, where in the past these problems would only be found at run-time during testing later on in the process. Different components in the system may use different technologies, but they all have a standardized build procedure, implemented using Maven. As such, they benefit from the same mechanisms that we use to build and test new developed components.
