Working Agreement on Team Availability/Jira/PR Activity
- If you are away or on leave for more than two days, it is your individual responsibility to catch up on project updates by checking in with your teammates. Please ensure you are informed about any important developments or changes you might have missed.
- When updating a Jira story status to "In Progress," please remember to add a comment summarizing the current status or any relevant details. This helps anyone who missed the Daily Standup Meeting (DSM) quickly understand the progress or any impediments related to the task by reviewing the comments in Jira.
- If you encounter any blockers or issues with your tasks, please raise them during the DSM. This allows the team to address the problem promptly and enables anyone with potential solutions to assist.
- When teammates ask about the progress of your tasks, please respond politely and constructively, even if you have already updated the information in Jira. Open and respectful communication strengthens team collaboration.
- Always maintain professionalism, be courteous to your teammates, and follow workplace decorum in all communications.
- Senior and Mid need to approve the PR
- PR Shouldn't remain open for more than 2 days
- We are doing round robin process for release
BRANCHING STRATEGY:
We are following Git Flow Branching Strategy in our partner portal, that defines a strict branching strategy designed around the project release. It provides a robust framework for managing larger projects with multiple developers. Here’s a concise explanation of the Git Flow model:
Main Branches
1. main (or master) Branch:
• This branch contains the production-ready code.
• Only stable and tested code is merged into this branch.
• Releases are tagged in this branch.
2. develop Branch (In our scenario its feature_test):
• This branch contains the latest development changes.
• It is the integration branch for features and fixes.
• It is always kept in a deployable state.
Supporting Branches
1. Feature Branches:
• Branch off from: feature_test
• Merge back into:feature_test
• Naming convention: feature/*
• Used to develop new features for the upcoming release.
• Example: feature/user-authentication
2. Release Branches:
• Branch off from:feature_test
• Merge back into: main andfeature_test
• Naming convention: release/*
• Used to prepare for a new production release.
• Allows for minor bug fixes and preparing meta-data for a release.
• Example: release/1.0.0
Write Unit Test Cases:
It is important to write unit test cases for your API project whenever you implement new features. This ensures that your code is reliable, maintainable, and less prone to bugs. Additionally, using a testing framework like Bunit for your Blazor UI projects is a good practice to ensure the quality and correctness of your UI components.
We have implemented unit test cases for API projects using the xUnit framework and are planning to implement front-end unit test cases using Bunit.
Always ensure that all test cases pass before pushing your code to the feature_test branch.