Development Phase

After completing the design phase and finalizing architecture, the following workflow will guide the development phase, ensuring that each issue is thoroughly planned, tracked, and executed with the highest level of detail.

1. Preparation

Objective: =Split the whole Product Story into Jira Tasks and GitHub Issues

This is usually considered during planning/design phase, but really it is not possible to predict everything in advance so adjustments to Jira will be needed.

Basically, the key points are the following:

Each jira milestone is set of small tasks.
Each task is an issue or a set of issues (depends on the complexity)
Each issue is PR (pull request)

Break Down Features: Divide each feature into smaller, manageable tasks to ensure incremental progress and maintain a clear development focus.

IMPORTANT: Each GitHub issue should represent a single, self-contained task that can be independently developed, tested, and integrated.

In cases where a task is too large or complex, split it into several issues, then follow a rebase strategy to organize the larger task within a sequence.

Please, take a look at the following examples:

1.1 User Authentication

Issue #	Title	Details
Issue 1	Create Registration Endpoint	Implement user registration, including validations, JWT token generation, and user data storage.
Issue 2	Implement Login with JWT Authentication	Develop login functionality with JWT tokens, handle session expiration, and include error handling.
Issue 3	Forgot Password Flow	Create a "Forgot Password" flow with email verification and secure token-based password reset.
Issue 4	Set up Social Authentication	Integrate social authentication (e.g., Google, Facebook) using OAuth protocols.

1.2 Product Management

Issue #	Title	Details
Issue 1	Database Models for Products/Categories	Define and implement database models for products and categories, including relationships and constraints.
Issue 2	CRUD Endpoints for Product Management	Build CRUD endpoints for products, with data validation and error handling.
Issue 3	Product Filtering and Sorting	Implement filtering, sorting, and pagination logic for products.
Issue 4	Unit Tests for Product Endpoints	Write unit tests to ensure CRUD functionality and data integrity for product endpoints.

1.3 Payment Integration

Issue #	Title	Details
Issue 1	Stripe API Integration	Integrate Stripe API to handle payment processing, including validation and error handling.
Issue 2	Webhook for Payment Status Updates	Implement webhook handling for payment status updates from Stripe.
Issue 3	UI Flow for Payment Details	Develop the user interface for entering and validating payment details.
Issue 4	Backend Validation for Payments	Add backend validation to ensure security and accuracy of payment details.

This issues are representing the development tasks in Jira as well, they have to be well planned and documented thoroughly.

2. Issue Breakdown

Each issue should be meticulously planned with all necessary details to provide a clear path to completion. An excellent issue breakdown will ensure smooth development, reduce misunderstandings, and allow for efficient reviews. Here’s a comprehensive template for structuring GitHub Issues.

IMPORTANT: You can allocate up to 70% of time during the development to plan issue thoroughly, isntead of writing code and avoid extreme complexities/uncertainties.

2.1 GitHub Issue Metadata

This should be added directly on the issue page on Github.

Title:
A concise and descriptive title, e.g., Create registration endpoint.
Description:
Provide a comprehensive overview of the issue, including:
The purpose of the feature or fix.
Functional requirements and any dependencies.
Edge cases or specific considerations.

Example:
Implement an API endpoint to register new users. This endpoint will: - Accept required fields (username, email, password). - Validate inputs for uniqueness (e.g., email) and enforce password standards. - Store user data in the database and return a JWT token on successful registration.

Acceptance Criteria:
Define specific criteria to indicate when this issue can be considered complete.

Example: - User receives a 201 Created response with a user ID and authentication token on successful registration. - For invalid inputs (e.g., existing email, weak password), return appropriate error responses with a 400 Bad Request status.

Labels:
Use labels to categorize and prioritize the issue, e.g., Backend, Authentication, High Priority, Database.
Assignees:
Specify the developer(s) responsible for this task.
Estimated Time:
Include an estimate for task completion (e.g., 5 hours) to assist with sprint planning and resource allocation.
Dependencies:
List any preconditions that must be met before this issue can be started or completed (e.g., database schema finalization).

