Repository access policy

The goal of this document is to have a guideline inside of the company about the code repository access considering that we’re going to have different roles (Admin, Code-Owners and Contributors) and they could be included, at the same time, in team organisation (like BIT, ATA, ONL, ...)

Who will have access to the repository?

The repository access will be Private and their access is only allowed to company accounts with the next role distribution:

• Admin. They’ll can manage the access to the repository but assigned individually, for better management and audibility, considering the changes inside of the teams.
• Code-Owners. They should be appears as default reviewers. The PR must not be merge without, at least, one Code-Owner approval.
• Contributors. Set by default with “Write” permission but only the Code-Owners are available to merge it to 'master' and integration branches like 'staging', 'dev', ...

You have more information about those roles in the code-ownership page

Responsibilities in the repository:

The responsibility is divided into three sections:

• Management. This affect the repository administrators, they'll be involved to maintain the repository updating the people access.

• Supervisor. This affect the repository Code-Owners, they'll be involved in:

  • Repository documentation (see Code ownership)
  • PR Policy:
    • Branch permission (Master -> just PR, anyone write access)
    • Default reviewers
    • Merge strategy (Squash by default)
    • Minimum PR approvals
    • Jenkinsfile (include Dockerfile / Quality gates / Makefiles)
  • As an expert of the repository code, resolve possible doubts or questions during PRs

• Development. As Contributor, every change needs to be requested through PRs.

Security tips

• Repositories cannot be downloaded on devices that don’t belong to the organization.
• Users must use login using two-steps verification.
• The repositories should have an assigned project.