From development to product maturity with Docker

RISC Software GmbH supported the LKR Leichtmetallkompetenzzentrum Ranshofen in rolling out a software product for production in continuous aluminum casting. In order to unite different user environments and versions, the Docker platform was used.

Modern software projects require a large number of different libraries, system settings, environments and services, each in different versions. However, the end product must run on a variety of systems. Docker has emerged as the de facto standard for reconciling these divergent conditions.

RISC Software GmbH worked with LKR Leichtmetallkompetenzzentrum Ranshofen from March to July 2022 to bring the FReSGo framework from a pure developer version to a state that allows production-ready installations to be rolled out via Docker images

Functionality

The FReSGo framework lets the user select a parameter configuration for a continuous aluminum casting via a web application. If no configuration exists for the desired parameters, the framework runs a simulation via OpenFoam to determine the necessary configuration. Web application and simulation use a common PostgreSQL database.

Initial situation

The framework including the web application was written in Python and ran on the respective developer computers, as well as a local PostgreSQL database in each case. The simulation consisted of a C++ component for OpenFOAM and the OpenFOAM simulation core, which required a relatively high effort for local installation due to its demanding requirements. The C++ component had to be built after each change, and the knowledge resided with a single developer. All sources are managed in an LKR internal installation of Gitlab.

Measures

Took the following steps to formalize tacit knowledge and automate building, testing, and rolling out to production systems:

Introducing or revising Docker configurations for each subproject.
Creating common parent Docker images so that the number of different configurations remained low.
Consolidating shared information into environment variables codified in an .env file.
Based on the publicly available Docker image of OpenFOAM, a simulation image was created that automatically builds the C++ component.
Extraction of test cases into a custom Docker test image.
Design and automation of CI/CD build pipeline with versioning integrated with git.

Results

Development benefited enormously from the change. Whereas broken code in the repository often went unnoticed because it ran flawlessly on one developer’s specific system environment but not on another developer’s slightly different environment, the CI/CD pipeline exposed problems much sooner after tests were built and executed. Debugging cycles were shortened.