gitea-pages/admin-guide/architecture/version-control.rst

Version control

We use the internal PSI Gitlab server for version control. On this server we use a single repository group (linux-infra) for all infrastructure-related repositories, because this way a number of things have to be configured only once, e.g. members. In addition milestones and labels are group-wide concepts in Gitlab, and it is very useful to have those apply to all repositories. Finally it is easy to see all issues and merge requests for a repository group.

Repositories

Our repositories are configured in the following way:

The puppet repository

• Fast-forward merges only

  This keeps the history linear without merge commits, which makes it easier to read.

• Merges to prod or preprod require one approval

• Approval is revoked when further changes are pushed to an already approved merge request.

• The default branch is called prod. There is no master branch.

• The prod branch is protected.

• The preprod branch is protected.

Hiera repositories

These repositories contain Hiera data. There is exactly one repository per sysdb environment. The repository for environment foo is called data-foo.

Access is granted to the owner and admins of the corresponding sysdb environment.

Development workflow

We steer development through Gitlab issues.

For every change, be it a new feature, bug fix, or improvement, we create an issue on the relevant repository. Issues that have broader implications and do not naturally belong to a code repository, go into the org repository. An example would be a change of the development workflow or repository authorization.

When starting work on a change, the developer first assigns the issue to themselves.

Once the developer has finished development and tested the change, they rebase their changes to the prod branch, push the changes to a new branch, and opens a merge request to the preprod branch. Each issue #N being fixed must be mentioned at the start of the commit message in the form Fix #N.

Other developers will review the merge request. If they approve it, either the approving or the original developer may accept it, which will trigger the actual merge.