Standard Developer Workflow

A standardized software development lifecycle (SDLC) workflow aligns managers, developers, and QA engineers around a predictable delivery rhythm. It eliminates communication silos, enforces code quality gates before deployment, and ensures traceability from ticket creation to production release.

Role Key

To clarify responsibilities across each phase of the lifecycle, actions are marked by role:

• 🟡 Managers & Engineering Leads — Prioritization, estimation review, scope, and process alignment.
• 🔵 Developers — Implementation, branch hygiene, testing, and PR management.
• 🟢 QA & Reviewers — Manual testing, acceptance criteria validation, and peer review.

Workflow Lifecycle Overview

[ 1. Jira Ticket ]
       │
       ▼
[ 2. Estimation & Due Date ] (Story Points)
       │
       ▼
[ 3. Git Branch Creation ]  (feat-xxx / bug-xxx from dev)
       │
       ▼
[ 4. Implementation ]       (Clean code, modular functions)
       │
       ▼
[ 5. Commit & Reassign ]    (Conventional commits with ticket IDs)
       │
       ▼
[ 6. Pull Request (PR) ]    (Linked to Jira & shared to Slack)
       │
       ▼
[ 7. CI / Automated Tests ] (Linting, static analysis, unit tests)
       │
       ▼
[ 8. Code Review ]          (Peer review & feedback loop)
       │
       ▼
[ 9. Deploy to Dev/Staging] (Automated post-merge deployment)
       │
       ▼
[ 10. QA Verification ]     (Reproduction steps & edge cases)
       │
       ▼
[ 11. Ticket Closed & Clean](Delete remote branch)

Phase 1: Planning & Ticket Setup

Step 1: Create the Jira Ticket 🟡 🔵

Every task starts with a well-scoped ticket in your issue tracker (Jira, Linear, GitHub Issues):

• Summary: Concise and descriptive (e.g., feat: Add Google OAuth2 login flow).
• Description: Include user stories, expected behavior, edge cases, and design/Figma links.
• Attachments: Provide annotated screenshots or screen recordings where applicable.
• Initial Status: Tickets default to the Backlog or To-Do column.

Issue Type: Story / Bug / Task
Summary: [Auth] Implement session-based token refresh
Description:
  - As a user, I want my token refreshed seamlessly without logging me out.
  - Acceptance Criteria:
    1. Interceptor catches 401 Unauthorized responses.
    2. Background request fetches new JWT using refresh token.
    3. Failed refresh redirects user to /login.

Step 2: Story Point Estimation & Due Dates 🟡

Story Point: An abstract unit of effort, complexity, and risk required to deliver a task.

1. Review requirements with the assigned developer.
2. Estimate points during sprint planning or grooming.
3. Agree on achievable deadlines and due dates.
4. Set explicit ticket priority (P0 Blocker, P1 High, P2 Medium, P3 Low).

Phase 2: Branching & Development

Step 3: Branch Creation from dev 🔵

Before writing any code:

1. Move the Jira ticket from To-Do to In Progress.
2. Break down complex stories into subtasks if multiple team members are contributing.
3. Create a dedicated feature or bugfix branch originating from the latest dev (or develop) branch:

# Ensure local dev branch is up-to-date
git checkout dev
git pull origin dev

# Create feature or bugfix branch
git checkout -b feat-878-auth-session
# or for bug fixes:
git checkout -b bug-122-navbar-shadow

Branch Naming Standard:

• feat-<ticket-id>-<short-description>
• bug-<ticket-id>-<short-description>
• chore-<ticket-id>-<short-description>

Step 4: Writing Production-Grade Code 🔵

Maintain consistent engineering hygiene throughout the codebase:

1. Self-Documenting Code: Write clear, expressive function and variable names instead of relying on redundant comments.
2. Remove Debug Logs: Strip out temporary console.log(), print_r(), or dump() statements before staging changes.
3. Consistent Indentation & Formatting: Enforce Prettier, ESLint, or language formatters on pre-commit hooks.
4. File Length Discipline: Keep individual source files under 100–150 lines wherever possible by extracting reusable components and utility helpers.
5. Accessibility: Always provide descriptive alt attributes on image elements and semantic HTML landmark tags.

Additional Backend Guidelines (e.g. Laravel / Node / Spring):

