Merged in feature/rewrite_readme (pull request #194)

Rewrite README

Approved-by: Umang Mistry
This commit is contained in:
Michael McGuinness
2024-09-25 14:02:15 +00:00
+15 -47
View File
@@ -6,60 +6,28 @@ This guide outlines the naming conventions, branching strategy, and merging proc
## Branch Naming Conventions
### Feature Branches
- **Feature Branch**: `feature/<name>`
- Example: `feature/add_build_stage`
- **Bugfix Branch**: `bugfix/<name>`
- Example: `bugfix/pages_duplication`
- **Hotfix Branch**: `hotfix/<name>`
- Example: `hotfix/deployment_failure`
- **Naming Convention**: `feature/<workstream>_<version>`
- Example: `feature/streamlit_UI0_1.0`, `feature/textract_1.5`
## ....
## Branching Strategy
### Creating Feature Branches
### Creating Branches
1. **From Release Branch**: Create a feature branch from `release/uat_<version>`
- Example: To develop Streamlit UI1 v1.5, create `feature/streamlit_UI1_1.5` from `release/uat_1.0`
### Merging Process
#### Merging to DEV
1. **Initial Merge**: Once the feature is ready, merge the feature branch into DEV.
2. **Verification**: Ensure the functionality is verified in DEV.
#### Merging to UAT
1. **Approval Requirement**: Merge to UAT requires approval from default reviewers (Anup / Priya / Umang).
2. **Post-Approval Merge**: After approval, merge the same feature branch that was verified in DEV into UAT.
#### Merging to PROD
1. **Final Merge**: Once the feature is tested and approved in UAT, merge it into PROD.
2. **Complete Versions**: Deployment to PROD should only be done with complete versions (e.g., v1.0, v2.0) with an appropriate release branch in place.
## State of Branches
### After Initial Release (v1.0)
| Workstream | DEV | UAT | PROD |
|------------|-----|-----|------|
| Streamlit | 1.0 | 1.0 | 1.0 |
| Textract | 1.0 | 1.0 | 1.0 |
| DevOps | 1.0 | 1.0 | 1.0 |
| Data | 1.0 | 1.0 | 1.0 |
### After Streamlit 1.5 and Textract 1.5
| Workstream | DEV | UAT | PROD |
|------------|-----|-----|------|
| Streamlit | 1.5 | 1.5 | 1.0 |
| Textract | 1.5 | 1.5 | 1.0 |
| DevOps | 1.0 | 1.0 | 1.0 |
| Data | 1.0 | 1.0 | 1.0 |
## Merge Restrictions
- **Workstream Specific Changes**: For feature branches, only changes in the respective folder are allowed. Other changes require a separate feature branch. This ensures that workstream changes are deployed to the respective infra.
- **Merge Approval**: Merging into DEV, UAT or PROD requires approval from default reviewers.
1. Create a feature branch from `main` using the appropriate naming convention.
2. Create a small and complete change. `main` must always have deployable code.
3. Create a Pull Request back to `main`.
4. Ensure all checks have passed.
5. Merge new code.
6. Ensure the functionality is verified in the dev environment.
## Refer to the branching guide in Confluence for more info on this
---
This guide ensures that all team members follow the best practices for branch management and releases.
This guide ensures that all team members follow the best practices for branch management and releases.