In the last decade, software became a key business differentiator, and our customers need to develop more software with higher quality in shorter development cycles. We are not surprised that the demand for combining model-based development (MBD) and processes of continuous integration and testing is increasing. For this reason, we overturn held beliefs to provide the best solutions. One held belief was that MBD files, e.g., *.dd, *.mdl, or *.slx files, do not suit well in pull request workflows to review, comment, and approve. In this blog post, we show you our solution to use pull requests with MBD files to take your software development to the next level.

Pull what? Brief description of pull requests

Developing software generally works best if done in small steps. All changes are stored in application life cycle management (ALM) suites like Microsoft® Azure DevOps. To ensure that several developers work in parallel without disturbing each other feature, you can create feature branches. A feature branch is a separate place used to work on specific features or fixes. Each feature branch must be merged back to the main branch while the main branch is not changed directly. This is where pull requests enter the game. Pull requests ease the collaboration of developers and ensure process-safety because they make sure that every change is properly reviewed before they are merged into the main branch. In the pull request, the team can directly review the changes and discuss the implementation of the proposed feature or fix via the web interface of the ALM. In an iterative process, the team gives feedback or tweaks the implementation. Once the implementation is deemed good, it is merged into the main branch. Before creating the pull request, it can be useful to merge the main branch into the feature branch to check if there are any changes made to the main branch since the feature branch was created and to resolve possible conflicts.

Facing the problems with MBD files

The main problem in using pull requests for MBD files is that the team is only informed about two different file revisions and not the explicit changes. This means that the differences cannot be shown directly in the web interface of the ALM as one is used to with source code files. Yet, commercial comparison tools like Model Compare are available. To use them for review, the original and modified versions must both be downloaded and compared locally by each team member. This negatively affects the workflow and does not allow the user to inspect, comment, or approve the changes directly without additional effort. However, problems are made to be solved.

Solution for MBD files in pull request workflows

To use the established pull request workflow of source files for MBD files, you can automatically create diff reports for the changed file revisions. This means that each pull request or update triggers the creation process of the diff reports. The reports are published to a shared place, e.g., an artifact server, a shared network drive, or directly attached to the pull request. This allows the team members to review the changes directly and comment on the changes. The author of the pull request can filter all open comments, fix them in his local development environment and update the pull request. Each time a pull request is updated, a new diff report is generated automatically. This allows a seamless pull request workflow till it is completed and merged into the main branch. We recommend checking if there are any changes on the main branch since the feature branch was created via merging the main branch into the feature branch. If MBD files changed on the main and the feature branch, the file conflicts can be easily resolved in the local development environment.

Kickstart your pull request journey

Before you are entering the rabbit hole, we want you to give the following hints for your pull request workflow:

• Split big features into small parts. In continuous processes, changes are often integrated or tested. Therefore, avoid pull requests that have thousands of model element changes.
• Separate changes clearly. A pull request should not mix up several tasks. Therefore, use one branch and pull request per feature or fix. If changes cannot be isolated, create different commits to allow reviewers to distinguish the changes.
• Integrate possible changes from the main branch into the feature branch before creating a pull request. This significantly reduces the probability of merge conflicts.

Overturning held beliefs

Day after day, we encounter deeply held beliefs. So, you could also end this blog post with the phrase "Impossible is nothing" and thus make a reference to Muhammad Ali. Ali never said these words and our belief is merely based on an advertising campaign of a well-known sporting goods manufacturer. Nevertheless, this way of thinking has undreamt-of powers, as impossibilities can represent potential and drive change. For this reason, we at dSPACE always try to challenge our beliefs and provide our customers with the best solution to a problem. In this blog post, we outlined a solution to establish a pull request workflow with MBD files. This enables our customers to develop more and higher quality software in shorter development cycles as pull requests have already proven for source code files. Change is the only constant in life. Therefore, we encourage you to get in touch with us and share your experiences or demands on that topic. This will help us to further optimize our solutions for your success.