docs(phase-6): revise context - single-instance deployment, Docker only, no scale testing

- Lock decision: Single-instance Docker deployment (not multi-site)
- Remove scale testing from Phase 6 scope (defer to v3)
- Simplify to 2 plans: Docker deployment + operational runbook
- Update success criteria to focus on reliability, not performance testing
This commit is contained in:
2026-04-22 18:17:45 +03:00
parent 4b7621fcd1
commit 4ea9625928

View File

@@ -1,55 +1,58 @@
# Phase 6: Deployment & Scale — Context & Strategic Overview # Phase 6: Docker Deployment — Context & Strategic Overview
**Phase Goal**: Production-ready multi-site deployment with automated setup, scale testing, and operational runbooks. **Phase Goal**: Production-ready single-instance Docker deployment with automated setup and operational runbooks.
**Duration**: 1 month **Duration**: 2-3 weeks (simplified scope)
**Target Version**: v2.0 stable **Target Version**: v2.0 stable
**CRITICAL DECISION**: Single-instance deployment (not multi-site). Docker containerization only. No scale testing.
--- ---
## Phase Overview ## Phase Overview
Phase 6 bridges the gap between fully-featured code (Phases 4.1 + 5) and production deployment at scale. After Phase 5 delivers search, exports, and quick quantity adjustment, the system needs: Phase 6 delivers containerized deployment for v2.0. After Phase 5 delivers search, exports, and quick quantity adjustment, the system needs:
1. **Containerization** — Reliable Docker/Compose setup for rapid multi-site rollout 1. **Containerization** — Reliable Docker/Compose setup for reliable deployment
2. **Automation** — Single-command deployment (environment agnostic) 2. **Automation** — Single-command deployment (`./deploy.sh`)
3. **Scale validation** — Prove system handles 10K items + 5 concurrent users without degradation 3. **Operational readiness** — Health checks, monitoring, runbook documentation
4. **Performance tuning** — Identify and fix bottlenecks revealed by load testing 4. **Documentation** — Clear deployment and troubleshooting guides for operators
5. **Operational readiness** — Backup/restore, disaster recovery, runbook documentation
**OUT OF SCOPE**: Scale testing, multi-site federation, performance optimization, multi-instance clustering
--- ---
## Key Decisions Made During Planning ## Key Decisions Made During Planning
### 1. Docker Strategy ### 1. Docker Strategy (LOCKED)
- **Existing**: docker-compose.yml and Dockerfiles already in place (backend/, proxy/) - **Existing**: docker-compose.yml and Dockerfiles already in place (backend/, proxy/)
- **Gap**: Automated deployment scripts, environment templates, CI/CD hooks - **Gap**: Automated deployment scripts, environment templates, health checks
- **Plan 1 Focus**: Enhance existing Dockerfiles → production-grade, add health checks, optimize layers - **Focus**: Enhance existing Dockerfiles → production-grade, add health checks, optimize layers
- **Multi-site**: Single docker-compose.yml template with `.env` overrides per site - **Deployment Target**: Single-instance Docker Compose (local development + production)
### 2. Deployment Automation ### 2. Deployment Automation (LOCKED)
- **Target**: `./deploy.sh` (single entry point) — no manual steps - **Target**: `./deploy.sh` (single entry point) — no manual steps
- **Scope**: Config validation, DB initialization, certificate generation, health checks - **Scope**: Config validation, DB initialization, certificate generation, health checks
- **Fallback**: Documented manual steps for troubleshooting - **Fallback**: Documented manual steps for troubleshooting
- **Testing**: Pre-flight checks (port availability, storage, permissions) - **Testing**: Pre-flight checks (port availability, storage, permissions)
### 3. Scale Testing Approach ### 3. Scale Testing (DEFERRED - NOT IN PHASE 6)
- **Load Profile**: 10K items + 5 concurrent users (realistic field scenario) - **Decision**: Application is single-instance. Scale testing (10K items + 5 concurrent users) deferred to v3.
- **Tools**: Locust (Python) for backend load testing, Playwright for frontend workflow - **Rationale**: Phase 5 delivered core features. Phase 6 focuses on reliable deployment, not load testing.
- **Metrics**: Response time <2s for search/scan, CPU/memory usage, sync reliability - **Future**: If multi-instance or multi-site deployment needed later, add scale testing then.
- **Plan 2 Focus**: Load testing infrastructure + performance baseline + optimization recommendations
### 4. Backup/Restore Philosophy ### 4. Operational Readiness (LOCKED)
- **Data**: SQLite DB + config files + certificate state - **Health Checks**: Docker healthchecks on all services
- **Versioning**: Backup includes timestamp + version number for easy rollback - **Monitoring**: Prometheus-style metrics endpoint (optional, documented)
- **Testing**: Automated restore test on each backup cycle - **Logging**: Centralized logs via Docker (stdout/stderr)
- **Plan 3 Focus**: Backup automation script, restore validation, documented RTO/RPO - **Documentation**: Runbook for deployment, troubleshooting, health monitoring
### 5. Operational Documentation ### 5. Operational Documentation (LOCKED)
- **Audience**: Ops teams deploying to new sites; minimal Docker/Python knowledge required - **Audience**: Ops teams deploying single-instance setups; minimal Docker/Python knowledge required
- **Format**: Runbook style (step-by-step checklists) - **Format**: Runbook style (step-by-step checklists)
- **Coverage**: Deployment, scaling, troubleshooting, health monitoring, upgrade path - **Coverage**: Deployment, monitoring, troubleshooting, upgrade path
- **OUT OF SCOPE**: Multi-site federation, scaling across instances
--- ---
@@ -71,59 +74,49 @@ Phase 6 bridges the gap between fully-featured code (Phases 4.1 + 5) and product
--- ---
## Technical Approach ## Technical Approach (SIMPLIFIED)
### Plan 1: Docker & Deployment Automation (Week 1-2) ### Plan 1: Docker & Deployment Automation (Week 1)
- Refine Dockerfiles (health checks, logging, layer optimization) - Refine Dockerfiles (health checks, logging, layer optimization)
- Create deployment automation script (`deploy.sh`) - Create deployment automation script (`./deploy.sh`)
- Environment template with validation - Environment template with validation (single-instance config)
- Pre-flight checks + error handling - Pre-flight checks + error handling
- Docker Compose enhancements (healthchecks, volumes, networking) - Docker Compose enhancements (healthchecks, volumes, networking)
- Health check integration tests
### Plan 2: Scale Testing & Performance (Week 2-3) ### Plan 2: Operational Runbook & Documentation (Week 2-3)
- Load testing framework (Locust) - Deployment runbook (step-by-step, fresh VM scenario)
- Database seeding (10K items with realistic categories) - Health monitoring checklist (startup, daily, weekly checks)
- Concurrent user simulation (5 users, multiple workflows) - Troubleshooting guide (common issues + solutions)
- Metrics collection (response time, CPU, memory) - Upgrade procedure documentation
- Bottleneck identification + optimization PR recommendations - Emergency procedures (container restart, data recovery)
- Health check automation - Optional: Prometheus metrics endpoint documentation
### Plan 3: Backup/Restore & Runbook (Week 3-4) **Scale Testing Moved to v3 Backlog** — Focus on single-instance reliability instead.
- Backup automation script (daily/weekly cycles)
- Restore validation + testing
- Runbook documentation (deployment, scaling, troubleshooting)
- Disaster recovery procedures
- Health monitoring guidelines
--- ---
## Success Criteria ## Success Criteria (SIMPLIFIED FOR SINGLE-INSTANCE)
### Deployment Automation ### Deployment Automation
- [ ] `./deploy.sh` deploys full stack in <5 minutes - [ ] `./deploy.sh` deploys full stack in <5 minutes
- [ ] Automatic DB initialization on first run - [ ] Automatic DB initialization on first run
- [ ] Health checks confirm all services running - [ ] Health checks confirm all services running
- [ ] Env validation prevents misconfiguration - [ ] Env validation prevents misconfiguration
- [ ] Works on clean Ubuntu 22.04+ LTS system - [ ] Works on clean Ubuntu 22.04+ LTS system (local Docker)
### Scale Testing ### Operational Documentation
- [ ] Load test with 10K items + 5 concurrent users completes - [ ] Deployment runbook (step-by-step, fresh VM scenario)
- [ ] Response times stable: search <500ms, scan <1s, sync <2s - [ ] Health monitoring checklist (startup, daily, weekly)
- [ ] CPU usage <70%, memory <2GB during load
- [ ] Sync reliability 99%+ (no dropped transactions)
- [ ] Baseline metrics documented for future comparisons
### Backup/Restore
- [ ] Backup script creates timestamped archives
- [ ] Restore fully recovers system state (DB + config)
- [ ] Zero data loss on restore test
- [ ] RTO <10 minutes, RPO 1 day (configurable)
### Documentation
- [ ] Deployment runbook (step-by-step, no domain knowledge required)
- [ ] Scaling guide (adding more users, larger DB)
- [ ] Troubleshooting guide (common issues + solutions) - [ ] Troubleshooting guide (common issues + solutions)
- [ ] Health monitoring checklist - [ ] Upgrade procedure documented
- [ ] Emergency procedures clear (restart, recovery)
### Quality Gates
- [ ] All Docker builds succeed with no warnings
- [ ] Health checks pass on fresh deployment
- [ ] All services accessible after deployment
- [ ] Documentation is accurate and complete
--- ---
@@ -151,12 +144,12 @@ Phase 6 bridges the gap between fully-featured code (Phases 4.1 + 5) and product
## Blockers & Workarounds ## Blockers & Workarounds
### Known Constraints ### Known Constraints
1. **SQLite single-writer limitation** — No true concurrent writes; acceptable for 5 users 1. **Certificate persistence** — Caddy certs need stable volume mount
- Workaround: WAL mode enabled, connection pooling limits contention
2. **Certificate persistence** — Caddy certs need stable volume mount
- Workaround: Use persistent named volumes for `/data/caddy_*` - Workaround: Use persistent named volumes for `/data/caddy_*`
3. **Environment variability** — Different orgs may have different network configs 2. **Environment variability** — Different deployments may have different network configs
- Workaround: Pre-flight checks validate critical assumptions (ports, storage) - Workaround: Pre-flight checks validate critical assumptions (ports, storage)
3. **Single-instance limitation** — Application designed for single-instance; no clustering
- Accepted constraint for v2 scope
### Potential Issues ### Potential Issues
- Docker daemon availability (some restricted environments) - Docker daemon availability (some restricted environments)
@@ -165,17 +158,16 @@ Phase 6 bridges the gap between fully-featured code (Phases 4.1 + 5) and product
--- ---
## Execution Checklist ## Execution Checklist (UPDATED FOR SINGLE-INSTANCE SCOPE)
- [ ] Phase 5 complete + all tests passing - [x] Phase 5 complete + all tests passing
- [ ] Create Phase 6 directory structure - [x] Create Phase 6 directory structure
- [ ] Write 3 PLAN.md files (Deployment, Scale Testing, Backup/Runbook) - [ ] Update PLAN.md files to match simplified scope (Docker + runbook only)
- [ ] Execute Plan 1: Docker + deploy.sh - [ ] Execute Plan 1: Docker + deploy.sh automation
- [ ] Execute Plan 2: Load testing + performance baseline - [ ] Execute Plan 2: Operational runbook & documentation
- [ ] Execute Plan 3: Backup/restore + runbook - [ ] Integration testing (fresh deployment + health checks)
- [ ] Integration testing (full deployment cycle)
- [ ] Documentation review - [ ] Documentation review
- [ ] Commit all changes with `feat(6): phase 6 planning complete...` - [ ] Commit all changes with `feat(6): phase 6 deployment automation (single-instance)`
- [ ] Tag v2.0-rc1 for release candidate validation - [ ] Tag v2.0-rc1 for release candidate validation
--- ---