Track each issue through Trello or JIRA, including time tracking for Planning, Development, and Review to ensure accuracy in tracking team velocity and task completion.

2.2 GitHub Issue Structure

There is an approximate format I would like to see within issues. This format represents any backend implementation, but sometimes some sections can be ommitted if business logic is not required.

IMPORTANT: At this point you should completely understand the improtance of Planning and Design Phases. Now we can use well structured information to transform business requirements into tehcnical solutions.

| **Task** | **Deadline**           |
|----------|-------------------------|
| [CRUD for Settings]() | [07/12/22:00]          |

### Problem

### Solution

### DB Changes

### Endpoints

### Models

### Serializers

### Views

### Schemas

### Services

### Tests

### Docs  

### Tasks

2.3 Github Issue Example

Please, find the following examples of completed issues.

Issue #1
Issue #2
Issue #3

Once you have completed an issue, assign it to me and it will be reviewed ASAP. I will leave the review/approve for further development.

IMPORTANT: Do not start the actual implementation of the feature until it has been approved by me. We may waste a lot of time having to hustle around or do not understand the actual bussiness requirement, so this should be confirmed.

alt text

3. Git Flow

Git Flow branching strategy.

To maintain an organized, clean, and scalable codebase this approach provides a clear structure for managing new features, hotfixes, and production releases, ensuring stability and allowing multiple developers to work on different tasks in parallel.

4. Branching Structure

Branch Type	Purpose	Naming Convention	Workflow
Master Branch	Holds stable, production-ready code. Only code that has passed thorough testing and review is merged here.	`master`	Only release or hotfix branches should merge into `master`. This branch is protected to prevent direct commits or pushes.
Feature Branches	Dedicated to a single feature or bug fix, facilitating isolated development and testing.	`feature/<feature-name>-jira_ticket_id`	Each feature/bug fix starts from the latest code in `master`. After completion, testing, and review, merge into `master`.
		`fix/<issue-description>-jira_ticket_id`	Examples: `feature/user-authentication-ABC1234`, `fix/login-bug-ABC1234`
Release Branches	Created to prepare a new version for deployment, allowing final testing, bug fixing, and documentation updates.	`release/<version-number>`	Create a release branch from `master` when all features are ready. Perform final tests, apply hotfixes, and update the changelog.
Hotfix Branches	Addresses urgent fixes to production code, handling issues discovered post-release.	`hotfix/<issue-description>`	Create a hotfix branch from `master`, apply the fix, then merge back into `master` to synchronize the fix.

5. Git Workflow [Template]

Creating a Feature Branch

Start by pulling the latest changes from master:

git checkout master
git pull origin master

Create a new feature branch:

git checkout -b feature/user-authentication

Implement code changes, committing frequently with clear messages:
```
git commit -m "Add JWT authentication for user login"
```
Committing and Pushing Changes
Regularly push your feature branch to the remote repository to allow for backups and collaboration:
```
git push origin feature/user-authentication
```
Creating a Pull Request (PR)
Once development is complete, create a Pull Request from feature/user-authentication to develop.
Use the PR template to include a detailed description of the changes, screenshots, and test results.
Request reviews from at least 2 other developers + QA to ensure quality and consistency.

6. Pull Requests

Please, find the following template and example which should be applied during creation of pull request.

PR Template
PR Example

IMPORTANT: This template should be filled in to each MR

7. Rebase Strategy for Feature Branches

Using a rebase strategy ensures a linear commit history, reducing the chances of merge conflicts and making it easier to trace changes. Here’s how to implement a rebase approach:

Sync with the Latest Code in master
Before pushing or merging your feature branch, make sure it’s up-to-date with master:
```
git checkout master
git pull origin master
```

Switch to your feature branch:

git checkout feature/user-authentication

Rebase Feature Branch onto master
Rebase your feature branch with the latest code in master:
```
git rebase master
```
If conflicts arise, resolve each conflict as you proceed, then continue the rebase:
```
git add <resolved-file>
git rebase --continue
```
Push Rebased Feature Branch
After successfully rebasing, you may need to force-push the updated feature branch to the remote repository:
```
git push origin feature/user-authentication --force
```

