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.