6.4 KiB
id, title
| id | title |
|---|---|
| 03-gitea-organization | Gitea Organization |
Gitea Organization Management
This document outlines the organizational structure, permissions, and management practices for our Gitea instance. It defines how teams are organized, what permissions they have, and how organizational resources are managed.
Organization Overview
Our Gitea instance serves as the central repository management platform for all development projects. Organizations are structured around projects rather than functional teams, providing clear project boundaries and focused development workflows.
Key Benefits
- Project Isolation → Each project has its own organization with dedicated repositories
- Technology Separation → Clear boundaries between different technology stacks
- Access Control → Project-specific permissions and team assignments
- Resource Management → Organized repositories, teams, and settings per project
- Scalability → Easy to add new projects and development initiatives
---Continuous Integration/Continuous Deployment
Organization Structure
Our Gitea instance is organized around project-based organizations rather than functional teams. Each organization represents a specific project or development initiative, allowing for clear project isolation and focused development workflows.
🎮 Main Development Projects
Main Development Projects are end-user facing products or core game systems. These include all primary game titles, lobbies, and shared frameworks that are directly part of production or delivery.
- Full Name Pattern:
Project <Engine/Platform> <ProjectName> - Name Pattern:
<Engine/Platform>-<ProjectName>
Examples:
Project Unity Joker→ Project Game for Joker using Unity EngineProject Cocos Core→ Project Core using Cocos Creator EngineProject Cocos Joker→ Project Game for Joker using Cocos Creator EngineProject Cocos Lobby→ Project Lobby using Cocos Creator Engine
🛠 Support Organizations
Support Organizations are internal or auxiliary projects that provide tools, resources, infrastructure, or research to assist developers. They are not directly delivered to end-users but are essential for efficient development.
- Full Name Pattern:
Project <Purpose> - Name Pattern:
dev-<Purpose>
Examples:
Project Developer Probation→ Project for Developer probationProject Development Tools→ Project for Development toolProject Research Development→ Project for Research development
Permission Levels
👑 Owners Team
Holds the highest level of authority within an organization.
- Create, modify, and delete any resource within the organization
- Manage organization-wide settings, policies, and access controls
- Add or remove teams and members
- Configure organization-wide permissions
- Approve major changes and policy updates
- Full access to all repositories and resources
👥 Leaders Team
Responsible for managing project execution within their organization.
- Create repositories within the organization’s scope
- Manage team member permissions and assignments
- Configure repository settings and branch protection rules
- Review and approve pull requests
- Oversee project workflows and development processes
- Access to organization-specific repositories
💻 Developers Team
Responsible for day-to-day coding and implementation.
- Create new branches and submit pull requests
- Access assigned repositories and project resources
- Participate in code reviews and technical discussions
- Implement features and contribute to project development
- Work only within their organization’s repositories
🔧 Builders Team
Automation account responsible for executing builds and deployments.
- Execute CI/CD1 pipelines and automated build processes
- Run build configurations and build scripts created by developers
Team Management Guidelines
Team Creation Process
- Request Submission → Team Leader submits a team creation request.
- HoD2 Approval → Head of Department reviews and approves the request.
- Team Setup → HoD creates the team with appropriate permissions.
- Member Assignment → HoD adds members to the team.
- Repository Access → Repositories are assigned to the team as needed.
Team Structure Guidelines
Base Team Structure
All organizations follow a standardized team structure with four core team types:
👑 Owners Team
- Purpose: Provide full administrative control over the organization.
- Members: Head of Department (HoD) and senior management for that organization.
- Permissions: Create, modify, and delete resources within the organization.
- Scope: Limited to the specific organization they own.
- Size: 1–3 members per organization (typically HoD and senior technical leads).
👥 Leaders Team
- Purpose: Project management and technical leadership.
- Members: Team Leaders.
- Permissions: Manage team members, review and approve pull requests, configure repositories and workflows.
- Size: 2–5 members per organization.
💻 Developers Team
- Purpose: Core development work and feature implementation.
- Members: Game Developers.
- Permissions: Create branches, submit pull requests, access assigned repositories, and participate in code reviews.
- Size: 3–10 members per organization (varies by project size).
🔧 Builders Team
- Purpose: Manage build and deployment automation.
- Members: Automation accounts (not human users).
- Permissions: Execute CI/CD pipelines, run build scripts, and perform automated deployments.
- Size: 1 automation account per organization.
Team Assignment Guidelines
- Organization-Specific Teams: Each organization maintains its own complete set of base teams.
- Owners Team Scope: Each organization has its own Owners Team, with authority limited to that organization.
- Cross-Project Access: Builders Team may hold access to multiple organizations for shared infrastructure.
- Role Flexibility: Team members may belong to multiple teams within the same organization if required.
- Permission Inheritance: Team permissions are standardized and inherited from the base team structure.
- Isolation: Owners of one organization cannot access or modify another organization.