GitLab

Rationale

GitLab is the platform we use for developing our software. It provides essential services like Git repositories, Merge requests, Development planning, CI/CD, among many others.

The main reasons why we chose GitLab over other alternatives are:

1. It is Open Source.
2. It is SaaS.
3. It is a DevOps Suite, meaning that all their technical efforts are focused on creating a workflow that facilitates getting high quality code to production as secure and fast as possible. Such vision is in harmony with our philosophical vision of software development and current development cycle.
4. It has its own Continuous Integrator with built-in support, which is essential to our development cycle.
5. It has the GitLab for Open Source program, which gives unlimited ultimate free seats to Open Source projects like ours.
6. It provides Development Planning with [issues][ISSUE], milestones, roadmaps, among others. Such features are essential for task prioritization and resource assignment.
7. It has highly customizable permissions settings, allowing to give permissions using a user-based granular approach. Publishing specific sections of a project using a section-based granular approach is also possible.
8. It supports Two-factor Authentication.
9. It supports Merge Requests, allowing developers to open requests to get their changes to production.
10. It supports Merge Request Approvals, allowing to specify a group of developers for reviewing and approving merge requests. In order to be able to reach production, developers need at least one approval from a user belonging to the approvers group. An approver cannot approve her own merge requests, everyone needs their work to be reviewed by someone else.
11. It has a very complete REST API that allows us to automate processes like reviewing merge requests, rotating AWS secrets and programmatically cloning repositories.
12. It has its own Container registry, allowing us to seamlessly store all our containers in the same place.
13. It supports CI/CD schedules, which allows us to easily run scheduled jobs.
14. It supports Environments for seamlessly accessing both development and production environments.
15. It supports built-in Analytics that provide issue insights, CI/CD analytics, merge request analytics, issue analytics, repository analytics, among others.
16. It supports many ChatOps integrations. Allowing us to have an open, dedicated telemetry channel on our internal chat platform that receives all types of relevant information from GitLab. Developers just need to keep an eye on it in order to know what's happening with merge requests, [issues][ISSUE], failed jobs, etc.
17. It supports Repository Mirroring, allowing us to have a mirror of our repository on GitHub.
18. It supports Project Access Tokens, which greatly increase security and reliability on our integrations, as we use project-bounded instead of user-bounded tokens.
19. It supports SSH Signed Commits, allowing us to add an extra layer of security by ensuring that when someone pushes a new commit, that person is indeed who she claims she is.
20. It supports GitLab Pages, a very easy way of publishing static web pages.
21. It supports Protected Branches, an essential feature that assures that no one can push to the main production branch, thus forcing developers to reach production via merge requests.
22. It supports infrastructure integrations for Error Tracking, Tracing, Metrics, among others.
23. It supports Push Rules that allow to further customize what can and cannot be pushed to the repository. Some examples are branch naming, signed commits, secret pushing prevention, among others.

Alternatives

1. Azure DevOps: It did not exist at the time. It is not Open Source.
2. BitBucket: It is not a DevOps solution but a source code repository. It did not integrate with a CI/CD solution.
3. GitHub: It is not a DevOps solution but a source code repository. It did not integrate with a CI/CD solution.

Usage

We use GitLab for:

1. Hosting our universe repository.
2. Hosting our issues.
3. Hosting our milestones.
4. Opening our merge requests.
5. Hosting our containers.
6. Visualizing jobs and pipelines.

We do not use GitLab for:

1. Implementing it as code: We can partially implement GitLab as code using Terraform.
2. Security scans: We tried to implement this in the past but were not able due to low parametrization capabilities on the scans.
3. Operations: We currently do not use a stack that integrates with GitLab. Issues have been opened for this: Review Sentry, Review Jaeger, Review Elastic Stack.

Guidelines

1. Start using Git on the command line.
2. Signing commits with SSH.
3. Generate SSH keys.
4. Create a personal access token.
5. Create a merge request.
6. Create an issue.

Note: This subsection is pending review. Some of the information might be outdated.