mirror of
https://github.com/frappe/frappe_docker.git
synced 2026-06-17 13:55:08 +00:00
128 lines
4 KiB
Markdown
128 lines
4 KiB
Markdown
# Easy-Docker Development Team Process
|
|
|
|
## Purpose
|
|
|
|
This document defines the working model for the easy-docker team.
|
|
Focus is process, responsibilities, and execution flow for ongoing refactoring and feature work.
|
|
|
|
## Team Setup
|
|
|
|
- Lead Developer
|
|
- Owns scope, priorities, and release decisions.
|
|
- Resolves conflicts between technical proposals.
|
|
- Approves final merge readiness.
|
|
- Senior Developer A (Correctness)
|
|
- Reviews control flow, edge cases, and failure behavior.
|
|
- Validates data handling, state transitions, and rollback paths.
|
|
- Checks defensive programming and explicit error handling.
|
|
- Senior Developer B (Architecture)
|
|
- Reviews modularity, coupling, and naming consistency.
|
|
- Drives DRY/KISS refactors and shared helper extraction.
|
|
- Validates maintainability and testability.
|
|
- Implementation Developer
|
|
- Delivers code changes according to approved scope.
|
|
- Keeps behavior stable unless change is explicitly requested.
|
|
- Adds/update docs for structure and flow changes.
|
|
- QA/Verification Owner
|
|
- Runs pre-commit and targeted checks.
|
|
- Executes reproducible manual test matrix for wizard paths.
|
|
- Reports pass/fail with concrete reproduction steps.
|
|
|
|
## Working Agreement
|
|
|
|
- No hidden behavior changes during refactors.
|
|
- Source-of-truth decisions must be explicit and documented.
|
|
- New code must prefer existing helpers over duplicated logic.
|
|
- Every change batch must be reviewable by concern (flow, env, compose, ui).
|
|
|
|
## Daily Process (Tomorrow Plan)
|
|
|
|
1. Kickoff (15 min)
|
|
- Confirm target scope for the day.
|
|
- Confirm "no functional change" boundaries.
|
|
- Assign owners for implementation and verification.
|
|
2. Design sync (20 min)
|
|
- Compare at least two technical options for non-trivial edits.
|
|
- Select one approach with short tradeoff note.
|
|
3. Implementation blocks
|
|
- Work in small vertical batches (one concern per batch).
|
|
- Keep public function contracts stable where possible.
|
|
- Update docs in the same batch when structure changes.
|
|
4. Review blocks
|
|
- Senior A reviews correctness and failure paths.
|
|
- Senior B reviews architecture and maintainability.
|
|
- Lead resolves conflicts and accepts/rejects batch.
|
|
5. Verification block
|
|
- Run pre-commit for changed files.
|
|
- Run targeted manual flow checks.
|
|
- Record results in short checklist format.
|
|
6. Handover
|
|
- Write what is done, what is pending, and next first task.
|
|
- List any blockers with owner and proposed resolution.
|
|
|
|
## Implementation Workflow
|
|
|
|
1. Define scope and constraints.
|
|
2. Map affected files/functions.
|
|
3. Propose options and select approach.
|
|
4. Implement with small commits by concern.
|
|
5. Validate with checks and manual path coverage.
|
|
6. Document final state and next steps.
|
|
|
|
## Review Workflow
|
|
|
|
1. Findings-first review format.
|
|
2. Severity order: BLOCKER, HIGH, MEDIUM, LOW.
|
|
3. Each point must include file reference and reason.
|
|
4. Lead decision:
|
|
- Approved
|
|
- Approved with conditions
|
|
- Not approved
|
|
|
|
## Test and Verification Matrix (Minimum)
|
|
|
|
- Create new production stack and complete wizard.
|
|
- Create new development stack and complete wizard.
|
|
- Manage existing stack:
|
|
- Apps -> Generate apps.json
|
|
- Apps -> Select apps and branches
|
|
- Docker -> Generate docker compose from env
|
|
- Docker -> Start stack in Docker Compose (single-host topology)
|
|
- Abort/Back paths:
|
|
- Back navigation in each submenu
|
|
- Abort wizard with rollback
|
|
- Validation paths:
|
|
- Domain validation error then correction
|
|
- Branch selection from apps catalog (including back-navigation)
|
|
|
|
## Definition of Done (Team)
|
|
|
|
- Scope completed with no unplanned behavior change.
|
|
- No avoidable duplication introduced.
|
|
- Review completed by both senior roles.
|
|
- Lead verdict documented.
|
|
- Verification evidence recorded.
|
|
- Handover notes prepared for next workday.
|
|
|
|
## Handover Template
|
|
|
|
Use this at day end:
|
|
|
|
```text
|
|
Date:
|
|
Completed:
|
|
- ...
|
|
|
|
In Progress:
|
|
- ...
|
|
|
|
Next First Task:
|
|
- ...
|
|
|
|
Blockers:
|
|
- <owner> - <issue> - <proposed action>
|
|
|
|
Verification:
|
|
- pre-commit: <pass/fail + note>
|
|
- manual matrix: <pass/fail + note>
|
|
```
|