new: Documentation for Branching and Code Reviews,
This commit is contained in:
parent
b9a76775ae
commit
65cead18aa
5 changed files with 166 additions and 4 deletions
57
branching-code-review-process.md
Normal file
57
branching-code-review-process.md
Normal file
|
|
@ -0,0 +1,57 @@
|
|||
# Branching and Code Review Process
|
||||
|
||||
This document outlines the guidelines and expectations for effective code branching, review, and merging within a regulated Azure DevOps environment. Emphasis is placed on the four-eyes principle and traceability of changes.
|
||||
|
||||

|
||||
|
||||
## Traceability
|
||||
|
||||
- Utilize Azure Boards for work item tracking, linking commits and PRs to their respective items.
|
||||
- Enforce policies in Azure Repos to require reviews, approvals, optionally linked work items for merges.
|
||||
- Use annotations in your code for significant changes, providing explanations and linking back to documentation or specs.
|
||||
|
||||
## Create a Branch
|
||||
|
||||
- Create branches under subfolders aligned with their purpose (`new`, `update`, `fix`, `delete`) following the semantic versioning linked with release notes documentation.
|
||||
- Use descriptive branch names that reflect the feature or fix.
|
||||
|
||||
## Apply Changes
|
||||
|
||||
- Commit changes regularly with clear, concise messages that follow semantic versioning.
|
||||
- Include work item or issue numbers in commit messages for traceability.
|
||||
|
||||
## Manual Testing
|
||||
|
||||
- Perform local linting to ensure code quality.
|
||||
- Preview changes locally, especially for UI-related updates.
|
||||
- Run unit tests and ensure they pass before pushing code.
|
||||
|
||||
## Create a Pull Request
|
||||
|
||||
- Rebase your branch on the latest main branch to simplify the review process and prevent conflicts.
|
||||
- Ensure your PR description is detailed, linking back to any related work items or issues for context.
|
||||
- Tag relevant team members for review and set a deadline if necessary.
|
||||
|
||||
## Automated Testing
|
||||
|
||||
- Optional part, automated tests can be defined within a pipeline that is triggered automnatcally when a Pull Request is created.
|
||||
- Ensure all automated tests pass, including unit, integration, and end-to-end tests.
|
||||
- Check for code coverage and ensure it meets the project's standards.
|
||||
|
||||
## Review a Pull Request
|
||||
|
||||
- Focus on maintainability, readability, and scalability of the code.
|
||||
- Ensure new code adheres to project standards and integrates well with existing codebase.
|
||||
- Provide constructive feedback, highlighting both strengths and areas for improvement.
|
||||
|
||||
## Merge a Pull Request
|
||||
|
||||
- Ensure all PR checks pass (build, test pipelines, and any additional checks your team requires).
|
||||
- Only merge after at least one other team member has approved the changes.
|
||||
- Upon merging, the main branch triggers a CI/CD pipeline to deploy changes to a staging environment for further testing.
|
||||
|
||||
## Post-Merge
|
||||
|
||||
- Delete the feature branch to keep the repository clean and manageable.
|
||||
- Update any project tracking tools to reflect the completion of tasks.
|
||||
- Review deployment results and ensure no issues in the staging environment before promoting to production.
|
||||
Loading…
Add table
Add a link
Reference in a new issue