Development Workflow
Internal process the MIP team follows for every feature, fix, or chore landing in dev.
Lifecycle
1. Open branch
2. Implement
3. Tester (Burak) verifies
4. After tester approval: open PR
5. Merge to dev
Stages
1. Open branch
Branch from the right base per the team rule:
- mip-frontend-server → branch from
dev - mip-backend-server → branch from
dev - mip-frontend-web → branch from
main - mip-health-check → branch from
dev
Naming convention: feature/<name>, fix/<name>, chore/<name>, test/<name>.
A development that touches several repos uses exactly the same branch name in every repo. The name is what ties the parts together: the release pipeline gives the whole development one product version, and waits with that version until the branch is merged in every repo that has it. A branch that exists in one repo only gets a version of its own.
2. Implement
Code, write tests, keep commits atomic, follow Conventional Commits (feat:, fix:, docs:, test:, chore:, ci:, refactor:, perf:).
Push intermediate progress to the feature branch — never directly to dev/main.
3. Tester verifies
Tester (Burak) pulls the feature branches involved and runs the test plan against a local or test-server deployment.
For features touching multiple repos, the tester pulls each branch with the same name (e.g. feature/<name>) and runs them together.
4. Open PR (after tester approval only)
Only after Burak signs off on the test plan does the developer open the PR.
PR description must include:
- Linked spec / plan (if any)
- Test plan checklist with results
- Repos & branches touched
5. Merge to dev
After at least one code-review approval, the PR is merged into dev.
Versions
The product version is x.y.z.t:
| Part | Increases when | Who triggers it |
|---|---|---|
t | an image is built from dev - once per merged development, however many repos it spans | automatic |
z | dev is promoted to staging (about every two weeks) | the Architect asks for the promotion |
y | staging is promoted to main (about every two months) | the Architect asks for the promotion |
x | the platform changes fundamentally (for example a framework generation) | only the Architect, explicitly |
When a part increases, the parts to its right start again at 0. Nobody edits version numbers by hand; the Release Wave claims them.
Rule
No PR before tester approval. Skipping this step means broken features hit dev, blocking everyone else.