Workflow Rules

This document defines the standard development workflow at EGI, from writing code to deploying it in production. Every project follows these rules unless a documented exception is approved by a project lead.

Branch Strategy

EGI uses a feature branch workflow with a protected main branch.

Branch Naming

Branch Type	Format	Example
Feature	feature/[short-description]	feature/user-auth
Bug fix	fix/[short-description]	fix/login-redirect
Hotfix (production)	hotfix/[short-description]	hotfix/api-timeout
Chore / maintenance	chore/[short-description]	chore/update-deps
Release	release/[version]	release/1.2.0

Rules

• main is always deployable. No one pushes directly to main.
• Every change goes through a feature branch created from the latest main.
• Branch names are lowercase, hyphen-separated, and descriptive enough to understand the purpose without reading the code.
• Delete branches after they are merged.

Pull Request Process

Creating a Pull Request

1. Push your feature branch to the remote repository
2. Open a pull request (PR) against main
3. Fill in the PR template completely:
   • Summary: What changed and why
   • Test plan: How the change was tested
   • Screenshots/recordings: If the change affects UI
   • Related issues: Link to relevant tickets or issues
4. Assign at least one reviewer
5. Ensure all CI checks pass before requesting review

Code Review Standards

Reviewer responsibilities:

• Review within 4 business hours of being assigned (or reassign if unavailable)
• Check for correctness, readability, test coverage, and adherence to project conventions
• Leave constructive, specific comments tied to the code, not the person
• Approve, request changes, or comment (never leave a review in an ambiguous state)

Author responsibilities:

• Respond to all review comments within 1 business day
• If you disagree with a comment, explain your reasoning rather than dismissing it
• Do not merge your own PR without approval (except for documented emergency hotfixes)

Approval Gates

Change Type	Required Approvals	Additional Requirements
Standard feature or fix	1 engineer	CI passing
Database migration	1 engineer + project lead	Migration tested on staging
Infrastructure change	1 engineer + project lead	Rollback plan documented
Security-sensitive change	1 engineer + project lead	Security review completed
Hotfix (production emergency)	1 engineer (post-merge review acceptable)	Incident documented within 24h

Definition of Done

A feature or fix is considered done when all of the following are true:

• Code is written and follows project coding standards
• Unit tests are written and passing for new or changed logic
• Integration tests are updated if the change affects API contracts or data flows
• The feature works correctly on the staging environment
• The PR has been reviewed and approved
• Documentation is updated if the change affects user-facing behavior, API contracts, or operational procedures
• No unresolved review comments remain
• CI pipeline passes all checks (lint, test, build, type check)

Sprint Cadence

EGI operates on two-week sprints.

Event	Day	Duration	Purpose
Sprint planning	Day 1 (Monday)	60 min	Scope and assign work for the sprint
Daily standup	Every day	15 min	Blockers, status, priorities
Mid-sprint check-in	Day 5 (Friday)	15 min	Assess progress, adjust scope if needed
Sprint review / demo	Day 10 (Friday)	30 min	Demonstrate completed work to stakeholders
Sprint retrospective	Day 10 (Friday)	30 min	Identify process improvements

Sprint Rules

1. Do not add work to an active sprint without removing equivalent effort. Scope changes during a sprint require project lead approval.
2. Carry-over items from the previous sprint are discussed and re-prioritized in planning, not automatically included.
3. Unfinished work is flagged in the retrospective with a root cause (blocked, underestimated, scope creep, etc.).

Merge and Deploy Flow

The standard flow from code to production:

feature branch → PR → code review → approval → merge to main → staging deploy → staging verification → production deploy

Step-by-Step

1. Merge to main: After PR approval, the author merges using squash merge to keep the commit history clean
2. Staging deploy: Merging to main triggers an automatic deployment to the staging environment
3. Staging verification: The author verifies the change on staging, including smoke tests for affected functionality
4. Production deploy: Production deployment is triggered manually after staging verification
5. Post-deploy monitoring: The author monitors production for 30 minutes after deploy for errors, performance regressions, or unexpected behavior

Rollback

If a production deployment causes issues:

1. Revert the merge commit on main via a new PR (fast-track review)
2. Deploy the reverted main to production
3. Open a new issue documenting the failure
4. Fix the issue on a new feature branch and go through the standard process

Release Approval Process

For versioned releases or major deployments:

1. The project lead creates a release/[version] branch from main
2. Final testing and bug fixes are applied to the release branch
3. The release branch PR requires approval from the project lead and one engineer
4. After merge, the release is tagged with a semantic version (e.g., v1.2.0)
5. The changelog is updated and stakeholders are notified

See the Release Checklist for the full step-by-step release process.

Emergency Hotfixes

When a critical production issue requires an immediate fix:

1. Create a hotfix/[description] branch from main
2. Apply the minimal fix necessary to resolve the issue
3. Open a PR and request expedited review (tag with "urgent" label)
4. One approval is sufficient; the fix can be merged by the author if no reviewer is available within 30 minutes
5. Deploy to production immediately after merge
6. Within 24 hours, complete a post-incident review and create follow-up tickets for any deferred work