Gitlab Project Creation & Management
SOP
1. Project Group Creation
● Responsibility: The creation of project groups is the responsibility of the Team Lead
(TL), Project Manager (PM), or a Senior Team Member.
● Purpose: Ensure that the main project groups are created with clear and consistent
naming conventions aligned with the organization’s structure.
2. Sub-Group Creation
● Responsibility: The TL/PM or Senior Team Member is responsible for creating
sub-groups within the main project group.
● Platform Specific: Sub-groups should be created for respective platforms (e.g., iOS,
Android, React, Backend) under the main group.
● Purpose: Maintain an organized structure that allows developers to easily locate and
access their relevant projects.
3. Repository Creation
● Responsibility: The creation of empty repositories within sub-groups is to be handled by
the TL/PM or Senior Team Member.
● Initial Setup: Repositories must be initialized with a default README file and a main
branch.
● Purpose: Standardize the repository setup across all projects to ensure consistency
from the start.
4. Member Assignment
● Responsibility: The TL/PM or Senior Team Member is responsible for adding the
respective members to the appropriate sub-group.
● Platform Specific: Developers will be added to their respective platform’s sub-group
(e.g., iOS developers to the iOS sub-group).
● Purpose: Ensure that team members have access only to the projects relevant to their
work.
5. Branch Naming and Protection
● Naming Convention: All branches must follow a standardized naming convention. For
example:
○ feature/feature-name
○ bugfix/issue-id
○ hotfix/issue-id
○ release/version-number
● Branch Protection: The main branch should be protected:
○ Require at least one code review before merging.
○ Enforce passing status checks (e.g., CI/CD pipeline checks) before merging.
● Purpose: Maintain a clean and organized branch structure, ensuring the stability of the
main branch.
6. Merge Requests (MRs)
● MR Creation: Developers must create a Merge Request (MR) when they are ready to
merge their changes into the main branch or another protected branch.
● Review Process: MRs must be reviewed by at least one team member (preferably a
senior developer or TL) before merging.
● Approval and Merging: Only designated reviewers can approve and merge MRs. The
TL/PM or Senior Developer should be involved in the approval process for critical
merges.
● Purpose: Ensure code quality and consistency through peer reviews and controlled
merges.
7. CI/CD Pipeline Guidelines
● Pipeline Setup: Required repositories should have a CI/CD pipeline configured to
automate build, test, and deployment processes.
● Pipeline Standards: Pipelines must include automated tests and code quality checks.
Any failing pipeline should prevent code from being merged into the main branch.
● Responsibility: It is the responsibility of the TL/PM or a Senior Developer to ensure that
the CI/CD pipeline is correctly set up and maintained.
● Purpose: Automate and standardize the deployment process, reducing human error and
ensuring reliable deployments.
8. Code Review Practices
● Code Review Requirement: Every MR must undergo a code review. The reviewer
should check for:
○ Adherence to coding standards.
○ Functionality and correctness of the code.
○ Code efficiency and performance.
○ Security concerns.
● Reviewer Assignment: The TL/PM or a Senior Developer should assign reviewers
based on the complexity and criticality of the code.
● Purpose: Maintain high code quality, encourage knowledge sharing, and identify
potential issues early in the development process.
