blob: 00b4dddd273f63920c2f0922d74aa773c45d5d24 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
|
# Workflow
## References
https://nvie.com/posts/a-successful-git-branching-model/ \
https://learn.microsoft.com/en-us/azure/devops/repos/git/merging-with-squash?view=azure-devops
## Branching
*Based off GitFlow but slightly modified*
- There are two main branches
- `main` - production-ready code
- `development` - integration branch for features
- `staging` - represents the current staging state
- In addition, there are additional branches
- Feature branches - for new features and non-urgent bugfixes
- Hotfix branches - probably won't be used but for critical bugs in production (this is what testing should prevent)
- Release branches - for preparation of production releases
- Feature branches - e.g. `feature/short-description`
- Bugfix branches - e.g. `bugfix/short-description`
- Hotfix branches - e.g. `hotfix/short-description`
- Release branches - e.g. `release/vX.Y.Z`
### Examples
```
feature/add-data-extractor
bugfix/fix-s3-upload-error
hotfix/security-patch
release/v1.0.0
```
## Environments
1. Development - where active development and initial testing occur
2. Staging - for integration testing and final checks before production
3. Production - live and stable environment
## Deployment
1. `main` - represents the current production state
2. `develop` - represents the integration branch for features and non-urgent fixes
3. `staging` - represents the current staging state
## Staging Flow
1. Create feature branches from `develop` & merge completed features back into `develop`
2. When the `develop` branch is ready for testing, create a `staging` branch from `develop`
3. Deploy the `staging` branch to the staging environment and perform our unit-tests
4. If staging tests pass, create a `release/vX.Y.Z` branch from `staging`
5. Make any final adjustments in the `release/vX.Y.Z` branch
6. Once we have approved the changes in the `release/vX.Y.Z` branch, merge into `main`
7. Tag the release in `main`
### Notes
- No new features should be included in the release branches and any new features should be merged into `develop` for the next release cycle
## Commit Messages
Please follow the conventional commits specification:
```
<type>[optional scope]: <description>
<optional body>
[optional footer(s)]
```
### Types
- feat: new features
- fix: bugfixes
- docs: documentation-only changes
- style: changes that do not affect the meaning of the code
- refactor: code changes that neither fix bugs nor adds features
- perf: code changes that improve performance
- test: adding tests or correcting existing tests
- chore: changes to build process or tools/libraries (probably not needed)
- infra: changes to infrastructure configuration (e.g. Terraform)
### Examples
```
feat(extract): add automatic scheduling for data ingestion
docs: update README with project setup instructions
```
Configuration files for things such as Terraform isn't native to Conventional Commits, but we can add our own:
```
infra(tf): update S3 bucket policy
```
If the Terraform change involves a fix, you may combine `fix` and `infra`:
```
fix(infra): ...
```
|
