GitLab

We "eat our own dogfood" and use the GitLab instance on the Developers' Hub to manage our work. All team members should be part of the DevOps group on GitLab.

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.

Where

Usually a project will be created within a sub-group of the DevOps group.

Naming

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 uis/devops/raven/raven-deploy.

The "long name" should make sense in isolation so, for the example above, naming the project "Raven Deployment Configuration" makes sense.

Settings

New projects should have the following settings changed:

  • Require 1 approver for all Merge Requests

Content

Create the project with a README. This provides an initial commit which forms the master branch. The contents of the repository should be opened as the first merge request for review.