#supportchat channels for questions that don't seem appropriate to use the issue tracker or the internal email address for.
GitLab consists of many subprojects. A curated list of GitLab Repositories can be found at the GitLab Engineering Projects page.
When adding a repository please follow these steps:
CONTRIBUTING.mdin the repository. It is easiest to simply copy-paste the DCO + License section verbatim from the
CONTRIBUTING.mdfrom the project's
A team needs certain skills and a minimum size to be successful. So we start a standlone team when we have the following:
Until this criteria is met the work should be scheduled on existing teams. If a new product manager starts before a team can be created they should work with a existing product managers to get work scheduled with their engineering teams.
To maintain our rapid cadence of shipping a new release every month, we must keep the barrier low to getting things done. Since our team is distributed around the world and therefore working at different times, we need to work in parallel and asynchronously as much as possible.
That also means that if you are implementing a new feature, you should feel empowered to work on the entire stack if it is most efficient for you to do so.
We need to maintain code quality and standards. It's very important that you are familiar with the Development Guides in general, and the ones that relates to your group in particular:
The idea that working software is the primary measure of progress is one of the principles of agile software development. Demoing gets more eyes on the project to uncover bugs and reveal ambiguities in the product requirements. It's also a transparent and lightweight way to provide status to the rest of the organization. Developers should demo at least once a week with product managers present. Demo meetings should be kept to 30 minutes or less. The emphasis should be on the product requirements or acceptance criteria and less on the implementation details.
GitLab makes use of a 'Canary' environment, a series of servers to test the GitLab code base on prior to production deployment. The Canary environment contains code functional elements like web and git servers while sharing data elements such as sidekiq, database, and file storage with production. This allows UX code and most application logic code to be user tested under real world scenarios before being deployed.
The Canary environment is available for usage by enabling a cookie attribute of
gitlab_canary when accessing
Code reviews are mandatory for every merge request, you should get familiar and follow our Code Review Guidelines.
When using any of the resources listed below, some rules apply:
Every team member has access to a common project on Google Cloud Platform. Please see the secure note with the name "Google Cloud Platform" in the shared vault in 1password for the credentials or further details on how to gain access.
Once in the console, you can spin up VM instances, Kubernetes clusters, etc. Please remove any resources that you are not using, since the company is billed monthly. If you are unable to create a resource due to quota limits, file an issue on the Infrastructure issue tracker.
Every team member has access to the dev-resources project which allows everyone to create and delete machines on demand.
In general, most team members do not have access to AWS accounts. In case you need an AWS resource, file an issue on the Infrastructure issue tracker. Please supply the details on what type of access you need.
There are primarily two Slack channels which developers may be called upon to assist the production team when something appears to be amiss with GitLab.com:
#backend: For backend-related issues (e.g. error 500s, high database load, etc.)
Treat questions or requests from production team for immediate urgency with high priority.
Because of the volume of work required to get a release out the door, there will be two primary release managers:
Trained release managers, one in Americas and one on EMEA/APAC, will ultimately be in charge of making sure the release candidates (RCs) get created and deployed.
These release managers need to be very vocal if they need help or something is blocking the release candidate (RC)
Trainee release managers will do most of the hands-on work (e.g. cherry-picking, creating RCs, deploying, etc.).
Trainers should allow trainees to do the work, but like a pilot of an airplane they can take over when time becomes critical.