Munich Open Source

English

Deutsch

English

Deutsch

Appearance

Repositories ​

Public Code is defined by free licenses, but also by publicly accessible source code and artifacts.

Code ​

We want to give citizens, developers from other authorities, citizen developers, basically all interested people, the opportunity to use, understand, distribute and improve our code.

GitHub is the best-known public code repository for free software. Users from the FOSS community search, share and discuss free code mainly on GitHub. We follow the community and also use GitHub for Public Code of the City of Munich. Through code management and CI/CD on GitHub, we offer low-barrier participation for everyone.
GitHub does not hold any restrictive rights to the code managed there; each project can determine its own license. This leads to low vendor dependency, which is also easy to escape: We are only tied to Git as free software for distributed code management. This is also used by all other relevant platforms. Like other free projects, e.g. curl, we keep ourselves open to using other Git-based platforms additionally or alternatively.

When we contribute to other software projects, we do so on the existing platform of the software project.

An important and relevant alternative for public administrations in Germany is gitlab.opencode.de. We also run the landeshauptstadt-muenchen group there. Even if we do not primarily publish on gitlab.opencode.de, we are prepared to mirror repositories there on request. If we want to participate in free software projects from other public administration communities, we will only do so there if the projects allow merge requests.

In order not to force employees to use their real names on the Internet, employees are allowed to use pseudonyms. However, all pseudonyms used are documented internally in order to be able to trace which employees are acting publicly here.

Artifacts ​

The concept of Public Money Public Code obliges us to publish only the source code. To make our software easy to use, we want to publish as many artifacts based on the source code as possible, such as built packages, container images or Helm charts.

Repository Structure ​

Software repositories can be structured in various ways. Whether to choose a project repository or a multi-repo approach should always be a well-reasoned, project-specific decision.

Each option has its own strengths and weaknesses. In many cases, a project repository is recommended, but there are also valid reasons to opt for a multi-repo. We use both approaches: for example, the Wahllokalsystem project as a project repository and the dave- projects as a multi-repo.

When in doubt, a project repository should be preferred.

This recommendation applies in particular to projects on GitHub, but is generally applicable to any Git repository (e.g., git.muenchen.de).

Project Repo ​

A project repo is a software development strategy in which the code for multiple related services within a project is managed in a single repository. This contrasts with multirepos, where each microservice is maintained in its own repository.

Advantages of a project repo:

  • Dependencies between services within a project (e.g., a new feature that requires changes to both the frontend and backend) can be developed, tested, and released together—including pull requests, tests, and deployments.
  • A project repo makes it easier for outsiders to quickly identify which components belong together.
  • Developers can more easily set up a complete development environment with all the necessary services.
  • There is a central README.md that can provide clear documentation for the entire project. In addition, a documentation website, either in a /docs directory or as a standalone site, is recommended.
  • The overview on GitHub (e.g., github.com/orgs/it-at-m/repositories) remains clear and organized, since fewer individual repositories are created.

A single project repository is particularly well-suited for projects in which many services are closely intertwined and interdependent.

Multirepo ​

Arguments in favor of multirepos:

  • Each microservice is assigned exactly one repository and one pipeline. This makes development more organized.
  • A project consisting of different services using different technologies can lead to code mixing in a monorepo and, in some cases, to merge conflicts that are difficult to resolve for people without knowledge of technology A or B.
  • Pipelines are usually less complicated than in a project repo.
  • Less data than in a project repo: Cloning an individual repository and tracking its changes (e.g., with git blame) is faster.
  • Bugs in the main branch usually affect only one microservice, but may also affect dependent services or the entire product.

Multi-repos are particularly well-suited for standalone services and, in particular, for libraries intended for use in other projects.

Monorepo ​

When we talk about a monorepo approach, it essentially means that there is only a single repository for the entire company. This repository contains all of the company’s projects, including both active and inactive ones. The best-known example of a monorepo in production is Google, which built its own source code management tool specifically to manage exactly one single repository. Meta Platforms, the company behind Facebook and Instagram, also essentially relies on a monorepo, using its Git-compatible in-house tool Sapling, which was released as open source at the end of 2022. A monorepo like this is incredibly huge and contains the history of (almost) all of the company’s projects.

from Sujeevan Vijayakumaran: DevOps Wie IT-Projekte mit einem modernen Toolset und der richtigen Kultur gelingen ISBN 978-3-8362-9099-9 5.5.4 Was ist eigentlich mit Monorepos?

A monorepo is a single repository containing multiple distinct projects, with well-defined relationships.

from monorepo.tools

There are practically no limits to the size of a monorepo:

Google, for example, is theorized to have the largest code repository ever, which has thousands of commits per day and is over 80 TBs large.

from semaphoreci.com - What is a monorepo?

For example, a monorepo at LHM would exist if Refarch, all Refarch projects, the BayernID plugin as an independent but utilized SSO service, and other projects were managed together in a single repository.

Rules ​

  • Documentation: The numerous services in a monorepo should be documented in the README.md and include links to the respective files or directories.
  • Naming convention: Every repository belonging to a project's or product's multi-repo should be named using a consistent prefix followed by a - (e.g., dave-).