Design Patterns - iNineBD/Track-5Sem2025Main GitHub Wiki

🎯 Objective

This document aims to standardize development practices across all project repositories, promoting consistency, readability, and efficient collaboration among team members. The guidelines apply to all stakeholders, including Frontend, Backend, and ETL teams.

🧩 Summary

  • 🚀 Branch Pattern
  • 📦 Commit Pattern
  • 🚧 Pull Request Pattern
  • 📌 Guidelines
  • 👀 Code Review
  • 🔖 Version Tag Pattern
  • ✅ Definition of Done (DoD)
  • 🟢 Definition of Ready (DoR)

🚀 Branch Pattern

🌿 Main Branches

  • main: Contains the stable, production-ready version of the project.
  • sprint-{number}: Branch used as a base for the ongoing sprint tasks.

Example: sprint-2, sprint-3

🔤 Format for task branches:

{Jira issue code}-{brief-description}

✅ Example:

TRK-01-creation-of-project-repositories

Use lowercase letters and hyphens instead of spaces. The issue code must come from the management tool, in our case, Jira.

📦 Commit Pattern

🔤 Format:

{Jira issue code}-{type}:{short description}

Allowed types:

  • feat: - Implementation of new functionality.
  • fix: - Bug fix or code issues.
  • doc: - Documentation changes.
  • style: - Formatting adjustment (no functional impact).
  • refactor: - Code refactoring.
  • test: - Addition/update of tests.
  • chore: - Task with no direct impact on source code, tools, configurations or libraries.

✅ Example:

TRK-01 - feat: Creation of project repositories

🚧 Pull Request Pattern

🔤 Format:

{Jira issue code} - [Type] Short description of the change

Allowed types:

  • [Feature] - New functionality.
  • [Fix] - Bug fix.
  • [Docs] - Documentation.
  • [Refactor] - Code refactoring.
  • [Chore] - Internal maintenance.

✅ Example:

TRK-01 - [Feature] Creating project repositories

📌 Guidelines:

  • Every new feature or fix must go through PR.
  • When opening the PR:
    • Tag at least 1 reviewer from the team.
    • Add the link to the Jira/Taiga issue.
    • Make a clear description of what was changed.
    • Make sure the branch is up to date with the sprint branch.

👀 Code Review

  • Every PR must be reviewed by at least one team member.
  • The reviewer must check:
    • Clarity and readability of the code.
    • Test coverage (if applicable).
    • Impact on other parts of the system.
    • Good practices and standards defined here.

No PR should be merged without approval and without success in the CI workflow.

🔖 Version Tag Pattern

🔤 Format:

sprint - {number}

✅ Example:

sprint - 1

Use tags to mark relevant deliveries or sprint closures.

✅ Definition of Done (DoD)

Minimum criteria to consider a task as complete:

  • ✅ Code implemented and reviewed.
  • ✅ Functionality meets acceptance criteria.
  • ✅ Automated tests created (if applicable).
  • ✅ Interface validated according to design requirements.
  • ✅ Updated documentation (API, user manual, etc.).
  • ✅ Code merged into the main branch without conflicts.
  • ✅ Functionality validated with the PO or team.

🟢 Definition of Ready (DoR)

Minimum criteria to consider a task ready for development:

  • ✅ Clear and objective description.
  • ✅ Acceptance criteria defined.
  • ✅ Dependencies identified.
  • ✅ Priority established in the backlog.
  • ✅ Documented technical requirements (if any).