Skip to content

Domain Services - Governance

The Domain Services ecosystem comprises the Domain Services itself as well as dependent software components such as the Domain Services plugins (providers), workflow components, and web frontend components (React).

These components form a self-service platform of reusable components that are shared across MIKE products as well as projects and applications in the business units.

The overall governance mechanism for these components is internal Open Source Software (iOSS).

Deployment

The .NET components are deployed as individually versioned NuGet packages on nuget.org. As such, they shall be considered third party libraries to the consumers of these components.

The NuGet packages are deployed using semantic versioning that indicates whether a released package includes bug-fixes (change in the PATCH version number), new functionality (change in the MINOR version number) or possibly backward in-compatible changes (change in the MAJOR version number). Pre-releases uses the "-rc" notation (for example 3.0.0-rc01).

A bug fix leads to a new patched version of the most recent package. This means that consumers of a NuGet package must update to the most recent version of the package to adopt this fix.

The scripts for pushing packages are all a part of the individual source code projects, so that everybody with the necessary privileges can easily push new versions of NuGet packages.

The JavaScript (React) components are deployed using the npm package manager.

Contributing

The Domain Services components are all based on a philosophy of collaboration and openness; hence, they are maintained using internal Open Source Software (iOSS) principles, which means that every software developer within DHI can contribute to the development of these components.

The source code for these components are kept in DHI's private GitHub. Access to DHI's private GitHub is granted by THB. Each GitHub repository has an administrator with the following responsibilities:

The below table shows the GitHub source code repositories and the corresponding administrators:

Repository Administrator(s)
DHI/DomainModels (Spatial, Physics, etc.) LAM
DHI/DomainServices (Services, Web APIs, VS project templates, Samples) LAM
DHI/DomainServicesProviders (MIKECore, MCLite, ShapeFile etc.) LAM, FRT
DHI/Workflow (Activities, Service, Designer, Executer) FRT, MDT
DHI/react-components (React Web Components) FRT, DOCA, BOGD

Within the individual source code repositories, some of the above responsibilities is delegated to so-called code owners of particular projects.

Issues

Even though it is the administrators (code owners) responsibility to moderate and handle code issues as described above, this does not mean that the code owners will always fix the code issues. The code owner should not be a bottleneck to solving issues, so sometimes the code owner will delegate the responsibility to fix issues to the iOSS community itself, and merely review and merge pull requests.

However, for selected components, the code owner role will not be covered by an individual person, but rather by a formal MIKE Development team. In this case, you can expect issues, regarding at least bugs, to always be rapidly fixed by this team. One example of such a component is the MCLite provider.

Reviewers checklist

Below is a checklist for a standard review of a pull request (PR) and deployment of a .NET component.

  1. Checkout the development branch to your local machine and open the project in Visual Studio.
  2. Make sure the project builds and that all unit tests are green.
  3. Use the "Files changed" view in GitHub to go through the modified files one-by-one, marking them as viewed when processed. In this process, double-check the modifications/additions in Visual Studio. Maybe you discover analyzer violations or other issues. Make sure the contribution lives up to best coding practices in general and the Domain Services best coding practices in particular.
  4. If new functionality is added, make sure that this functionality is covered by unit tests.
  5. If there are various issues that needs attention, request modifications and/or make modifications yourself and commit to the development branch.
  6. If necessary, you can push a preliminary prerelease version of the NuGet package for testing, or for preliminary installation in a dependent component that might also need modifications. A prerelease version number must have the format {major}.{minor}.{patch}-rc{nn} - for example 3.5.1-rc02. Remember the rules of semantic versioning.
  7. Eventually, approve the PR, merge to master and delete the development branch.
  8. Once merged with master branch, checkout master branch and pull the most recent changes to your local machine.
  9. Build and re-run the tests and make sure they are all green. Then push the final version of the NuGet package. Remember the rules of semantic versioning.
  10. Commit the changes of the version number into the master branch with a comment stating the version number and a description - for example "3.5.1. Fixing null pointer exception in method foo."
  11. Evaluate whether this PR leads to modifications or additions to the documentation. If so, make sure it is updated.