# GitLab Soft Launch Meeting Notes, 16<sup>th</sup> January 2019, UIS
This meeting is to introduce the GitLab service which is part of the new University Developer Hub.
The Developer Hub is intended to be a community building tool for Software Developers in the University.
It is still in its infancy but we're looking for early feedback on services and to build an initial community.
GitLab is an online platform which is intended to have the majority of tools required for modern software development.
GitLab is resourced by the Technology Development Fund until August 2019 funding. Our aim is for it to be chest funded post August if utility can be demonstrated.
You can start playing with GitLab right away. The URL is [https://gitlab.developers.cam.ac.uk/](https://gitlab.developers.cam.ac.uk/). You can log in via Raven and create repositories within a personal namespace. If you'd like to get a group under the UIS group, [open an issue on the support project](https://gitlab.developers.cam.ac.uk/uis/devops/devhub/docs/wikis/Information-for-UIS-users).
## Historical Context
_Some of the following is taken from [Tony Finch's notes on the current git service](https://git.uis.cam.ac.uk/i/uis/git/gitcam.git/blob/refs/heads/master:/doc/2017-10-31-service-status.mc)._
[Git](https://git-scm.com/) is a free version control system which can be used to track changes to a shared code base, share those changes with other developers and merge those changes into the shared code base.
UIS (then UCS) first launched a git service in 2013. It's currently managed by Tony Finch with assistance by Rich Wareham.
Using some statistics from the end of 2017, the current git service at git.uis.cam.ac.uk
* serves around 40 research groups and institutions;
* has around 500 users of which around 100 are active each month;
* hosts around 1000 repositories of which around 300 to 400 are active each month; and
* handles just shy of 2000 commits per month.
Although the service has been both popular and robust, it can be somewhat intimidating to users. Group management can, Lookup integration aside, require action by local admins.
The following features of the git service proved to be very good ideas:
***Delegated administration.** The administrators of a given institution or research group's top-level "folder" had complete control over how repositories within their top-level folder was managed. (We call these top-level folders "accounts".)
***Light touch in deciding who had an account.** If you viewed yourself as an autonomous group, we let you have a folder.
We're hoping to take those ideas forward. Some things which proved difficult with the current service:
***Group management.** There is some Lookup integration but there are still too many times where adding/removing members to a group required emailing a local admin.
***User management.** Adding users to an account required emailing a local admin.
***Cross-institution sharing.** Beyond making a repository completely public, it was fiddly to share work across top-level accounts.
The GitLab service should help address some of those difficulties.
## Where we are
We've secured the resources to deploy an "alpha" GitLab service. This service is resourced by the TDF until August 2019 after which we're seeking chest funding.
In the alpha phase we
* build a prototype of the service;
* test the prototype with users; and
* demonstrate that the service is technically possible.
We use our experience building prototypes in the alpha to:
* find problems with the design of the service and decide how to solve them;
* make some estimates about how much the service will cost; and
* identify the biggest risks for the beta stage, as early as possible.
By the end of alpha we aim to know:
* whether to move the service into the beta phase; and
* what we need to build in beta if we move into beta.
Although the service is alpha we are still intending it to be robust. We **do not** intend to delete data if we move to beta. We **will** perform appropriate data integrity measures such as snapshots and backups during the alpha phase.
The GitLab service is now live. We have a single top-level UIS group. If you'd like to get a group, [open an issue on the support project](https://gitlab.developers.cam.ac.uk/uis/devops/devhub/docs/wikis/Information-for-UIS-users).
## What we'd like from you
We want users within UIS to exercise our GitLab deployment and its features. We expect bugs and we expect policy questions to be raised which we don't have answers to.
By adopting GitLab early, you'll have a chance to provide early feedback about what works for you and what doesn't. We aim to mold the future of the service based on this early feedback.
At the moment we have a fairly vanilla deployment with very little custom configuration. As the service progresses we'll add configuration where appropriate in response to user need.
## How do I migrate repositories from git.uis?
We have no automated migration support at the moment. Because we gave local admins such flexibility to define permission models, it's non-trivial to migrate permissions over with complete fidelity.
Project owners may [configure repository mirroring](https://gitlab.developers.cam.ac.uk/help/workflow/repository_mirroring.md) to either a) push changes made on GitLab back to git.uis or b) pull changes from git.uis into GitLab. Which direction owners choose depend on which repository they want to be "canonical".
[More information](https://gitlab.developers.cam.ac.uk/uis/devops/devhub/docs/wikis/FAQs#is-there-any-support-for-migrating-from-the-gituiscamacuk-service) can be found in the Developer Hub documentation.
## Key GitLab Features
### Repository Hosting
Like the current git service you can host shared or personal git repositories.
### Delegated Group Management
Groups can contain subgroups. Owners of a group can manage membership of the group and subgroups themselves without involving a local admin.
### Protected Branches
Branches in a project repository can be marked as "protected" to disable, amongst other things, force-pushes re-writing history or code being merged if it has not been reviewed or does not pass tests.
### Merge Requests and Code Review
Collaborators on a project can submit their changes as a Merge Request. Depending on how the project is managed, a Merge Request can also be reviewed by another collaborator and feedback given in the Merge Request. The owners of a project may designate certain branches as requiring Code Review before changes are merged in.
### Wikis
Projects can have associated wikis.
### Flexible Permissions model
Users can be granted different levels of access to projects. Projects can be made publicly readable or restricted to people who can log into the GitLab service. (To a first approximation, this is the set of people with a Raven account and selected external collaborators.)
### External Collaborators
An external person can be given a login and access to a project. External collaborators can optionally be given the same read rights as a Raven account holder on a case-by-case basis.
### Continuous Integration and Deployment
GitLab comes with a flexible CI/CD system which can be used to run tests and/or deploy your code on every commit and/or merge request.
## Resources
*[GitLab help on the Developer Hub](https://gitlab.developers.cam.ac.uk/help)
*[GitLab features list](https://about.gitlab.com/features/)
*[GitLab overview on LinkedIn Learning](https://www.linkedin.com/learning/git-for-teams/gitlab-overview)
*[Git for teams on LinkedIn Learning](https://www.linkedin.com/learning/git-for-teams)
