Repositories

Repository Organization and Permissions Management

Repository Structure

To maintain clarity and order in GitHub/GitLab, repositories should follow a structured naming convention. This approach simplifies organization, filtering, and management.

GitLab Example:

AdminPanel
|__ Server
|       |__ someMicroserviceRepo
|__ Client
         |__ Web
               |__ someFrontendRepo
         |__ Mobile
               |__ someIOSRepo
               |__ someAndroidRepo

GitHub Example:

admin-panel.server.some-msvc-repo
admin-panel.client.web.some-front-repo
admin-panel.client.mobile.some-ios-repo
admin-panel.client.mobile.some-android-repo

---

User Roles and Permissions

When managing permissions, avoid assigning them directly to individual users. Instead, use groups (GitLab) or teams (GitHub) to manage access. This ensures scalability and simplifies permission management.

Recommended Practices:

• Assign permissions at the project level rather than globally.
• Use descriptive group or team names to reflect their purpose (e.g., Frontend Team, Mobile Developers).

Permissions by Project (Hierarchical Structure)

To simplify permission management, create a hierarchy of teams (in GitHub) or groups (in GitLab) based on repository naming conventions. This allows for granular control while maintaining consistency.

Formula for Teams and Permissions:

• Admins: Full access to manage repository settings and user roles.
• Maintainers: Write access to manage repository content and approve contributions.
• Developers: Write access to contribute code.
• Testers: Read access for testing and reviews.
• Designers: Read access for design reviews.

GitLab:

• admin-panel.*:
  • Admins: Full access to all repositories under AdminPanel.
  • Maintainers: Write access to manage repository content.
• admin-panel.server.*:
  • Server Admins: Full access to all server-related repositories.
  • Backend Developers: Write access to contribute code.
  • QA Team (Testers): Read access for testing and reviews.
• admin-panel.client.web.*:
  • Web Admins: Full access to all web-related repositories.
  • Frontend Developers: Write access.
  • Designers: Read access for design reviews.
  • Testers: Read access for testing.
• admin-panel.client.mobile.*:
  • Mobile Admins: Full access to all mobile-related repositories.
  • Mobile Developers: Write access.
  • QA Team (Testers): Read access.

GitHub:

• admin-panel.*:
  • Admins: Full access to all repositories under admin-panel.
  • Maintainers: Write access to manage repository content.
• admin-panel.server.*:
  • Server Team: Full access to all server-related repositories.
  • Backend Team: Write access to contribute code.
  • QA Team (Testers): Read-only access.
• admin-panel.client.web.*:
  • Web Team: Full access to all web-related repositories.
  • Frontend Team: Write access.
  • Design Team: Read-only access.
  • Testers: Read-only access for testing.
• admin-panel.client.mobile.*:
  • Mobile Team: Full access to all mobile-related repositories.
  • Mobile Developers: Write access.
  • QA Team (Testers): Read-only access.

---

GitOps and Naming Conventions

Using consistent and descriptive naming conventions is also beneficial for GitOps workflows. For example:

• Automatically committing the latest image tag to a GitOps repository can be streamlined by using a predictable file structure, such as {repo-name}/deployment.yml.
• Example:
  • For admin-panel.server.some-msvc-repo, the GitOps repository could include a file like admin-panel/server/some-msvc-repo/deployment.yml to track deployment configurations.
  • This ensures that automation tools can easily locate and update the correct files.

By adopting good naming practices, you can enhance automation, reduce errors, and improve the maintainability of your GitOps processes.

---

Summary

By organizing repositories with a clear structure, managing permissions at the project level using a hierarchical approach, and using consistent naming conventions for GitOps, you can ensure efficient collaboration, maintain security, and streamline automation. Always use groups (GitLab) or teams (GitHub) to assign permissions, avoiding direct user assignments.