67 lines
2.3 KiB
ReStructuredText
67 lines
2.3 KiB
ReStructuredText
Version control
|
|
---------------
|
|
|
|
We use the internal `PSI Gitlab server <https://git.psi.ch/>`_ 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.
|