5

What is the best practice for managing dependencies within a Simulink Project when the project is worked on across a team and the project has dependencies on different models and libraries?

An parallel example would be when building an application using Gradle and declaring the dependencies of a project including the required version numbers. Grade will resolve and download the versions that are required to build the project.

e.g. the following declares a dependency on version 2.1 of library and version 1.0 upwards of some-library, so that the latest version 1.x (1.0, 1.1, 1.2...) that is available will be downloaded and used.

dependencies {
    compile("com.example:library:2.1")
    compile("com.example:some-library:1.+")
}

The documentation for Simulink (and also here covering manifests) seems to talk about models within a project having version numbers. It doesn't seem to mention libraries that are imported into the project. Models that are only used within a single project could all be contained in the overall project, but what happens if there are (for example) generic S-Functions defined within a separate project or library (or library defined within a project) that are applicable across multiple projects? This requirement is all with the aim of helping to support an automatic build process triggered by a Continuous Integration server, such as Jenkins.

I'm interested in a workflow that will easily support dependency management and automatic dependency resolution with a Github Flow git branching policy.

John
  • 10,837
  • 17
  • 78
  • 141

1 Answers1

0

I've spent much time on this problem. Finally I didn't find an appropriate solution online, but I'd like to share the workflow we are using now and which fulfills our needs.

In short: We created our own dependency management by using git submodules.

Assumption: In fact, it is more a version management of persistent dependencies rather than offering the possibility to dynamically add new or remove old packages or libraries. This also works, but requires the git submodules to be added to or removed from the main git repository.

Objectives:

  • Consistent setup for everyone who works on the project.
  • Traceability of depdendencies.
  • Continous Integration with less effort.

How we do it (Example):

  • We have Project A and Project B which shall be used in Project C.
  • All three projects are under git version control and still under development.
  • We have set up additional release repositories for Project A and Project B, e.g. located on a network drive.
  • In Project C we add the release repositories of Project A and Project B as git submodules
  • We have set up some kind of auto-deployment to push only relevant files into these release repositories. For example if we want to make changes of Project B accessible to Project C, we only create a version tag in Project B's repository and it gets pushed to its release repository.
  • In Project C we update our git submodules and can checkout a new submodule version (if needed).

Advantages:

  • Since git stores the checked out version (commit) of git submodules in the main project, we can ensure that everyone works with the same files.
  • Changing the commit of a submodule is traceable in the main project.
  • The relation between the main project and the dependencies is always consistent.
  • Continuous Integration should work "out of the box". We are using GitLab and GitLab Runner and only had to setup our runner to fetch submodules recursively (in case of nested submodules).

I think this approach works as long as the repositories won't get too big, since you do not fetch only the version you need but also the whole version history.

Bibonaut
  • 61
  • 5