• Database Migrations: Always use versioned migrations; never execute manual raw SQL schema alterations in shared environments.
• Form Request Validation: Authorize and validate request payloads in dedicated Form Request or DTO classes prior to controller execution.
• Standardized API Responses: Return consistent JSON response envelopes with HTTP status codes (200 OK, 201 Created, 400 Bad Request, 403 Forbidden, 404 Not Found).
• Environment Isolation: Never hardcode secrets, access keys, or third-party endpoints; strictly read them through .env configurations.
• Single Responsibility Principle (SRP): Keep controller handlers lean (20–30 lines max), delegating complex business orchestration to Service or Repository layers.

Phase 3: Commits & Pull Requests

Step 5: Committing Changes 🔵

Follow Conventional Commits with ticket references embedded in each commit message:

feat: 878-implement-session-token-refresh
fix: 122-resolve-navbar-elevation-shadow
refactor: 405-extract-user-permission-service

git add .
git commit -m "feat: 878 implement token refresh interceptor

- Adds Axios interceptor to catch 401 responses
- Automatically issues refresh token call before retrying original request
- Jira: https://company.atlassian.net/browse/PROJ-878"

Step 6: Create the Pull Request (PR) 🔵

1. Push your branch to the remote origin:

   git push -u origin feat-878-auth-session

2. Open a Pull Request targeting the dev branch.
3. Include the Jira ticket link in the PR description, and paste the PR link as a comment in the Jira ticket.
4. Verify diffs locally to confirm no unintended configuration files, secrets, or temporary files were staged.

Step 7: Announce in Pull-Request Channel 🔵

Post the PR link into your team’s designated review channel (e.g., #dev-pull-requests on Slack):

🚀 Ready for Review: [PROJ-878] Implement Session Token Refresh
PR: https://github.com/org/repo/pull/142
Ticket: https://company.atlassian.net/browse/PROJ-878
Reviewers: @lead-dev @qa-team

Phase 4: CI, Review & Deployment

Step 8: Automated CI Checks 🔵 🟡

Continuous Integration pipelines should automatically trigger on PR submission:

• Linter checks (e.g., ESLint, Stylelint, PHP CS Fixer).
• Type checking (tsc, astro check).
• Automated unit and integration test suites.

Step 9 & 10: Peer Code Review & Feedback Loop 🟡

1. The supervisor or designated reviewer inspects code architecture, security implications, database query performance (e.g. N+1 queries), and test coverage.
2. Reviewers leave constructive, inline comments on GitHub/GitLab.
3. The developer resolves requested changes with follow-up commits.
4. Approval requires green lights from both automated tests and peer reviewers.

Step 11 & 12: Merge & Dev Server Deployment 🟡 🔵

1. The reviewer merges the PR using squash-and-merge or merge commits based on repository policy.
2. Continuous Deployment (CD) triggers an automatic deploy to the development/staging environment.
3. The developer verifies that the feature works in the live staging environment.
4. Mark the PR as complete in Slack (e.g., with a :white_check_mark: reaction).

Phase 5: QA Testing & Ticket Closure

Step 13: QA Verification 🟢 🟡

1. Move the Jira ticket to In QA / Testing.
2. The QA tester conducts manual and end-to-end verification against the ticket’s Acceptance Criteria.
3. If an anomaly is discovered:
   • Provide reproduction steps, browser/device specs, logs, and screenshots.
   • Reopen the ticket or return it to In Progress.
4. If a disagreement arises regarding expected behavior, review the ticket specifications with the Product Manager / Engineering Lead.

Step 14 & 15: Closure & Branch Cleanup 🟡 🔵

1. Once QA approves, move the Jira ticket to Closed / Done.
2. Branch Cleanup: The developer deletes the merged remote and local branch to prevent repository clutter:

# Switch back to local dev
git checkout dev
git pull origin dev

# Delete local feature branch
git branch -d feat-878-auth-session

# Prune stale tracking references
git fetch -p

Reporting Ad-Hoc Issues & Bugs 🔵 🟡

If a team member discovers a bug or potential improvement outside the current sprint scope:

• Create a standalone Jira ticket categorized under Bug or Improvement.
• Link it as an issue related to the relevant Epic or Story ticket.
• Notify the engineering supervisor during daily standup for sprint triage and prioritization.

Questions or Feedback?

Have suggestions or refinements for team workflow standards? Feel free to connect via email at kashifwahaj@gmail.com.