Groups and projects¶
Each service has its own group on GitLab. These are usually sub-groups of the DevOps group.
Within each service's group, there are usually one or more projects. Projects can be roughly grouped into the following categories:
- Support and documentation. Projects which have repository hosting disabled and exist purely as wiki and/or issue tracking projects. These can be the "public" side of private repos if we want to offer public developer focussed documentation or a public issue tracker.
- Deployment. Projects which contain code to deploy a particular service. These usually only contain deployment configuration and secrets. They are almost always private as they contain deep details of how a service is deployed.
- Implementation. Projects which contain the implementation of services. We try to structure our services with the idea that they may be deployed in multiple places or by multiple people. As such the implementation of a service should not assume it will be deployed in a particular place or at a particular URL.
Creating a new project¶
When creating new projects in GitLab we try to follow the conventions below.
Usually a project will be created within a sub-group of the DevOps group.
Naming is hard. When providing the "short name" for a project, consider that it
will appear in URLS. As such it is better to have projects named like
uis/devops/raven/deploy rather than
The "long name" should make sense in isolation so, for the example above, naming the project "Raven Deployment Configuration" makes sense.
New projects should have the following settings changed:
- Require 1 approver for all Merge Requests
Create the project with a README. This provides an initial commit which forms
master branch. The contents of the repository should be opened as the
first merge request for review.