IMPORTANT: Please, do this carefully, ensure that it is tested, done properly and doesn't break anything.

8. PR Approval and Merging Process

Please, use the following checklist and follow steps described in delivery for PRs before merging it into master. Do not forget to track spent time on reviwew to understand how much time does it take for the task to complete.

8.1 Checklist

8.1 Delivery

IMPORTANT: Add a brief summary of changes and proves that you have actually tested this.

IMPORTANT: Everyone should attach the results of E2E testing as a part of the MR.

LGTM! I tested the key changes, and everything is working smoothly:

Login Endpoint: Logged in with valid credentials and got a success response (200 OK) along with the expected token:

{
  "token": "JWT_token_example",
  "message": "Login successful."
}

Additionally, tried to login with incorrect credentials, and received the correct error response (401 Unauthorized) with a clear message: "Invalid email or password". The token also works as expected for accessing protected routes—no issues here! Approved.

9. Notes

DO NOT FORGET TO ADJUST THE DB/ENDPOINTS which were completed during the Design phase (in case the initial design and implementation has been changed and discussed with a team).
If you don't know how to plan your issue in advance, please complete an investigation and think about it very deep. NEVER RUSH WITH A SOLUTION.
In case if you cannot reproduce the conditions or do not understand how to test the task properly, contact your TL or Yehor for additional support.
If you can't get the task done or seriously got stuck, ask for support, don't be alone.
Use the #reviews channel if the task is a bit of due date to push reviewers.

10. Changelog and Velocity

Maintaining a clear and structured changelog is essential for tracking the project’s evolution, changes made, and any notable improvements or fixes. This is sort of demonstration of implemented functionality for FE and Devops teams.

10.1 Changelog Structure

Version Number: Start each changelog entry with the release version (e.g., v1.0.1) and date of release.
Categories: Organize changes under clear categories:
New Features: Describe any new functionalities or modules added.
Improvements: Document enhancements to existing features or performance improvements.
Bug Fixes: List resolved bugs and issues with a brief explanation.
Security: Note any security patches or improvements made.
Description: Each change should have a concise, meaningful description explaining the impact or reason for the update.

10.2 Rules

Frequency: Update the changelog with every feature addition (which can affect the development of FE), bug fix, or improvement merged into the master branch.
Format Consistency: Use a consistent format and level of detail for each entry to maintain readability.
Assign Responsibility: The developer responsible for the PR must also update the changelog as part of the PR process, ensuring the change is documented before merging.

10.3 Changelog Example

## [v1.0.1] - 2024-10-30
### Features
-  (#124) Added user registration with JWT-based authentication. (@nickname)
-  (#128) Integrated Stripe API for secure payment processing. (@nickname)

### Improvements
- (#130) Enhanced product filtering to support category and price range.

### Bug Fixes
- (#122) Fixed issue causing incorrect password reset links in emails.
- (#125) Resolved pagination bug in product listing.

### Additional
- (#126) Updated password hashing to bcrypt for enhanced security.

This changelog will become public for releases and that's how FE developer will be able to understand the changes made to the project which will simplify work done.

11 Velocity Tracking

Velocity measures the team’s work output per sprint, serving as a baseline for planning and resource allocation.

Record the total points or estimated hours for tasks completed each week.
Calculate the velocity as a rolling average over the last three sprints for more stable estimates.

| Sprint 12/11-25/11 |

Developer	Total Story Points	Estimated Hours	Actual Hours Logged	Velocity (Points/Hours)
Dev A	6	30	28	6 points, 28 hours
Dev B	8	40	38	8 points, 38 hours
Dev C	6	30	29	6 points, 29 hours
	20	100	95	18 points, 95 hours

IMPORANT: These calculations are done in order to check how accurate estimates during planning and to know if the team is capable of completing tasks within specific and tight deadlines.

Do not worry if you don't show a good velocity from the beginning, we are all part of the team and this shouldn't be a problem to put a shoulder for support.