Ana içeriğe geç

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>.

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.

CI then automatically bumps the staging version when the dev-to-staging promotion runs.

Rule​

No PR before tester approval. Skipping this step means broken features hit dev, blocking everyone else.