Krow/Krow-workspace
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: add comprehensive release process documentation and version file references

Browse Source 
- Introduced RELEASE_VISUAL_GUIDE.md for a visual overview of the release pipeline, including development, staging, and production phases.
- Created RELEASE_WORKFLOW.md detailing step-by-step release procedures for single and multi-product releases, including hotfix processes.
- Added VERSION_FILES_REFERENCE.md to outline all necessary version file updates for each product during releases, ensuring consistency and completeness.
This commit is contained in:
Achintha Isuru
2026-03-05 10:49:09 -05:00
parent faae6c07d5
commit 085445e730
13 changed files with 4650 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

509
RELEASE_IMPLEMENTATION.md Normal file
View File

@@ -0,0 +1,509 @@
# Release Strategy Implementation Guide
This guide walks you through implementing the tagging and release strategy for KROW Workforce.
---
## 📍 Phase 1: Initial Setup (Do This First)
### Step 1: Review and Approve Strategy
1. Read [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md)
2. Get team feedback
3. Customize if needed (adjust cadence, naming, etc.)
4. Commit to this approach
### Step 2: Verify Current State
Check current versions of all products:
```bash
# Mobile
cat apps/mobile/apps/staff_app/pubspec.yaml | grep "^version:"
cat apps/mobile/apps/client_app/pubspec.yaml | grep "^version:"
# Web
cat apps/web/package.json | grep '"version"'
# Backend
cat backend/command-api/package.json | grep '"version"'
cat backend/core-api/package.json | grep '"version"'
```
Current expected state:
```
Staff Mobile: 0.1.0+?
Client Mobile: 0.1.0+?
Web Dashboard: 0.0.0
Command API: 0.1.0
Core API: 0.1.0
```
### Step 3: Create Initial Dev Tags
Create retrospective tags for the current state. This establishes a baseline.
```bash
# Navigate to repo
cd /Users/achintha/Documents/GitHub/krow-workforce
# Create tags for current development versions
# (These mark the current checkpoint, not retrospective releases)
git tag -a staff-mobile/dev-v0.1.0 -m "Staff Mobile v0.1.0 - Initial development release"
git tag -a client-mobile/dev-v0.1.0 -m "Client Mobile v0.1.0 - Initial development release"
git tag -a web-dashboard/dev-v0.0.0 -m "Web Dashboard v0.0.0 - Pre-release"
git tag -a command-api/dev-v0.1.0 -m "Command API v0.1.0 - Initial development release"
git tag -a core-api/dev-v0.1.0 -m "Core API v0.1.0 - Initial development release"
# Push all tags to remote
git push origin --tags
# Verify tags were created
git tag -l "*" --sort=-version:refname
```
Expected output:
```
core-api/dev-v0.1.0
command-api/dev-v0.1.0
client-mobile/dev-v0.1.0
staff-mobile/dev-v0.1.0
web-dashboard/dev-v0.0.0
```
---
## 📍 Phase 2: GitHub Configuration
### Step 1: Enable Branch Protection for Production Tags
1. Go to your GitHub repo → Settings → Branches
2. Click "Add rule"
3. Configure as follows:
```
Branch name pattern: */prod-v*
Require a pull request before merging: ✅ ON
Require approvals: ✅ ON (1+ approvals)
Dismiss stale pull request approvals: ✅ ON
Require status checks to pass: ✅ ON
Require branches to be up to date before merging: ✅ ON
Include administrators: ✅ ON
Allow force pushes: ❌ OFF
Allow deletions: ❌ OFF
```
4. Click "Create"
### Step 2: Configure Required Status Checks
Status checks that must pass before merging:
- `build / test` - Unit and integration tests
- `build / lint` - Code quality checks
- `build / security-scan` - Security validation
(These should already exist from your CI/CD pipeline)
### Step 3: Setup Release Notes Template
1. Go to Settings → Releases → Set up a release
2. Add this template:
```markdown
## Release Notes: [Product] v[Version]
**Release Date**: [Date]
**Environment**: [dev/staging/prod]
### 🎯 What's New
### ✨ Features
- Feature 1
- Feature 2
### 🔧 Improvements
- Improvement 1
- Improvement 2
### 🐛 Bug Fixes
- Bug fix 1
- Bug fix 2
### 📦 Dependencies & Compatibility
**Requires:**
- Backend API v[X.X.X] or higher
- [Other dependencies]
**Compatible with:**
- [Previous version compatibility]
### 📥 Installation
[Download links and installation instructions]
### ⚠️ Known Issues & Workarounds
- Issue 1: [description] (Workaround: ...)
### 🔄 Migration Guide
[Steps for upgrading from previous version]
### 📞 Support
For issues: support@krow-workforce.com
```
---
## 📍 Phase 3: CI/CD Integration (CodeMagic)
### Update CodeMagic for Automated Tagging (Optional)
Edit `codemagic.yaml` to automatically create tags on successful builds:
```yaml
workflows:
mobile-client-build:
on:
push:
branches:
- main
# ... existing config ...
# Add this section
on_success:
- |
if [ "$CI_BRANCH" = "main" ]; then
VERSION=$(grep "^version:" apps/mobile/apps/client_app/pubspec.yaml | cut -d' ' -f2)
git tag -a client-mobile/dev-${VERSION} \
-m "Client Mobile ${VERSION} - Development build from CodeMagic"
git push origin client-mobile/dev-${VERSION}
fi
```
(Optional - can be done manually initially)
---
## 📍 Phase 4: Create Release Documentation
### Copy Release Checklist Template
Create a file for release planning:
```bash
mkdir -p docs/releases
```
Create `docs/releases/RELEASE_TEMPLATE.md`:
```markdown
# Release Plan: [Product] v[Version]
**Status**: Draft / In Progress / Completed
**Target Date**: [Date]
**Release Manager**: [Name]
## Scope
[Description of features/fixes in this release]
## Pre-Release Tasks (48h before)
- [ ] All PRs merged and code reviewed
- [ ] All tests green (unit, integration, E2E)
- [ ] No lint/type errors
- [ ] Mobile builds succeed on CodeMagic
- [ ] Performance benchmarks acceptable
- [ ] Security scan passed
- [ ] CHANGELOG.md updated with all changes
- [ ] Documentation updated
- [ ] Staging environment prepared for testing
## Release Day Tasks
- [ ] Create release branch: `release/[product]-v[version]`
- [ ] Update version in all relevant files
- [ ] Commit and push release branch
- [ ] Create git tags (staging)
- [ ] Deploy to staging environment
- [ ] Run smoke tests
- [ ] Get sign-off from product owner
## Post-Release Tasks (24h after)
- [ ] Monitor error logs
- [ ] Verify all features work end-to-end
- [ ] Performance is acceptable
- [ ] Create production tags
- [ ] Deploy to production
- [ ] Final verification
- [ ] Create GitHub Release page
- [ ] Announce release to users
## Rollback Plan (if needed)
```
Issue Found: [description]
Severity: Critical / High / Medium
Action: Rollback to v[previous-version]
Hotfix: [version bump plan]
```
## Outcomes
**Release Date**: [Actual date]
**Status**: ✅ Successful / ⚠️ Issues / 🚫 Rolled back
[Additional notes]
```
---
## 📍 Phase 5: Team Training
### Create Runbook for Team
Share [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) with your team
### Conduct Training Session
**Agenda (30 minutes):**
1. Explain versioning strategy (5 min)
2. Walk through release workflow (10 min)
3. Demo: Create a test tag (10 min)
4. Q&A (5 min)
### Sample Demo Commands
```bash
# Everyone runs these to practice
# 1. See existing tags
git tag -l
# 2. Create a test tag (won't push)
git tag -a test/demo-v0.0.1 -m "Demo tag for training"
# 3. View tag details
git show test/demo-v0.0.1
# 4. Delete test tag
git tag -d test/demo-v0.0.1
```
---
## 📍 Phase 6: First Real Release
### Plan Your First Staging Release
Let's do: **Staff Mobile v0.2.0** (next development version)
### 1. Prepare Changes
```bash
# Make your feature/fix commits normally
git checkout main
git pull origin main
# Create feature branches as usual
git checkout -b feature/some-feature
# ... make changes ...
git commit -m "feat(staff-mobile): Add new feature"
git push origin feature/some-feature
# Create PR, review, merge
```
### 2. Create Release Branch
```bash
# Start release
git checkout main
git pull origin main
git checkout -b release/staff-mobile-v0.2.0
```
### 3. Bump Version
```bash
# Edit: apps/mobile/apps/staff_app/pubspec.yaml
# Change: version: 0.1.0+5 → version: 0.2.0+6
nano apps/mobile/apps/staff_app/pubspec.yaml
```
### 4. Update CHANGELOG
```bash
nano CHANGELOG.md
# Add at top:
# | 2026-03-05 | Staff Mobile 0.2.0 | Feature: [description] |
```
### 5. Commit & Tag
```bash
git add .
git commit -m "chore(staff-mobile): bump version to 0.2.0"
git push origin release/staff-mobile-v0.2.0
# Create and push tag
git tag -a staff-mobile/staging-v0.2.0 -m "Staff Mobile v0.2.0 - Staging release"
git push origin staff-mobile/staging-v0.2.0
# Verify
git tag -l "staff-mobile/*" --sort=-version:refname
```
### 6. Deploy & Test
```bash
# Deploy to staging environment
# (Use your deployment scripts or manual process)
# Run tests
make test-mobile-staff
# Get team QA approval
```
### 7. Promote to Production
```bash
# Create production tag
git tag -a staff-mobile/prod-v0.2.0 -m "Staff Mobile v0.2.0 - Production release"
git push origin staff-mobile/prod-v0.2.0
# Deploy to production
# (Use your deployment scripts)
```
### 8. Create GitHub Release
1. Go to https://github.com/[your-org]/krow-workforce/releases
2. Click "Draft a new release"
3. Fill in:
- Tag: `staff-mobile/prod-v0.2.0`
- Title: `Staff Mobile v0.2.0`
- Description: Copy from CHANGELOG
- Add APK/AAB as attachments (if available)
4. Click "Publish release"
---
## 📋 Communication Plan
### For Each Release
1. **Announcement** (release day)
```
📱 Staff Mobile v0.2.0 released!
Includes: [feature summary]
Available: [iOS/Android app stores]
```
2. **Status Updates** (during staging QA)
```
🔄 Staff Mobile v0.2.0 in staging for testing
Expected production release: [date]
```
3. **Post-Release** (24h after)
```
✅ Staff Mobile v0.2.0 now in production
All systems normal. No issues reported.
```
4. **If Issues**
```
⚠️ Staff Mobile v0.2.0 - Hotfix in progress
Rollback to v0.1.0 - No impact to users
ETA for fix: [time]
```
---
## 🔧 Troubleshooting
### Problem: Tag Already Exists
```bash
# If you try to create a tag that exists:
error: **/prod-v0.1.0 already exists
# Solution: Delete and recreate
git tag -d staff-mobile/dev-v0.1.0
git push origin --delete staff-mobile/dev-v0.1.0
git tag -a staff-mobile/dev-v0.1.0 -m "New message"
git push origin staff-mobile/dev-v0.1.0
```
### Problem: Can't Push Tags
```bash
# Error: remote permission denied
# Solution: Ensure you have push access
git credential-osxkeychain erase host=github.com # Re-authenticate
# Then try again
git push origin --tags
```
### Problem: Version Not Updated Everywhere
```bash
# Verify all locations have same version
grep -r "0.2.0" apps/mobile/apps/*/pubspec.yaml
grep '"0.2.0"' apps/web/package.json
grep '"0.2.0"' backend/*/package.json
grep 'build_version: "0.2.0"' codemagic.yaml
# Update any missing locations
```
---
## ✅ Validation Checklist
After implementing this strategy, verify:
- [ ] Initial dev tags created (v0.1.0 for all products)
- [ ] GitHub branch protection configured for prod tags
- [ ] Release template documented in repo
- [ ] Team trained on release process
- [ ] CHANGELOG.md in place and tracked
- [ ] First staging release completed successfully
- [ ] GitHub Release page created for first release
- [ ] Communication plan working
---
## 🎯 Next Steps
1. ✅ Review RELEASE_STRATEGY.md with team
2. ✅ Complete Phase 1 setup (create initial tags)
3. ✅ Configure GitHub (Phase 2)
4. ⏳ First release (Staff Mobile v0.2.0) planned for [date]
5. ⏳ Establish release cadence (weekly dev, bi-weekly staging, monthly prod)
---
## 📞 Questions?
Reference documents:
- [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md) - Full strategy
- [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) - Step-by-step workflows
- [CHANGELOG.md](./CHANGELOG.md) - Version history
---
**Created**: 2026-03-05
**Status**: Ready for Implementation

411
RELEASE_INDEX.md Normal file
View File

@@ -0,0 +1,411 @@
# Release Documentation Index
**🎯 Start here!** This page helps you find the right document for your needs.
---
## 🔍 Find What You Need
### "I want to understand the release strategy"
1. Start: [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md) (15 min read)
2. Visualize: [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) (10 min read)
3. Deep dive: [RELEASE_IMPLEMENTATION.md](./RELEASE_IMPLEMENTATION.md)
### "I need to perform a release right now"
1. Quick: [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md) (2 min scan)
2. Execute: [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) (find your scenario)
3. Reference: [VERSION_FILES_REFERENCE.md](./VERSION_FILES_REFERENCE.md) (which files to edit)
### "I'm setting up the release process for the first time"
1. Follow: [RELEASE_IMPLEMENTATION.md](./RELEASE_IMPLEMENTATION.md) (Phase by phase)
2. Configure: [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md) → GitHub section
3. Train: Use [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) for team
### "I need to train my team"
1. Overview: [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md)
2. Visuals: [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) (show diagrams)
3. Hands-on: Walk through [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) together
4. Reference: Give each [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md)
### "I'm doing a specific type of release"
#### **Releasing Staff Mobile v0.2.0 (Single Product)**
1. Steps: [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) → "Release a single product"
2. Files: [VERSION_FILES_REFERENCE.md](./VERSION_FILES_REFERENCE.md) → "Staff Mobile App"
3. Checklist: [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md) → "Pre-tag checklist"
#### **Coordinated Release All Products v1.0.0**
1. Plan: [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md) → "Release Cadence"
2. Execute: [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) → "Multi-Product Coordinated"
3. Deploy: [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) → "Deployment Order"
#### **Emergency Hotfix (Critical Bug)**
1. Steps: [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) → "Hotfix Release"
2. Fast: [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md) → "Common Tasks"
3. Order: [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) → "Hotfix Flow"
### "I need to update version numbers"
→ [VERSION_FILES_REFERENCE.md](./VERSION_FILES_REFERENCE.md) (Product-by-product guide)
### "I need git commands"
→ [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md) → "Quick Commands"
### "I'm troubleshooting an issue"
→ [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md) → "Troubleshoot"
### "I need to communicate a release to stakeholders"
→ [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) → "Status Page Template"
### "I want to automate releases"
→ [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) → "Automation Scripts"
---
## 📚 Document Overview
### [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md)
**The Master Document**
| Aspect | Details |
|--------|---------|
| **Purpose** | Canonical strategy reference |
| **Audience** | Technical leads, architects |
| **Length** | ~300 lines |
| **Read Time** | 15-20 min |
| **Key Topics** | Versioning, naming, cadence, dependency order, rollback |
| **Use When** | Making strategic decisions |
**Sections:**
- Semantic Versioning strategy
- Tag naming convention
- Release cadence (dev/staging/prod)
- Product dependencies
- Release checklist
- Protected tags setup
- Rollback procedures
---
### [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md)
**The Execution Guide**
| Aspect | Details |
|--------|---------|
| **Purpose** | Step-by-step release instructions |
| **Audience** | Developers, release engineers |
| **Length** | ~400 lines |
| **Read Time** | 20-30 min (skim) / 60 min (full) |
| **Key Topics** | Quick start, multi-product, hotfix, git commands |
| **Use When** | Actually performing a release |
**Sections:**
- Quick start (single product)
- Multi-product coordinated release
- Hotfix procedure with steps
- Git commands reference
- Useful scripts to create
- Release checklist template
---
### [RELEASE_IMPLEMENTATION.md](./RELEASE_IMPLEMENTATION.md)
**The Setup Guide**
| Aspect | Details |
|--------|---------|
| **Purpose** | First-time setup and implementation |
| **Audience** | DevOps, release engineering |
| **Length** | ~500 lines |
| **Read Time** | 30-45 min (planning) / 2-4 hours (execution) |
| **Key Topics** | Initial setup, GitHub config, CI/CD, team training |
| **Use When** | Setting up process for the first time |
**Phases:**
1. Initial setup (create baseline tags)
2. GitHub configuration (branch protection)
3. CI/CD integration
4. Release documentation
5. Team training
6. First real release walkthrough
---
### [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md)
**The Diagram Reference**
| Aspect | Details |
|--------|---------|
| **Purpose** | Visual flows and process diagrams |
| **Audience** | Everyone (visual learners) |
| **Length** | ~400 lines |
| **Read Time** | 15-20 min |
| **Key Topics** | Pipelines, dependencies, timelines, templates |
| **Use When** | Understanding processes, presentations |
**Diagrams:**
- Release pipeline overview
- Product dependency & order
- Git tag timeline
- Release branch structure
- Multi-product coordination
- Hotfix flow
- Version matrix dashboard
---
### [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md)
**The One-Page Reference**
| Aspect | Details |
|--------|---------|
| **Purpose** | Quick lookup while working |
| **Audience** | All team members |
| **Length** | ~200 lines |
| **Read Time** | 5 min (scan) |
| **Key Topics** | Commands, naming, checklist, steps |
| **Use When** | Quick lookup, print & pin to desk |
**Includes:**
- ⚡ Quick commands
- 🏷️ Tag naming format
- 📝 Pre-tag checklist
- 🚀 Quick release steps
- 📍 Version file locations
- 🔄 Release timeline table
- 📞 Common tasks
**💡 Print this one!**
---
### [VERSION_FILES_REFERENCE.md](./VERSION_FILES_REFERENCE.md)
**The File Locations Guide**
| Aspect | Details |
|--------|---------|
| **Purpose** | Exact file locations and how to update |
| **Audience** | Developers doing version bumps |
| **Length** | ~350 lines |
| **Read Time** | 5-10 min per product |
| **Key Topics** | File paths, format, examples per product |
| **Use When** | Updating version numbers |
**Per Product:**
- Staff Mobile App
- Client Mobile App
- Web Dashboard
- Command API Backend
- Core API Backend
- DataConnect Schema
- CHANGELOG.md
---
### [RELEASE_PACKAGE_SUMMARY.md](./RELEASE_PACKAGE_SUMMARY.md)
**This Package Overview**
| Aspect | Details |
|--------|---------|
| **Purpose** | Overview of all 6 documents |
| **Audience** | New team members, anyone |
| **Length** | ~400 lines |
| **Read Time** | 15 min |
| **Key Topics** | Package contents, usage paths, next steps |
| **Use When** | Understanding what documents exist |
**Includes:**
- Complete package description
- How to use each document
- Current baseline versions
- Immediate next steps
- Feature checklist
- Success metrics
---
## 🎯 Reading Paths by Role
### Developer (Contributing Code)
1. skim: [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md) (5 min)
2. keep: [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md) at desk
3. when needed: [VERSION_FILES_REFERENCE.md](./VERSION_FILES_REFERENCE.md)
### Release Engineer
1. read: [RELEASE_IMPLEMENTATION.md](./RELEASE_IMPLEMENTATION.md) (full)
2. master: [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) (full)
3. reference: [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md)
4. check: [VERSION_FILES_REFERENCE.md](./VERSION_FILES_REFERENCE.md)
### Technical Lead / Architect
1. read: [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md) (full)
2. review: [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md)
3. approve: [RELEASE_IMPLEMENTATION.md](./RELEASE_IMPLEMENTATION.md)
4. maintain: Update [RELEASE_PACKAGE_SUMMARY.md](./RELEASE_PACKAGE_SUMMARY.md)
### Product Manager / Business Lead
1. understand: [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md) → Release Cadence section
2. visualize: [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) → Status Page Template
3. track: Version matrix dashboard
4. share: Communicate timelines to users
### New Team Member
1. start: [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md) (overview)
2. watch: Team walkthrough of [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md)
3. practice: Follow [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) with mentor
4. reference: Keep [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md) handy
---
## 🔗 Quick Links
| Need | Go To |
|------|-------|
| Version numbers for all products | [VERSION_FILES_REFERENCE.md](./VERSION_FILES_REFERENCE.md) |
| How to release a single product | [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) → Quick Start |
| Git commands | [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md) → Quick Commands |
| Branch structure | [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) → Git Tag Timeline |
| Hotfix steps | [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) → Hotfix Release |
| Release checklist | [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md) → Checklist |
| Automation scripts | [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) → Automation Scripts |
| Dependency order | [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) → Dependency Diagram |
| GitHub setup | [RELEASE_IMPLEMENTATION.md](./RELEASE_IMPLEMENTATION.md) → Phase 2 |
| Team training | [RELEASE_IMPLEMENTATION.md](./RELEASE_IMPLEMENTATION.md) → Phase 5 |
| Status communication | [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) → Status Page Template |
---
## 📅 Implementation Timeline
```
Week 1 (2026-03-05)
├─ Read: RELEASE_STRATEGY.md
├─ Review: RELEASE_VISUAL_GUIDE.md
└─ Decide: Approve strategy with team
Week 2 (2026-03-08)
├─ Follow: RELEASE_IMPLEMENTATION.md Phase 1-2
├─ Create: Initial dev tags (v0.1.0)
└─ Configure: GitHub branch protection
Week 3 (2026-03-15)
├─ Plan: First staging release
├─ Use: RELEASE_WORKFLOW.md
├─ Reference: VERSION_FILES_REFERENCE.md
└─ Check: RELEASE_QUICK_REFERENCE.md
Week 4 (2026-03-22)
├─ Execute: First production release
├─ Monitor: 24 hours post-release
└─ Document: Learnings in process
Month 2+
└─ Repeat: Establish release rhythm
```
---
## ✅ Before You Start
Make sure you have:
- [ ] Read at least 2 documents from your reading path
- [ ] Understood tag naming convention
- [ ] Know location of version files for your product
- [ ] Have git/GitHub access
- [ ] Know deployment procedure for your environment
- [ ] Know your team's approval process
---
## 🎓 Learning Path by Goal
### "I want to perform a release in the next hour"
1. skim: [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md) (5 min)
2. reference: [VERSION_FILES_REFERENCE.md](./VERSION_FILES_REFERENCE.md) (2 min)
3. follow: [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) → your scenario (30 min)
**Time: 40 minutes**
### "I want to understand the full strategy"
1. read: [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md) (20 min)
2. visualize: [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) (10 min)
3. deep dive: [RELEASE_IMPLEMENTATION.md](./RELEASE_IMPLEMENTATION.md) (30 min)
4. reference: [VERSION_FILES_REFERENCE.md](./VERSION_FILES_REFERENCE.md) (10 min)
**Time: 70 minutes**
### "I want to teach others"
1. prep: [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md) (20 min)
2. visuals: [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) (10 min)
3. demo: [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) → Quick Start (30 min)
4. handout: [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md)
**Time: 60 minutes prep + 30 min teaching**
---
## 📞 Where to Find Things
| Question | Document |
|----------|----------|
| What's our versioning scheme? | RELEASE_STRATEGY.md |
| How do I name tags? | RELEASE_QUICK_REFERENCE.md |
| What files do I need to edit? | VERSION_FILES_REFERENCE.md |
| How do I release a product? | RELEASE_WORKFLOW.md |
| Where do I get started? | RELEASE_IMPLEMENTATION.md |
| Show me diagrams | RELEASE_VISUAL_GUIDE.md |
| Quick git commands | RELEASE_QUICK_REFERENCE.md |
| Deployment order? | RELEASE_VISUAL_GUIDE.md |
| Hotfix steps? | RELEASE_WORKFLOW.md |
| Team training? | RELEASE_IMPLEMENTATION.md |
---
## 🎯 Success Criteria
After reading appropriate docs, you should know:
- ✅ What semantic versioning means
- ✅ How to name a git tag
- ✅ Which files control versions for each product
- ✅ The three environment levels (dev/staging/prod)
- ✅ The product deployment order
- ✅ Where to find version files
- ✅ How to execute a release
- ✅ What to do if something goes wrong
- ✅ How to communicate a release
---
## 💡 Pro Tips
1. **Bookmark** this index page
2. **Print** [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md)
3. **Share** [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) in presentations
4. **Reference** [VERSION_FILES_REFERENCE.md](./VERSION_FILES_REFERENCE.md) every release
5. **Update** as your process evolves
---
## 📞 Questions?
1. **How?** → Look in [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md)
2. **What file?** → Look in [VERSION_FILES_REFERENCE.md](./VERSION_FILES_REFERENCE.md)
3. **Git command?** → Look in [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md)
4. **Strategy?** → Look in [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md)
5. **Diagram?** → Look in [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md)
6. **Can't find it?** → Ask in #releases on Slack
---
## 🚀 Ready?
Pick your path above and start reading. You've got this!
**Questions? Ask in #releases**
---
**Created**: 2026-03-05
**Last Updated**: 2026-03-05
**Version**: 1.0

507
RELEASE_PACKAGE_SUMMARY.md Normal file
View File

@@ -0,0 +1,507 @@
# Release Strategy - Complete Package Summary
**Created**: 2026-03-05
**Status**: Ready for Implementation
**Document Set**: Complete & Integrated
---
## 📚 What Was Created
A complete, production-ready release and tagging strategy for the KROW Workforce monorepo with 5 independent products.
### Documents Included
#### 1. **RELEASE_STRATEGY.md** 📖
**Purpose**: The canonical strategy document
**Contents**:
- Semantic versioning approach (SemVer)
- Git tag naming convention
- Release cadence (dev/staging/prod)
- Deployment dependency order
- Release checklist
- Protected tag rules
- Version file locations
- Rollback procedures
**Audience**: Technical leads, team members planning releases
**Length**: ~300 lines
**Use When**: Making strategic decisions about releases
---
#### 2. **RELEASE_WORKFLOW.md** 🔧
**Purpose**: Step-by-step execution guide
**Contents**:
- Quick start release (single product)
- Multi-product coordinated release
- Hotfix procedure
- Useful git commands
- Automation scripts to create
- Release checklist template
**Audience**: Developers and release engineers executing releases
**Length**: ~400 lines
**Use When**: Actually performing a release
---
#### 3. **RELEASE_IMPLEMENTATION.md** 🚀
**Purpose**: Setup and first-release guide
**Contents**:
- Phase 1: Initial setup (create baseline tags)
- Phase 2: GitHub configuration (branch protection)
- Phase 3: CI/CD integration
- Phase 4: Release documentation
- Phase 5: Team training
- Phase 6: First real release walkthrough
- Communication plan
- Troubleshooting
**Audience**: DevOps/Release engineering team
**Length**: ~500 lines
**Use When**: Setting up the release process for the first time
---
#### 4. **RELEASE_VISUAL_GUIDE.md** 📊
**Purpose**: ASCII diagrams and visual references
**Contents**:
- Release pipeline overview (flowchart)
- Product dependency diagram
- Git tag timeline example
- Release branch structure diagram
- Multi-product release coordination
- Hotfix flow diagram
- Version matrix dashboard template
- Release timeline template
- Status page template
**Audience**: Everyone (visual learners, quick reference)
**Length**: ~400 lines
**Use When**: Understanding the flow, presentations, team communication
---
#### 5. **RELEASE_QUICK_REFERENCE.md** 🎯
**Purpose**: One-page quick reference (print-friendly)
**Contents**:
- Quick commands
- Tag naming format
- Pre-tag checklist
- Quick release steps
- Version file locations
- Release timeline table
- Common tasks with code examples
- Deployment order
- Red flags to avoid
- Troubleshooting
**Audience**: All team members
**Length**: ~200 lines
**Use When**: Quick lookup while working
**💡 Tip**: Print this and pin to your desk!
---
#### 6. **VERSION_FILES_REFERENCE.md** 📝
**Purpose**: Exact file locations and update instructions
**Contents**:
- Staff Mobile pubspec.yaml location
- Client Mobile pubspec.yaml location
- Web Dashboard package.json location
- Command API package.json location
- Core API package.json location
- DataConnect schema version (if applicable)
- CHANGELOG.md (all products)
- Release checklist per product
- Version update template script
- Common mistakes
- Pro tips
**Audience**: Developers doing version bumps
**Length**: ~350 lines
**Use When**: Updating version numbers for a release
---
## 🎯 How to Use This Package
### For Your First Release
1. **Read** [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md) (strategic overview)
2. **Follow** [RELEASE_IMPLEMENTATION.md](./RELEASE_IMPLEMENTATION.md) (Phase 1-6 setup)
3. **Reference** [VERSION_FILES_REFERENCE.md](./VERSION_FILES_REFERENCE.md) (exact files to update)
4. **Execute** [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) (step-by-step)
5. **Check** [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) (understand the flow)
6. **Keep** [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md) handy
### For Ongoing Releases
**Quick path:**
1. [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md) - Commands & checklist
2. [VERSION_FILES_REFERENCE.md](./VERSION_FILES_REFERENCE.md) - Which files to update
3. [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) - Copy the relevant section
4. [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) - Verify deployment order
### For Team Training
1. **Share** [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md) with team
2. **Show** [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) diagrams
3. **Walk through** [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) quick start
4. **Provide** [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md) as handout
5. **Reference** [VERSION_FILES_REFERENCE.md](./VERSION_FILES_REFERENCE.md) when needed
### For CI/CD Setup
1. Review automation sections in [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md)
2. Set up GitHub branch protection per [RELEASE_IMPLEMENTATION.md](./RELEASE_IMPLEMENTATION.md)
3. Configure CodeMagic per [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md)
---
## 🏷️ Quick Reference: Tag Naming
```
Format: <product>/<environment>-v<version>
Staff Mobile Example: staff-mobile/prod-v1.0.0
Client Mobile Example: client-mobile/prod-v1.0.0
Web Dashboard Example: web-dashboard/staging-v0.1.0
Command API Example: command-api/dev-v0.2.0
Core API Example: core-api/prod-v0.1.0
Environments:
dev → Development releases (daily/weekly)
staging → Pre-production releases (bi-weekly)
prod → Production releases (monthly)
```
---
## 📊 Current Baseline Versions
Based on your repository state (2026-03-05):
| Product | Current Version | Status |
|---------|-----------------|--------|
| Staff Mobile | 0.1.0 | Development |
| Client Mobile | 0.1.0 | Development |
| Web Dashboard | 0.0.0 | Pre-release |
| Command API | 0.1.0 | Development |
| Core API | 0.1.0 | Development |
**Next Releases**:
- Q1 2026: v0.2.0 (staging)
- Q2 2026: v1.0.0 (production)
---
## 🚀 Immediate Next Steps
### This Week (2026-03-05)
- [ ] Read [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md)
- [ ] Review with team
- [ ] Get approval to proceed
### Next Week (2026-03-08)
- [ ] Follow [RELEASE_IMPLEMENTATION.md](./RELEASE_IMPLEMENTATION.md) Phase 1-2
- [ ] Create initial dev tags (baseline v0.1.0)
- [ ] Configure GitHub branch protection for prod tags
- [ ] Train team on new process
### Week of Release (2026-03-15)
- [ ] Plan first staging release (Staff Mobile v0.2.0)
- [ ] Update version all files per [VERSION_FILES_REFERENCE.md](./VERSION_FILES_REFERENCE.md)
- [ ] Execute release using [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md)
- [ ] Deploy to staging and test
### Within 30 Days
- [ ] First production release (any product)
- [ ] Establish release cadence
- [ ] Document any customizations
- [ ] Refine process based on learnings
---
## ✅ Feature Checklist
This release strategy includes:
- ✅ **Semantic Versioning (SemVer)** - Industry standard
- ✅ **Product-specific Tags** - Independent version tracking
- ✅ **Environment Separation** - dev/staging/prod releases
- ✅ **Dependency Management** - Clear deployment order
- ✅ **Rollback Procedures** - Handling production issues
- ✅ **Hotfix Process** - Emergency fixes
- ✅ **Branch Protection** - GitHub security rules
- ✅ **Documentation** - Comprehensive guides
- ✅ **Templates** - Checklists and scripts
- ✅ **Visual Diagrams** - Process flows
- ✅ **Quick Reference** - Print-friendly guide
- ✅ **Version File Map** - Exact file locations
- ✅ **Communication Plan** - Stakeholder updates
- ✅ **Team Training** - Learning materials
- ✅ **Automation Scripts** - CI/CD integration
---
## 📋 File Structure
```
Repository Root
├── RELEASE_STRATEGY.md ← Strategic overview
├── RELEASE_WORKFLOW.md ← Step-by-step execution
├── RELEASE_IMPLEMENTATION.md ← Setup guide
├── RELEASE_VISUAL_GUIDE.md ← Diagrams & flows
├── RELEASE_QUICK_REFERENCE.md ← One-page reference
├── VERSION_FILES_REFERENCE.md ← File locations
│
├── CHANGELOG.md ← Version history (existing)
├── codemagic.yaml ← CI/CD config (existing)
│
└── apps/
├── mobile/
│ ├── apps/
│ │ ├── staff_app/pubspec.yaml ← Staff Mobile version
│ │ └── client_app/pubspec.yaml ← Client Mobile version
│ └── ...
│
└── web/
└── package.json ← Web Dashboard version
backend/
├── command-api/package.json ← Command API version
└── core-api/package.json ← Core API version
```
---
## 🔐 Security & Best Practices
### Branch Protection
- Production tags (`prod-v*`) require pull request review
- Require status checks to pass
- Require branches up-to-date
- Prevent force pushes
### Rollback Safety
- Always keep previous version available
- Test rollback procedure regularly
- Document rollback steps
- Communicate with users
### Change Tracking
- CHANGELOG.md for all product updates
- Git history for code changes
- Tags for release checkpoints
- GitHub Releases for user communication
---
## 💡 Tips for Success
### 1. Start Small
Begin with a single product release (e.g., Staff Mobile v0.2.0) to practice the process.
### 2. Establish Rhythm
Consistent release cadence makes it easier for everyone:
- Dev: Weekly
- Staging: Bi-weekly
- Prod: Monthly
### 3. Automate Wisely
Start manual to understand the process, then automate repetitive tasks.
### 4. Communicate Early
Announce release plans before deployment, not after.
### 5. Monitor Actively
24-hour post-release monitoring catches issues early.
### 6. Document Learnings
Update these guides based on real experience with your releases.
---
## 🐛 Troubleshooting
### I'm confused about which file to edit
→ See [VERSION_FILES_REFERENCE.md](./VERSION_FILES_REFERENCE.md)
### I need step-by-step release instructions
→ See [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md)
### I need git commands
→ See [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md)
### I need to understand the overall strategy
→ See [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md)
### I need to set up the process for the first time
→ See [RELEASE_IMPLEMENTATION.md](./RELEASE_IMPLEMENTATION.md)
### I need visual diagrams
→ See [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md)
---
## 📞 Additional Resources
### Related Documentation
- [CHANGELOG.md](./CHANGELOG.md) - Current version history
- [codemagic.yaml](./codemagic.yaml) - CI/CD configuration
- [docs/ARCHITECTURE/system-bible.md](./docs/ARCHITECTURE/system-bible.md) - System design
- [README.md](./README.md) - Project overview
### External References
- [Semantic Versioning 2.0.0](https://semver.org)
- [Git Tagging](https://git-scm.com/docs/git-tag)
- [GitHub Releases](https://docs.github.com/en/repositories/releasing-projects-on-github)
- [Git Workflow Best Practices](https://git-scm.com/book/en/v2)
---
## 👥 Team Roles
### Release Manager
- Plans release schedule
- Creates tags
- Coordinates deployment
- Monitors post-release
### Developers
- Ensure code is release-ready
- Update version files per checklist
- Update CHANGELOG
- Test releases
### DevOps/Infrastructure
- Configure branch protection
- Set up CI/CD automations
- Deploy to environments
- Monitor infrastructure
### Product Owner
- Approves staging releases
- Signs off before production
- Communicates with users
- Handles rollback decisions
### QA Team
- Tests staged releases
- Verifies production deployments
- Reports issues
- Validates rollbacks
---
## 📊 Success Metrics
Track these metrics for each release:
- **Lead Time**: Time from commit to production
- **Deployment Frequency**: How often you release
- **Change Failure Rate**: % of releases needing rollback
- **Mean Time to Recovery**: Time to fix issues
- **Automation Coverage**: % of tasks automated
- **User Adoption**: % of users on latest version
- **Issue Detection**: Time from deployment to issue detection
---
## 🎓 Knowledge Sharing
### For New Team Members
1. Have them read [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md)
2. Run through [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) together
3. Have them perform a dev release under supervision
4. Give them [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md) as reference
### For Leadership
Share [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) status page template to track releases across products.
### For Stakeholders
Use templates provided to communicate:
- Release announcements
- Feature summaries
- Deployment windows
- Known issues
---
## 📅 Release Calendar Template
```
March 2026
┌─────────────────────────────────────┐
│ 01 (Sun) Code Freeze │
│ 05 (Thu) Staging Release (0.2.0) │
│ 08 (Sun) QA Complete │
│ 15 (Sun) Production Release │
│ 22 (Sun) Monitoring & Stability │
│ 29 (Sun) Next Cycle Begins │
└─────────────────────────────────────┘
Every Monday: Release Sync Meeting
Every Friday: Status Update
Rolling: Release documentation updates
```
---
## ✨ Next Phase
Once this strategy is implemented and proven with 2-3 releases:
1. **Automation**: GitHub Actions to auto-tag on version change
2. **Metrics**: Dashboard tracking deployment metrics
3. **Communication**: Slack/email bot announcing releases
4. **Deployment**: Fully automated deployments per product
5. **Analytics**: Track adoption and issue post-release
---
## 📝 Document Maintenance
**When to update these guides:**
- After every major release (capture learnings)
- When process changes
- When team feedback warrants updates
- When new tools are integrated
- When scaling to new products
**Who maintains:**
- DevOps/Release engineering team
- Approved by: Technical leads, Product management
**Review Cycle:**
- Quarterly review of all documents
- Monthly: CHANGELOG.md updates
- As-needed: Bug fixes, clarifications
---
## 🎉 You're Ready!
This complete release strategy is ready to implement. Start with [RELEASE_IMPLEMENTATION.md](./RELEASE_IMPLEMENTATION.md) and follow the phases.
**Questions?**
- Review the relevant guide above
- Consult [RELEASE_QUICK_REFERENCE.md](./RELEASE_QUICK_REFERENCE.md)
- Ask your DevOps team
**Let's ship v1.0.0! 🚀**
---
**Package Version**: 1.0
**Created**: 2026-03-05
**Last Updated**: 2026-03-05
**Status**: Ready for Production
**Maintainer**: DevOps/Release Engineering Team

267
RELEASE_QUICK_REFERENCE.md Normal file
View File

@@ -0,0 +1,267 @@
# Release Quick Reference Card
**Print this and pin it to your desk! 📌**
---
## ⚡ Quick Commands
### View All Tags
```bash
git tag -l "*" --sort=-version:refname
```
### View Tags for One Product
```bash
git tag -l "staff-mobile/*" --sort=-version:refname
```
### Create a Tag
```bash
git tag -a staff-mobile/dev-v0.2.0 -m "Staff Mobile v0.2.0"
git push origin staff-mobile/dev-v0.2.0
```
### See What's in a Tag
```bash
git show staff-mobile/prod-v0.1.0
git log staff-mobile/prod-v0.1.0 -5 --oneline
```
### Delete a Tag
```bash
git tag -d staff-mobile/dev-v0.1.0 # Local
git push origin --delete staff-mobile/dev-v0.1.0 # Remote
```
---
## 🏷️ Tag Naming Format
```
<product>/<environment>-v<major>.<minor>.<patch>
Examples:
staff-mobile/dev-v0.2.0
client-mobile/staging-v0.2.0
web-dashboard/prod-v1.0.0
command-api/prod-v0.1.1
```
**Products:**
- `staff-mobile` / `client-mobile`
- `web-dashboard`
- `command-api` / `core-api`
- `dataconnect`
**Environments:**
- `dev` (development, unstable)
- `staging` (pre-production, testing)
- `prod` (production, stable)
---
## 📝 Checklist: Before You Tag
- [ ] Code review completed
- [ ] All tests passing locally
- [ ] CHANGELOG.md updated
- [ ] Version numbers updated in:
- [ ] `apps/mobile/apps/*/pubspec.yaml` (if mobile)
- [ ] `apps/web/package.json` (if web)
- [ ] `backend/*/package.json` (if backend)
- [ ] `codemagic.yaml` (if mobile)
- [ ] Committed and pushed changes
- [ ] Ready to merge release branch
---
## 🚀 Create a Release (Quick Steps)
```
1. Update version numbers
(See "Version File Locations" below)
2. Update CHANGELOG.md
Add line at top with date and version
3. Commit & push
git commit -m "chore: bump to v0.2.0"
git push origin release/branch-name
4. Create tag
git tag -a product/env-v0.2.0 -m "Description"
git push origin product/env-v0.2.0
5. Create GitHub Release
Go to Releases → Draft new release
Select tag → Fill in details → Publish
6. Deploy
(Follow your deployment script)
7. Monitor
Check logs for 24 hours
```
---
## 📍 Version File Locations
**Quick edit list for version bumps:**
### Mobile (Staff & Client)
- [ ] `apps/mobile/apps/staff_app/pubspec.yaml`
- [ ] `apps/mobile/apps/client_app/pubspec.yaml`
Format: `version: X.Y.Z+N` (N = build number)
### Web
- [ ] `apps/web/package.json`
Format: `"version": "X.Y.Z"`
### Backend
- [ ] `backend/command-api/package.json`
- [ ] `backend/core-api/package.json`
Format: `"version": "X.Y.Z"`
### CI/CD
- [ ] `codemagic.yaml`
Format: `build_version: "X.Y.Z"`
**Also update CHANGELOG.md!**
---
## 🔄 Release Timeline At-a-Glance
| Stage | Duration | Environment | Status | Next Step |
|-------|----------|-------------|--------|-----------|
| **Feature Dev** | 1-2 weeks | Local | 👨‍💻 In progress | Code review |
| **Code Review** | 1-3 days | GitHub | 👀 Reviewing | Merge to main |
| **Dev Release** | Same day | Dev env | ✅ Deployed | Weekly |
| **Staging Release** | 1 week | Staging | 🧪 Testing | QA sign-off |
| **Prod Release** | 2-3 hours | Production | 🚀 Deploying | 24h monitoring |
---
## 📞 Common Tasks
### I want to release Staff Mobile v0.2.0
```bash
git checkout -b release/staff-mobile-v0.2.0
# Edit: apps/mobile/apps/staff_app/pubspec.yaml (0.1.0 → 0.2.0)
# Edit: CHANGELOG.md (add entry)
git add .
git commit -m "chore: staff mobile v0.2.0"
git push origin release/staff-mobile-v0.2.0
# Create PR, get approved, merge
git tag -a staff-mobile/dev-v0.2.0 -m "Staff Mobile v0.2.0"
git push origin staff-mobile/dev-v0.2.0
```
### I found a critical bug in production
```bash
git checkout -b hotfix/staff-mobile-v0.1.1 staff-mobile/prod-v0.1.0
# Fix the bug
# Bump version 0.1.0 → 0.1.1 in pubspec.yaml
git commit -m "fix: [critical issue]"
git tag -a staff-mobile/prod-v0.1.1 -m "Hotfix: [issue]"
git push origin staff-mobile/prod-v0.1.1
# Deploy immediately, monitor 24h
```
### I want to see all production versions
```bash
git tag -l "*/prod-v*" --sort=-version:refname
```
### I want to compare two versions
```bash
git log staff-mobile/prod-v0.1.0...staff-mobile/prod-v0.2.0 --oneline
```
---
## 🎯 Deployment Order (Multi-Product Release)
Always deploy in this order:
1. **DataConnect** (if schema changed)
2. **Command API** + **Core API** (can be parallel)
3. **Web Dashboard**
4. **Staff Mobile** + **Client Mobile** (can be parallel)
Verify each step completes before moving to next.
---
## ⚠️ Red Flags 🚫
**DON'T tag if:**
- ❌ Tests are failing
- ❌ Code review not approved
- ❌ CHANGELOG not updated
- ❌ Version numbers not bumped
- ❌ Breaking changes not documented
- ❌ Staging not tested yet
- ❌ Team not notified
**DO tag if:**
- ✅ All tests passing
- ✅ Code reviewed + approved
- ✅ CHANGELOG updated
- ✅ Version numbers consistent
- ✅ Staged and tested
- ✅ Team aware
---
## 🆘 Troubleshoot
**Tag won't push:**
```bash
# Make sure you have push permissions
git config --list | grep remote.origin.url
# Re-authenticate if needed
git credential-osxkeychain erase host=github.com
```
**Wrong tag created:**
```bash
git tag -d wrong-tag
git push origin --delete wrong-tag
git tag -a correct-tag -m "message"
git push origin correct-tag
```
**Need to see what changed:**
```bash
git log v0.1.0..v0.2.0 --oneline
git diff v0.1.0..v0.2.0 -- apps/mobile/
```
---
## 📚 Full Documentation
For complete details, see:
- 📖 [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md) - Full strategy
- 🔧 [RELEASE_WORKFLOW.md](./RELEASE_WORKFLOW.md) - Step-by-step
- 🚀 [RELEASE_IMPLEMENTATION.md](./RELEASE_IMPLEMENTATION.md) - Setup guide
- 📊 [RELEASE_VISUAL_GUIDE.md](./RELEASE_VISUAL_GUIDE.md) - Diagrams
---
## 📞 Contact
**Release Questions?** Slack: #releases
**Need Help?** Check RELEASE_WORKFLOW.md or ask DevOps team
---
**Last Updated**: 2026-03-05
**Bookmark this page! 🔖**

425
RELEASE_STRATEGY.md Normal file
View File

@@ -0,0 +1,425 @@
# KROW Workforce Release Strategy & Tagging Plan
## 📋 Overview
This document establishes a systematic approach to versioning, tagging, and releasing across the KROW Workforce monorepo, which contains 5 distinct products with interdependencies.
**Products:**
1. **Staff Mobile App** - Flutter (iOS/Android)
2. **Client Mobile App** - Flutter (iOS/Android)
3. **Web Dashboard** - React/Vite
4. **Backend Services** - Node.js (Command API, Core API)
5. **Database/DataConnect** - Firebase Data Connect with PostgreSQL
---
## 🔗 Versioning Strategy
### Semantic Versioning (SemVer)
All products follow **Semantic Versioning 2.0.0**:
- **MAJOR.MINOR.PATCH** (e.g., `1.2.3`)
- **MAJOR**: Breaking changes, major features
- **MINOR**: Backward-compatible new features
- **PATCH**: Bug fixes, minor improvements
### Version Independence
Each product maintains its own version:
- Products can release independently
- No requirement for synchronized versions across products
- Allows flexibility in release schedules
### Current Baseline (as of 2026-03-05)
| Product | Current Version | Status |
|---------|-----------------|--------|
| Staff Mobile App | 0.1.0 | Development |
| Client Mobile App | 0.1.0 | Development |
| Web Dashboard | 0.0.0 | Pre-release |
| Backend (Command API) | 0.1.0 | Development |
| Backend (Core API) | 0.1.0 | Development |
| DataConnect | N/A | Schema-driven |
---
## 🏷️ Git Tag Naming Convention
### Format
```
<product>/<environment>-v<version>
```
### Products
- `staff-mobile` - Staff mobile application
- `client-mobile` - Client mobile application
- `web-dashboard` - Web dashboard
- `command-api` - Backend command API
- `core-api` - Backend core API
- `dataconnect` - Database/DataConnect schema
### Environments
- `dev` - Development release (unstable, for testing)
- `staging` - Staging release (pre-production)
- `prod` - Production release (stable, customer-facing)
### Examples
```
staff-mobile/dev-v0.1.0
client-mobile/staging-v0.1.0
web-dashboard/prod-v1.0.0
command-api/dev-v0.2.1
dataconnect/prod-v0.3.0
```
### Release Candidate Suffix (Optional)
For pre-release versions:
```
staff-mobile/staging-v0.1.0-rc.1
web-dashboard/prod-v1.0.0-rc.2
```
---
## 📅 Release Cadence
### Development Releases (`dev`)
- **Frequency**: Weekly or as-needed
- **Trigger**: Completed feature branches, bug fixes
- **Duration**: Not stable, for internal testing
- **Deployment**: Dev environment only
### Staging Releases (`staging`)
- **Frequency**: Bi-weekly
- **Trigger**: Completion of sprint/feature milestone
- **Duration**: Should maintain stability for 1-2 weeks
- **Deployment**: Staging environment for QA
### Production Releases (`prod`)
- **Frequency**: Monthly or sprint-based (typically end of month)
- **Trigger**: Successful staging validation + product sign-off
- **Duration**: Maintain for 2+ months
- **Deployment**: Production environment for customers
---
## 🔄 Release Dependency Order
### Critical Path (Recommended)
**For synchronized releases:**
1. **DataConnect Schema** (if schema changes) - Deploy first
2. **Backend Services** (Command API → Core API)
3. **Web Dashboard**
4. **Mobile Apps** (Staff first, then Client)
**Rationale:**
- DataConnect schema changes must be deployed before APIs consume new fields
- Backend APIs must be stable before frontend depends on new endpoints
- Web can be deployed independently but should test against new backend
- Mobile apps can be released independently but won't have full features until matching backend is live
### Independent Releases
Products can release independently if they don't introduce breaking changes:
- Mobile apps can release without backend changes
- Web dashboard can release bug fixes independently
- Backend can release non-breaking API changes independently
---
## 📦 Release Checklist
### Pre-Release (48 hours before)
- [ ] Code review complete on all changes
- [ ] All tests passing (unit, integration, E2E)
- [ ] Mobile app builds succeed on CodeMagic
- [ ] No lint/type errors
- [ ] Performance benchmarks acceptable
- [ ] Security scan completed
- [ ] Documentation updated
- [ ] CHANGELOG.md updated with changes
### Release Day
- [ ] Create release branch from main: `release/v<version>`
- [ ] Update version numbers in all relevant files:
- Mobile: `pubspec.yaml` version + build number
- Web: `package.json` version
- Backend: `package.json` version
- Backend: Update `codemagic.yaml` version refs
- [ ] Create git tag with appropriate name
- [ ] Merge release branch back to main
- [ ] Deploy to target environment
- [ ] Smoke tests run successfully
- [ ] Create GitHub Release with:
- Release notes from CHANGELOG
- Build artifacts (APK/AAB for mobile)
- Deployment checklist items
- Known issues
### Post-Release
- [ ] Verify in target environment (staging → prod)
- [ ] Monitor error logs for 24 hours
- [ ] Notify users of deployment
- [ ] Update status page if applicable
- [ ] Tag next development version as beginning
---
## 🔐 Protected Tags
### Rules
- **Production tags (`prod-v*`)**: Require pull request review
- **Staging tags (`staging-v*`)**: Require at least 1 approval
- **Dev tags (`dev-v*`)**: No restrictions
### Implementation in GitHub
1. Go to Repo Settings → Branches → Add rule
2. Apply to tag name pattern: `**/prod-v*`
3. Require pull request reviews before merging
4. Require status checks to pass
---
## 📝 Version File Locations
### Mobile Apps (Staff & Client)
**File**: `/apps/mobile/apps/staff_app/pubspec.yaml` (and client_app)
```yaml
version: 0.1.0+1
```
- First number = version
- After `+` = build number (increment for each release)
### Web Dashboard
**File**: `/apps/web/package.json`
```json
{
"version": "0.0.0"
}
```
### Backend Services
**Files**:
- `/backend/command-api/package.json`
- `/backend/core-api/package.json`
```json
{
"version": "0.1.0"
}
```
### CodeMagic Configuration
**File**: `/codemagic.yaml`
```yaml
workflows:
mobile-client-build:
environment:
flutter: stable
settings:
build_version: "0.1.0" # Update this
```
---
## 📊 Release Timeline Example: v1.0.0
**Timeline for coordinated production release:**
```
Day 1 (Monday)
├─ Code freeze announced
├─ All feature branches merged to main
└─ QA begins testing
Day 6 (Saturday)
├─ All tests pass
├─ Release manager creates release/v1.0.0 branch
└─ Version numbers bumped to 1.0.0 everywhere
Day 7 (Sunday)
├─ Tags created:
│ ├─ web-dashboard/staging-v1.0.0
│ ├─ command-api/staging-v1.0.0
│ ├─ core-api/staging-v1.0.0
│ ├─ staff-mobile/staging-v1.0.0
│ ├─ client-mobile/staging-v1.0.0
│ └─ dataconnect/staging-v1.0.0 (if schema changes)
├─ Deploy to staging environment
├─ QA smoke tests
└─ Product owner sign-off
Day 13 (Saturday) - Production Release
├─ Create production tags:
│ ├─ web-dashboard/prod-v1.0.0
│ ├─ command-api/prod-v1.0.0
│ └─ [other products]
├─ Deploy to production (following dependency order)
├─ Verify in production
└─ Release GitHub Release page
```
---
## 🛠️ Git Commands
### Create a Tag
```bash
# Create annotated tag
git tag -a staff-mobile/dev-v0.1.0 -m "Staff mobile v0.1.0 - [feature description]"
# Push tag to remote
git push origin staff-mobile/dev-v0.1.0
# Or push all tags
git push origin --tags
```
### List Tags for a Product
```bash
# Show all staff-mobile tags
git tag -l "staff-mobile/*" --sort=-version:refname
# Show tags in specific environment
git tag -l "*/prod-v*"
```
### Delete a Tag
```bash
# Local deletion
git tag -d staff-mobile/dev-v0.1.0
# Remote deletion
git push origin --delete staff-mobile/dev-v0.1.0
```
---
## 🔍 Rollback Procedures
### If Critical Issue Found in Prod
1. **Identify**: Determine which product caused the issue
2. **Revert**:
```bash
git revert <commit-hash> -m 1
git push origin main
```
3. **Tag**: Create hotfix tag
```bash
git tag -a staff-mobile/prod-v0.1.1 -m "Hotfix: [issue description]"
git push origin staff-mobile/prod-v0.1.1
```
4. **Deploy**: Follow deployment checklist
5. **Communication**: Notify users and stakeholders
### If Staging Issue Found
Similar to rollback but to staging environment. No customer impact.
---
## 📋 Release Notes Template
Create a GitHub Release with the following:
```markdown
# Staff Mobile v0.1.0 Release
**Release Date**: 2026-03-15
## What's New
### Features
- [ ] Feature 1 description
- [ ] Feature 2 description
### Improvements
- [ ] Improvement 1 description
### Bug Fixes
- [ ] Bug fix 1 description
## Dependencies
- ✅ Requires Backend API v0.1.0 or higher
- ✅ Requires DataConnect schema v0.3.0 or higher
## Installation
[iOS/Android download links]
## Known Issues
- [ ] Issue 1: Description (Workaround: ...)
## Migration Guide (if needed)
Steps for users to migrate from previous version.
## Support
For issues, contact support@krow-workforce.com or [GitHub Issues Link]
```
---
## 📊 Monitoring & Metrics
### Track Per Release
- [ ] Time to release
- [ ] Number of bugs in production
- [ ] User adoption rate
- [ ] Performance changes
- [ ] Rollback rate
- [ ] Deploy success rate
### Dashboard
Consider setting up a tool to track:
- Deploy frequency
- Lead time for changes
- Mean time to recovery (MTTR)
- Change failure rate
---
## 🔗 Related Documents
- [CHANGELOG.md](./CHANGELOG.md) - Historical version logs
- [docs/01-backend-api-specification.md](./docs/01-backend-api-specification.md) - API contract
- [docs/ARCHITECTURE/system-bible.md](./docs/ARCHITECTURE/system-bible.md) - System design
- [codemagic.yaml](./codemagic.yaml) - CI/CD pipeline
---
## ✅ Next Steps
1. **Approve this strategy** with the team
2. **Configure GitHub branch protection** for tag patterns
3. **Set up release automation** in CI/CD (GitHub Actions or CodeMagic)
4. **Create the v1.0.0 milestone** with all planned features
5. **Establish communication cadence** for releases (weekly status, release announcements)
6. **Train team members** on release process
---
**Last Updated**: 2026-03-05
**Owner**: DevOps/Release Engineering
**Status**: ✅ Active

382
RELEASE_VISUAL_GUIDE.md Normal file
View File

@@ -0,0 +1,382 @@
# Release Process Visual Guide
## 🔄 Release Pipeline Overview
```
┌─────────────────────────────────────────────────────────────────┐
│ KROW WORKFORCE RELEASE PIPELINE │
└─────────────────────────────────────────────────────────────────┘
┌─ DEVELOPMENT PHASE ────────────────────────────────────────────┐
│ │
│ Feature Branch Development │
│ ↓ │
│ Code Review & Testing │
│ ↓ │
│ Merge to Main │
│ ↓ │
│ Automated Builds & Tests (GitHub Actions / CodeMagic) │
│ ↓ │
│ ✅ Main is always deployment-ready │
│ │
└──────────────────────────────────────────────────────────────────┘
↓
┌─ STAGING RELEASE ──────────────────────────────────────────────┐
│ │
│ 1. Create Release Branch (release/[product]-v[version]) │
│ 2. Bump Version Numbers │
│ 3. Update CHANGELOG │
│ 4. Create Git Tags: */staging-v[version] │
│ 5. Deploy to Staging Environment │
│ 6. Run QA Tests │
│ 7. Product Owner Sign-off │
│ │
│ Duration: 1 week minimum │
│ Cadence: Bi-weekly │
│ │
└──────────────────────────────────────────────────────────────────┘
↓
┌─ ISSUE? ──────────────────┐
│ ↓
│ Create Hotfix
│ Branch/Tag
│ (*/staging-v[X+1])
└─ FIX & RETEST ────────────┘
↓
┌─ PRODUCTION RELEASE ───────────────────────────────────────────┐
│ │
│ 1. Final Verification in Staging │
│ 2. Create Production Tags: */prod-v[version] │
│ 3. Deploy in Dependency Order: │
│ • DataConnect Schema (if applicable) │
│ • Command API │
│ • Core API │
│ • Web Dashboard │
│ • Staff Mobile │
│ • Client Mobile │
│ 4. Smoke Tests in Production │
│ 5. Create GitHub Release Page │
│ 6. Announce to Users │
│ 7. Monitor for 24 hours │
│ │
│ Duration: 1-2 hours deployment, 24-48 hours monitoring │
│ Cadence: Monthly or sprint-based │
│ │
└──────────────────────────────────────────────────────────────────┘
Legend:
✅ = Ready state
→ = Next step
↓ = Dependency
```
---
## 📦 Product Dependency & Release Order
```
┌──────────────────────┐
│ DataConnect Schema │
│ (if applicable) │
└──────────┬───────────┘
│
┌──────────▼──────────┐
│ Backend Services │
│ │
├─ Command API │
└─ Core API │
│
┌──────────────┼──────────────┐
│ │ │
┌──────▼────┐ ┌──────▼────┐ ┌────▼──────┐
│ Web │ │ Staff │ │ Client │
│ Dashboard │ │ Mobile │ │ Mobile │
│ │ │ App │ │ App │
└───────────┘ └───────────┘ └───────────┘
Critical Path (Staging → Production):
1. DataConnect (if schema changes)
2. APIs (Command + Core) [parallel OK]
3. Web Dashboard [can wait for API confirmation]
4. Mobile Apps [independent, can deploy anytime]
Parallel Deployments (when safe):
• Both backend APIs can deploy in parallel
• Mobile apps can deploy in parallel
• Web + Mobile can deploy in parallel (if APIs stable)
Non-Blocking:
• Mobile can release without web changes
• Web can release without mobile changes
• Backend can release non-breaking API changes independently
```
---
## 🏷️ Git Tag Timeline Example
```
Release v1.0.0 Timeline (Coordinated)
2026-03-01 2026-03-08 2026-03-15 2026-03-22
│ │ │ │
├─ Code Freeze ├─ Staging Release ├─ Production ├─ Next Sprint
│ │ │ Release │
├─ Feature Branches ├─ */staging-v1.0.0 ├─ */prod-v1.0.0 │
│ → main │ │ │
│ ├─ QA Testing ├─ Deploy & Verify │
├─ All Tests # ├─ 24h Monitoring ├─ 48h Monitoring │
│ Green # │ │ │
│ ├─ Product Sign-off ✓ ├─ Users Notified │
└─ Ready ✓ └─ Approved for Prod └─ Stable ✓ │
Key Milestones:
# = All automated tests passing
✓ = Manual approval/sign-off
```
---
## 🔄 Release Branch Structure
```
┌─────────────────── main (Protected) ──────────────────┐
│ │
│ feature/auth feature/payments │
│ ↓ ↓ │
│ ──●──●──●── ──●──●──●── ──●──●──●── ← Feature │
│ │ │ │ Branches │
│ ├──────┬─────┤ ┬──────┤ │
│ ↓ │ ↓ │ ↓ │
│ ────●──────●─────●─────●──────●───── ← Merge PRs │
│ │ │
│ ↓ │
│ release/staff-mobile-v0.2.0 ← Release Branch │
│ │ │
│ ├─ Bump version │
│ ├─ Update CHANGELOG │
│ ├─ Commit & merge back │
│ │ │
│ ────●●────────────────── ← Merge back to main │
│ │ │
│ ↓ │
│ TAG: staff-mobile/staging-v0.2.0 ← Staging Tag │
│ TAG: staff-mobile/prod-v0.2.0 ← Prod Tag │
│ │ │
│ (Deploy from tags) │
│ │
└────────────────────────────────────────────────────────┘
Key Points:
• main is always clean and deployable
• Feature branches never go to staging/prod
• Tags point to main (after merge)
• Releases == Git tags, not branches
• Hotfix branches created from prod tags
```
---
## 📋 Multi-Product Release Coordination
```
Product Release States (Example: v1.0.0)
Staff Mobile:
├─ Dev build: ✅ staff-mobile/dev-v1.0.0 (deployed)
├─ Staging: ✅ staff-mobile/staging-v1.0.0 (testing)
└─ Production: 🔄 staff-mobile/prod-v1.0.0 (deploying)
Client Mobile:
├─ Dev build: ✅ client-mobile/dev-v1.0.0 (deployed)
├─ Staging: ✅ client-mobile/staging-v1.0.0 (testing)
└─ Production: 🔄 client-mobile/prod-v1.0.0 (deploying)
Web Dashboard:
├─ Dev build: ✅ web-dashboard/dev-v1.0.0 (deployed)
├─ Staging: ✅ web-dashboard/staging-v1.0.0 (testing)
└─ Production: ✅ web-dashboard/prod-v1.0.0 (live)
Command API:
├─ Dev build: ✅ command-api/dev-v1.0.0 (deployed)
├─ Staging: ✅ command-api/staging-v1.0.0 (testing)
└─ Production: ✅ command-api/prod-v1.0.0 (live)
Core API:
├─ Dev build: ✅ core-api/dev-v1.0.0 (deployed)
├─ Staging: ✅ core-api/staging-v1.0.0 (testing)
└─ Production: ✅ core-api/prod-v1.0.0 (live)
Legend:
✅ = Released and stable
🔄 = In progress
⏳ = Waiting for approval
⛔ = Blocked/awaiting fix
Sync Points (when to coordinate):
1. Before moving staging → prod (all ready?)
2. During prod deployment (follow order)
3. Post-release (all working?)
4. If hotfix needed (which products affected?)
```
---
## 🚨 Hotfix Release Flow
```
Production Issue Detected
│
↓
┌─────────────────┐
│ Is it critical? │
└────┬────────┬───┘
│ YES │ NO
↓ └─→ Plan for next release
┌─────────────────────────┐
│ Create Hotfix Branch │
│ (from prod tag) │
└──────────┬──────────────┘
│
↓
┌─────────────────────────┐
│ Make Fix │
│ Test locally │
└──────────┬──────────────┘
│
↓
┌─────────────────────────┐
├─ Bump PATCH version │
│ (e.g., 0.1.0 → 0.1.1) │
├─ Update CHANGELOG │
├─ Commit to hotfix branch│
└──────────┬──────────────┘
│
↓
┌─────────────────────────┐
│ Code Review (expedited) │
│ Approval + merge │
└──────────┬──────────────┘
│
↓
┌─────────────────────────┐
│ Create Tag │
│ */prod-v0.1.1 │
└──────────┬──────────────┘
│
↓
┌─────────────────────────┐
│ Deploy to Production │
│ (High priority) │
└──────────┬──────────────┘
│
↓
┌─────────────────────────┐
│ Verify Fix │
│ Monitor 24h │
└──────────┬──────────────┘
│
↓
┌─────────────────────────┐
│ Communicate to Users │
│ Incident Report │
└──────────┬──────────────┘
│
↓
✅ Resolved
Speed target: 4-8 hours total (from detection to production verification)
```
---
## 📊 Version Matrix Dashboard
Create in your team wiki/notion:
```
╔════════════════════════════════╦═══════════╦═══════════╦═══════════╗
║ Product ║ Dev ║ Staging ║ Prod ║
╠════════════════════════════════╬═══════════╬═══════════╬═══════════╣
║ Staff Mobile ║ 0.2.1 ║ 0.2.0 ║ 0.1.0 ║
║ Client Mobile ║ 0.2.1 ║ 0.2.0 ║ 0.1.0 ║
║ Web Dashboard ║ 0.1.0 ║ 0.0.0 ║ — ║
║ Command API ║ 0.2.0 ║ 0.2.0-rc1 ║ 0.1.0 ║
║ Core API ║ 0.2.0 ║ 0.2.0-rc1 ║ 0.1.0 ║
║ DataConnect ║ 0.4.0 ║ 0.3.0 ║ 0.3.0 ║
╚════════════════════════════════╩═══════════╩═══════════╩═══════════╝
Last updated: 2026-03-05
Updated by: DevOps Team
Next release planning: 2026-03-08
```
---
## ⏱️ Release Timeline Template
For every release, create this timeline:
```
Release: [Product] v[Version]
Target: [date]
Milestones:
├─ Feb 28 (T-7): Code freeze
├─ Mar 1 (T-6): Staging release + QA testing
├─ Mar 5 (T-2): Final staging verification
├─ Mar 6 (T-1): Production deployment readiness
├─ Mar 7 (T-0): Production deployment 14:00-16:00 UTC
├─ Mar 8 (T+1): Monitoring & verification
└─ Mar 9 (T+2): Release celebration 🎉
Deployment Windows:
Testing: Anytime
Staging: Anytime
Prod: 14:00-16:00 UTC on release day
(Off-peak time in all timezones)
Rollback Window: 4 hours post-deployment
```
---
## 🎯 Status Page Template
Share with stakeholders:
```
🚀 KROW Workforce Release Status
📅 Week of March 5, 2026
Current Production Versions:
├── Staff Mobile: 0.1.0 ✅
├── Client Mobile: 0.1.0 ✅
├── Web Dashboard: TBD ⏳
├── Command API: 0.1.0 ✅
└── Core API: 0.1.0 ✅
In Staging (Testing):
├── Staff Mobile: 0.2.0 🔄 (50% through QA)
├── Client Mobile: 0.2.0 🔄 (50% through QA)
└── Web Dashboard: 0.1.0 🔄 (30% through QA)
Next Production Release:
├── Target Date: March 15, 2026
├── Products: All 5 products
├── Focus: Shift booking, payments, mobile improvements
└── Expected Impact: 2-3 hour deployment window
Risks & Blockers: None current
Recent Incidents: None
```
---
**Document Version**: 1.0
**Created**: 2026-03-05
**Maintain**: DevOps / Release Manager

382
RELEASE_WORKFLOW.md Normal file
View File

@@ -0,0 +1,382 @@
# Release Workflow Guide
Quick reference for executing releases in the KROW Workforce monorepo.
## 🚀 Quick Start Release (for a single product)
### Example: Release Staff Mobile v0.2.0
```bash
# 1. Start from main branch
git checkout main
git pull origin main
# 2. Create release branch
git checkout -b release/staff-mobile-v0.2.0
# 3. Update version numbers
# File: apps/mobile/apps/staff_app/pubspec.yaml
# Change: version: 0.1.0+5 → version: 0.2.0+6
# 4. Update CHANGELOG.md
nano CHANGELOG.md
# Add entry at top:
# | 2026-03-05 | Staff Mobile 0.2.0 | [Feature/fix descriptions] |
# 5. Commit changes
git add .
git commit -m "chore(staff-mobile): bump version to 0.2.0"
# 6. Push release branch
git push origin release/staff-mobile-v0.2.0
# 7. Create pull request on GitHub
# (GitHub CLI: gh pr create --title "Release: Staff Mobile v0.2.0" --body "See RELEASE_STRATEGY.md")
# 8. Merge to main after approval
git checkout main
git pull origin main
git merge --ff-only release/staff-mobile-v0.2.0
# 9. Create git tag
git tag -a staff-mobile/dev-v0.2.0 -m "Staff Mobile v0.2.0 - [Feature description]"
# 10. Push tag
git push origin staff-mobile/dev-v0.2.0
# 11. Create GitHub Release
# - Go to Releases → Draft a new release
# - Tag: staff-mobile/dev-v0.2.0
# - Title: "Staff Mobile v0.2.0"
# - Description: Copy from CHANGELOG
# - Attach APK/AAB if available
# - Publish
```
---
## 🔄 Multi-Product Coordinated Release
### Step-by-Step for v1.0.0 Release (all products)
#### Phase 1: Preparation (48 hours before)
```bash
# Check all tests pass
make test
make test-backend
make test-web
# Verify builds
make build-mobile-dev
make build-web
# No lint errors
make lint
```
#### Phase 2: Version Bumping
**File locations to update:**
1. **Mobile Apps**: `apps/mobile/apps/staff_app/pubspec.yaml` (and client_app)
```yaml
version: 1.0.0+1 # Increment build number
```
2. **Web Dashboard**: `apps/web/package.json`
```json
"version": "1.0.0"
```
3. **Command API**: `backend/command-api/package.json`
```json
"version": "1.0.0"
```
4. **Core API**: `backend/core-api/package.json`
```json
"version": "1.0.0"
```
5. **CodeMagic**: `codemagic.yaml`
```yaml
build_version: "1.0.0"
```
6. **CHANGELOG.md**: Add entry at top
```markdown
| 2026-03-15 | 1.0.0 | Full feature v1.0.0 release [all products] |
```
```bash
# Commit all version bumps
git add -A
git commit -m "chore: bump all products to v1.0.0"
```
#### Phase 3: Staging Release
```bash
# Create release branch
git checkout -b release/v1.0.0-staging
# Push and merge (or direct commit to release branch)
git push origin release/v1.0.0-staging
# Tag all products with staging
git tag -a web-dashboard/staging-v1.0.0 -m "v1.0.0 staging release"
git tag -a command-api/staging-v1.0.0 -m "v1.0.0 staging release"
git tag -a core-api/staging-v1.0.0 -m "v1.0.0 staging release"
git tag -a staff-mobile/staging-v1.0.0 -m "v1.0.0 staging release"
git tag -a client-mobile/staging-v1.0.0 -m "v1.0.0 staging release"
# Push all staging tags
git push origin --tags
# Deploy to staging environment
./scripts/deploy-staging.sh # (create if needed)
```
#### Phase 4: QA & Testing
- [ ] Smoke test all features
- [ ] Performance tests
- [ ] Security scan
- [ ] API contract verification
#### Phase 5: Production Release
```bash
# Create production tags (after staging approval)
git tag -a web-dashboard/prod-v1.0.0 -m "v1.0.0 production release"
git tag -a command-api/prod-v1.0.0 -m "v1.0.0 production release"
git tag -a core-api/prod-v1.0.0 -m "v1.0.0 production release"
git tag -a staff-mobile/prod-v1.0.0 -m "v1.0.0 production release"
git tag -a client-mobile/prod-v1.0.0 -m "v1.0.0 production release"
# Push tags
git push origin --tags
# Deploy in dependency order
./scripts/deploy-prod-dataconnect.sh
./scripts/deploy-prod-backend.sh
./scripts/deploy-prod-web.sh
./scripts/deploy-prod-mobile.sh
```
---
## 🔥 Hotfix Release (Emergency Production Fix)
### Example: Critical bug in Staff Mobile v1.0.0 → v1.0.1
```bash
# 1. Create hotfix branch from production tag
git checkout -b hotfix/staff-mobile-v1.0.1 staff-mobile/prod-v1.0.0
# 2. Fix the bug
git add <fixed-files>
git commit -m "fix: [critical bug description]"
# 3. Update version (PATCH bump only)
# apps/mobile/apps/staff_app/pubspec.yaml
# Change: 1.0.0+1 → 1.0.1+2
# 4. Update CHANGELOG
nano CHANGELOG.md
# Add: | 2026-03-15 | Staff Mobile 1.0.1 | Hotfix: [bug description] |
# 5. Push hotfix branch
git push origin hotfix/staff-mobile-v1.0.1
# 6. Create PR for review (expedited)
gh pr create --title "Hotfix: Staff Mobile v1.0.1" \
--body "EMERGENCY: Critical issue fix\n\nSee CHANGELOG.md for details"
# 7. Merge to main (fast-track approval)
git checkout main
git pull origin main
git merge --ff-only hotfix/staff-mobile-v1.0.1
# 8. Tag production immediately
git tag -a staff-mobile/prod-v1.0.1 -m "Hotfix: [description]"
git push origin staff-mobile/prod-v1.0.1
# 9. Deploy to production
./scripts/deploy-prod-mobile-staff.sh
# 10. Create GitHub Release with "HOTFIX" in title
```
---
## 📊 Useful Git Commands
### View all tags for a product
```bash
git tag -l "staff-mobile/*" --sort=-version:refname
git tag -l "*/prod-v*" --sort=-version:refname
```
### View tag details
```bash
git show staff-mobile/prod-v1.0.0
git log staff-mobile/prod-v1.0.0...staff-mobile/prod-v0.9.0 # Changes between versions
```
### List tags created in last week
```bash
git log --oneline --decorate --tags --since="1 week ago"
```
### See all commits since last tag
```bash
git log <last-tag>..HEAD --oneline
```
### Delete a tag (if mistake)
```bash
# Local
git tag -d staff-mobile/dev-v0.1.0
# Remote
git push origin --delete staff-mobile/dev-v0.1.0
```
### Create lightweight tag (simpler, no message)
```bash
git tag staff-mobile/dev-v0.1.0
```
---
## 🤖 Automation Scripts (Create These)
### Create: `scripts/tag-all-products.sh`
```bash
#!/bin/bash
# Usage: ./scripts/tag-all-products.sh prod 1.0.0
ENV=$1 # dev, staging, prod
VERSION=$2 # e.g., 1.0.0
if [ -z "$ENV" ] || [ -z "$VERSION" ]; then
echo "Usage: $0 <env> <version>"
echo "Example: $0 prod 1.0.0"
exit 1
fi
PRODUCTS=(
"staff-mobile"
"client-mobile"
"web-dashboard"
"command-api"
"core-api"
)
for product in "${PRODUCTS[@]}"; do
TAG="${product}/${ENV}-v${VERSION}"
echo "Creating tag: $TAG"
git tag -a "$TAG" -m "$product v$VERSION - $ENV release"
done
echo "Pushing all tags..."
git push origin --tags
echo "✅ All products tagged for $ENV-v$VERSION"
```
### Create: `scripts/show-version-matrix.sh`
```bash
#!/bin/bash
# Show version matrix of all products
echo "📦 KROW Workforce Version Matrix"
echo "================================"
echo ""
PRODUCTS=(
"staff-mobile"
"client-mobile"
"web-dashboard"
"command-api"
"core-api"
)
ENVS=("dev" "staging" "prod")
for env in "${ENVS[@]}"; do
echo "=== $ENV Environment ==="
for product in "${PRODUCTS[@]}"; do
TAGS=$(git tag -l "${product}/${env}-v*" --sort=-version:refname | head -1)
if [ -z "$TAGS" ]; then
echo " $product: (no tags)"
else
echo " $product: $TAGS"
fi
done
echo ""
done
```
---
## ✅ Release Checklist Template
Copy this for each release:
```markdown
## Release: [Product] v[Version]
**Release Date**: [Date]
**Release Manager**: [Name]
### Pre-Release (48h before)
- [ ] All PRs merged and reviewed
- [ ] Tests passing (unit + integration)
- [ ] No lint/type errors
- [ ] Mobile builds succeed on CodeMagic
- [ ] Performance benchmarks acceptable
- [ ] Security scan passed
- [ ] CHANGELOG.md updated
- [ ] Documentation updated
### Release Day
- [ ] Create release branch: `release/[product]-v[version]`
- [ ] Bump version numbers in all files
- [ ] Commit: `chore: bump [product] to v[version]`
- [ ] Create tag: `[product]/staging-v[version]`
- [ ] Deploy to staging
- [ ] Smoke tests passed
- [ ] Create GitHub Release page
### Post-Release (24h after)
- [ ] Monitor error logs
- [ ] Verify features work end-to-end
- [ ] Create production tag (if approved)
- [ ] Deploy to production
- [ ] Final verification
- [ ] Notify users
### Rollback Plan (if needed)
- [ ] Identified issue
- [ ] Created hotfix branch
- [ ] Tagged hotfix version
- [ ] Deployed rollback
- [ ] Post-mortem created
```
---
## 🔗 Related Files
- [RELEASE_STRATEGY.md](./RELEASE_STRATEGY.md) - Full strategy document
- [CHANGELOG.md](./CHANGELOG.md) - Version history
- [codemagic.yaml](./codemagic.yaml) - CI/CD configuration
---
**Last Updated**: 2026-03-05

406
VERSION_FILES_REFERENCE.md Normal file
View File

@@ -0,0 +1,406 @@
# Version File Locations Reference
When releasing a product, update version numbers in **all applicable files**. Use this checklist to ensure nothing is missed.
---
## 📱 Staff Mobile App Release
**All files to update when releasing staff mobile app:**
### 1. Pubspec.yaml
**File**: `/apps/mobile/apps/staff_app/pubspec.yaml`
```yaml
# Current state (example)
version: 0.1.0+5
# Change to (example for v0.2.0)
version: 0.2.0+6
```
**Rules**:
- Format: `MAJOR.MINOR.PATCH+BUILD_NUMBER`
- Always increment BUILD_NUMBER
- For each new version, start BUILD_NUMBER at +1
### 2. CodeMagic Configuration
**File**: `/codemagic.yaml`
Find the `mobile-client-build` workflow section:
```yaml
workflows:
mobile-client-build:
name: Mobile Client Build
environment:
# ... other env vars ...
groups:
- default
- mobile-staff-build # ← This group might have version
on_success:
- |
VERSION=$(grep "^version:" apps/mobile/apps/staff_app/pubspec.yaml | cut -d' ' -f2)
echo "Version: $VERSION" # This auto-reads from pubspec
```
**Note**: CodeMagic typically reads version from pubspec.yaml automatically. Update only if you have hardcoded version strings.
### 3. CHANGELOG.md
**File**: `/CHANGELOG.md`
Add entry at **very top** of the table:
```markdown
| Date | Version | Change |
|---|---|---|
| 2026-03-05 | Staff Mobile 0.2.0 | [Feature descriptions] |
| 2026-03-01 | 0.1.25 | Previous entry... |
```
---
## 📱 Client Mobile App Release
**All files to update when releasing client mobile app:**
### 1. Pubspec.yaml
**File**: `/apps/mobile/apps/client_app/pubspec.yaml`
```yaml
# Update format same as staff app
version: 0.2.0+6
```
### 2. CodeMagic Configuration
**File**: `/codemagic.yaml`
Find the `mobile-staff-build` workflow (NOT client-build):
```yaml
workflows:
mobile-staff-build: # ← Staff app config
# ... update pubspec reference for staff ...
mobile-client-build: # ← Client app config (if separate)
# ... update pubspec reference for client ...
```
### 3. CHANGELOG.md
**File**: `/CHANGELOG.md`
```markdown
| Date | Version | Change |
|---|---|---|
| 2026-03-05 | Client Mobile 0.2.0 | [Feature descriptions] |
```
---
## 🌐 Web Dashboard Release
**All files to update when releasing web dashboard:**
### 1. Package.json
**File**: `/apps/web/package.json`
```json
{
"name": "web",
"private": true,
"version": "0.1.0", ← Update this
// ... other fields ...
}
```
**Format**: `X.Y.Z` (semantic versioning)
### 2. CHANGELOG.md
**File**: `/CHANGELOG.md`
```markdown
| Date | Version | Change |
|---|---|---|
| 2026-03-05 | Web Dashboard 0.1.0 | [Feature descriptions] |
```
### 3. Environment/Build Files (Optional)
Check if there are any other version references:
```bash
# Search for version strings
grep -r "0.0.0" apps/web/
grep -r "VERSION" apps/web/
```
---
## 🔧 Command API Backend Release
**All files to update when releasing command API:**
### 1. Package.json
**File**: `/backend/command-api/package.json`
```json
{
"name": "@krow/command-api",
"version": "0.2.0", ← Update this
// ... other fields ...
}
```
### 2. Docker Configuration (if applicable)
**File**: `/backend/command-api/Dockerfile`
If you tag Docker images:
```dockerfile
FROM node:20-alpine
# Add label with version
LABEL version="0.2.0"
LABEL description="KROW Command API v0.2.0"
```
### 3. CHANGELOG.md
**File**: `/CHANGELOG.md`
```markdown
| Date | Version | Change |
|---|---|---|
| 2026-03-05 | Command API 0.2.0 | [Feature descriptions] |
```
### 4. Environment Configuration (if applicable)
If there's a `.env` or config file:
```bash
# Check for any version references
grep -r "VERSION\|version" backend/command-api/
```
---
## 🔧 Core API Backend Release
**All files to update when releasing core API:**
### 1. Package.json
**File**: `/backend/core-api/package.json`
```json
{
"name": "@krow/core-api",
"version": "0.2.0", ← Update this
// ... other fields ...
}
```
### 2. CHANGELOG.md
**File**: `/CHANGELOG.md`
```markdown
| Date | Version | Change |
|---|---|---|
| 2026-03-05 | Core API 0.2.0 | [Feature descriptions] |
```
### Other Files
Same as Command API (Docker, config files, etc.)
---
## 🗄️ DataConnect Database Schema Release
**Note**: DataConnect versions are typically managed separately through schema versioning.
### 1. Schema Version File (if exists)
**File**: Check in `/backend/dataconnect/`
```yaml
# Example structure
schema_version: 0.3.0
created_at: 2026-03-05
description: "Schema version 0.3.0 - [description]"
```
### 2. CHANGELOG.md
**File**: `/CHANGELOG.md`
```markdown
| Date | Version | Change |
|---|---|---|
| 2026-03-05 | DataConnect Schema 0.3.0 | [Schema changes] |
```
---
## ✅ Release Checklist: Version File Updates
### When releasing Staff Mobile v0.2.0
- [ ] `/apps/mobile/apps/staff_app/pubspec.yaml` → `0.2.0+X`
- [ ] `/codemagic.yaml` → version string (if hardcoded)
- [ ] `/CHANGELOG.md` → Add entry with date + version
- [ ] Commit: `git add . && git commit -m "chore: staff mobile v0.2.0"`
- [ ] Tag: `git tag -a staff-mobile/dev-v0.2.0 -m "Staff Mobile v0.2.0"`
- [ ] Verify: `git show staff-mobile/dev-v0.2.0`
### When releasing Client Mobile v0.2.0
- [ ] `/apps/mobile/apps/client_app/pubspec.yaml` → `0.2.0+X`
- [ ] `/codemagic.yaml` → version string (if hardcoded)
- [ ] `/CHANGELOG.md` → Add entry
- [ ] Complete release process (commit → tag → verify)
### When releasing Web Dashboard v0.1.0
- [ ] `/apps/web/package.json` → `"version": "0.1.0"`
- [ ] `/CHANGELOG.md` → Add entry
- [ ] Complete release process
### When releasing Command API v0.2.0
- [ ] `/backend/command-api/package.json` → `"version": "0.2.0"`
- [ ] `/backend/command-api/Dockerfile` → Label update (optional)
- [ ] `/CHANGELOG.md` → Add entry
- [ ] Complete release process
### When releasing Core API v0.2.0
- [ ] `/backend/core-api/package.json` → `"version": "0.2.0"`
- [ ] `/backend/core-api/Dockerfile` → Label update (optional)
- [ ] `/CHANGELOG.md` → Add entry
- [ ] Complete release process
### When releasing All Products (Synchronized Release)
- [ ] Staff Mobile: Update pubspec + codemagic
- [ ] Client Mobile: Update pubspec + codemagic
- [ ] Web: Update package.json
- [ ] Command API: Update package.json + docker
- [ ] Core API: Update package.json + docker
- [ ] **CHANGELOG.md**: Add comprehensive entry with all products
- [ ] Single commit: `git commit -m "chore: release all products v1.0.0"`
- [ ] Multiple tags (one per product):
```bash
git tag -a staff-mobile/prod-v1.0.0 -m "v1.0.0"
git tag -a client-mobile/prod-v1.0.0 -m "v1.0.0"
git tag -a web-dashboard/prod-v1.0.0 -m "v1.0.0"
git tag -a command-api/prod-v1.0.0 -m "v1.0.0"
git tag -a core-api/prod-v1.0.0 -m "v1.0.0"
git push origin --tags
```
---
## 🔍 Verify All Updates
After updating versions, verify nothing was missed:
```bash
# Search for old version strings still remaining
grep -r "0.1.0" apps/mobile/ --include="*.yaml" --include="*.yml" --include="*.json"
grep -r "0.0.0" apps/web/ --include="*.json"
grep -r "0.1.0" backend/ --include="*.json"
# Check CHANGELOG was updated
head -5 CHANGELOG.md
# Verify git status shows all changes
git status
# Review exact changes before committing
git diff CHANGELOG.md
git diff apps/mobile/apps/staff_app/pubspec.yaml
git diff apps/web/package.json
```
---
## 📝 Version Update Template
Copy this template for each release:
```bash
#!/bin/bash
# Release: [Product] v[Version]
# Date: [Date]
# Update Staff Mobile
sed -i '' 's/version: 0.1.0+5/version: 0.2.0+6/' apps/mobile/apps/staff_app/pubspec.yaml
# Update CHANGELOG
# (Manual: Add entry at top with date and version)
# Verify
grep "^version:" apps/mobile/apps/staff_app/pubspec.yaml
head -3 CHANGELOG.md
# Commit
git add -A
git commit -m "chore: bump staff mobile to v0.2.0"
# Tag
git tag -a staff-mobile/dev-v0.2.0 -m "Staff Mobile v0.2.0"
git push origin staff-mobile/dev-v0.2.0
# Done!
echo "✅ Release complete. Tag: staff-mobile/dev-v0.2.0"
```
---
## 🚨 Common Mistakes
❌ **Forgot to update pubspec.yaml**
- Result: Version mismatch between code and git tag
❌ **Updated CHANGELOG but forgot to update package.json**
- Result: Version inconsistency, harder to debug
❌ **Updated version but didn't increment build number (mobile)**
- Result: Build tools may fail or warn
❌ **Forgot to update codemagic.yaml**
- Result: CI/CD may deploy old version
❌ **Updated multiple files but forgot to commit CHANGELOG**
- Result: Historical record lost
✅ **Always:**
1. Update ALL version files
2. Update CHANGELOG.md
3. Commit ALL changes together
4. Tag after commit
5. Verify with `git show <tag>`
---
## 🎯 Pro Tips
**Tip 1**: Use a script to update all versions at once
```bash
# Create update-version.sh
VERSION="0.2.0"
sed -i '' "s/version:.*/version: $VERSION/" apps/mobile/apps/staff_app/pubspec.yaml
sed -i '' "s/\"version\".*/\"version\": \"$VERSION\"/" apps/web/package.json
# ... etc for all files
```
**Tip 2**: Automate version bumping based on git commit messages
Use conventional commits (`feat:`, `fix:`, `BREAKING CHANGE:`) to auto-determine MAJOR/MINOR/PATCH
**Tip 3**: Use GitHub Actions to auto-create tags
Create an action that tags on PR merge with version from package.json
---
**Last Updated**: 2026-03-05
**Maintain**: DevOps Team

2
apps/mobile/apps/client/pubspec.yaml
View File

@@ -1,7 +1,7 @@
name: krowwithus_client
description: "KROW Client Application"
publish_to: "none"
version: 0.0.1-IlianaClientM3
version: 0.0.1-m4
resolution: workspace
environment:

2
apps/mobile/apps/staff/pubspec.yaml
View File

@@ -1,7 +1,7 @@
name: krowwithus_staff
description: "KROW Staff Application"
publish_to: 'none'
version: 0.0.1-IlianaStaffM3
version: 0.0.1-m4
resolution: workspace
environment:

343
docs/RELEASE/HOTFIX_PROCESS.md Normal file
View File

@@ -0,0 +1,343 @@
# Hotfix Process
**For Emergency Production Fixes**
---
## 🚨 When to Hotfix
Use hotfix when:
- ✅ Critical bug in production affecting users
- ✅ Data loss or security vulnerability
- ✅ Service unavailable or major feature broken
- ✅ Customer-blocking issue
**Don't use hotfix for:**
- ❌ Minor bugs (can wait for next release)
- ❌ Feature requests
- ❌ Nice-to-have improvements
- ❌ Styling issues
---
## 🔄 Hotfix Process
### Step 1: Assess & Declare Emergency
```
Issue: [Brief description]
Severity: CRITICAL / HIGH / MEDIUM
Product: [Staff Mobile / Client Mobile / Web / Backend]
Environment: Production
Impact: [How many users affected]
```
Once severity confirmed → Start hotfix immediately.
---
### Step 2: Create Hotfix Branch
```bash
# From production tag
git checkout -b hotfix/krow-withus-worker-mobile-v0.1.1 \
krow-withus-worker-mobile/prod-v0.1.0
# Verify you're on the right tag
git log -1 --oneline
```
**Format**: `hotfix/<product>-v<PATCH+1>`
---
### Step 3: Fix the Bug
```bash
# Make your fix
# Edit files, test locally
# Commit with clear message
git commit -m "fix: [issue description]
HOTFIX for production
Issue: [what happened]
Solution: [what was fixed]
Tested: [how was it tested locally]"
```
**Keep it minimal:**
- Only fix the specific bug
- Don't refactor or optimize
- Don't add new features
---
### Step 4: Update Version
Update PATCH version only (0.1.0 → 0.1.1):
**For Mobile** (`apps/mobile/apps/*/pubspec.yaml`):
```yaml
# Old
version: 0.1.0+5
# New
version: 0.1.1+6 # Only PATCH changed
```
**For Web** (`apps/web/package.json`):
```json
"version": "0.1.1"
```
**For Backend** (`backend/*/package.json`):
```json
"version": "0.1.1"
```
---
### Step 5: Update CHANGELOG
Add entry to **top** of appropriate CHANGELOG:
```markdown
| 2026-03-05 | 0.1.1 | HOTFIX: [Issue fixed] |
(previous entries below...)
```
---
### Step 6: Code Review (Expedited)
```bash
# Push hotfix branch
git push origin hotfix/krow-withus-worker-mobile-v0.1.1
# Create PR on GitHub with URGENT label
gh pr create --title "HOTFIX: [Issue description]" \
--body "**URGENT PRODUCTION FIX**
Issue: [What was broken]
Impact: [Users affected]
Solution: [What was fixed]
Testing: [Local verification]"
```
**Get approval within 15 minutes if possible.**
---
### Step 7: Merge to Main
```bash
# Review complete - merge
git checkout main
git pull origin main
git merge --ff-only hotfix/krow-withus-worker-mobile-v0.1.1
git push origin main
```
---
### Step 8: Create Production Tag
```bash
# Create tag from main
git tag -a krow-withus-worker-mobile/prod-v0.1.1 \
-m "HOTFIX: [Issue fixed]"
git push origin krow-withus-worker-mobile/prod-v0.1.1
```
---
### Step 9: Deploy to Production
```bash
# Follow your deployment procedure
# Higher priority than normal releases
./scripts/deploy-mobile-production.sh krow-withus-worker-mobile/prod-v0.1.1
```
**Deployment time**: Within 30 minutes of approval
---
### Step 10: Verify & Monitor
```bash
# Smoke tests
- App launches
- Core features work
- No new errors
# Monitor for 2 hours
- Watch error logs
- Check user reports
- Verify fix worked
```
---
### Step 11: Communicate
**Immediately after deployment:**
```markdown
🚨 PRODUCTION HOTFIX DEPLOYED
Product: Worker Mobile
Version: 0.1.1
Issue: [Fixed issue]
Impact: [Resolved for X users]
Status: ✅ Deployed & verified
No user action required.
Service restored to normal.
```
**24 hours later:**
```markdown
✅ HOTFIX STATUS UPDATE
Production hotfix v0.1.1 deployed 24 hours ago.
Zero errors reported post-deployment.
System stable.
Thank you for your patience!
```
---
## ⏱️ Timeline
```
T-0: Issue detected & reported
T+5min: Severity assessed, hotfix branch created
T+15: Fix implemented, code review started
T+30: Approved & merged, tag created
T+45: Deployed to production
T+60: Smoke tests pass, monitoring enabled
T+120: Declare emergency resolved, communicate
T+1day: Follow-up communication
```
**Total time: 2-4 hours from detection to resolution**
---
## 🚫 Common Mistakes to Avoid
❌ **Don't**:
- Skip code review (even in emergency)
- Add multiple unrelated fixes in one hotfix
- Forget to update version number
- Forget CHANGELOG entry
- Deploy without testing
- Forget to communicate with users
✅ **Do**:
- Keep hotfix minimal and focused
- Test every fix locally first
- Get at least one approval
- Update all version files
- Deploy immediately after approval
- Monitor actively for 2+ hours
---
## 📋 Hotfix Checklist
Copy for each emergency:
```
Hotfix: [Product] v[Old Version] → v[New Version]
□ Severity assessed & documented
□ Branch created from production tag
□ Bug fixed & tested locally
□ Version number updated (PATCH only)
□ CHANGELOG entry added
□ Commit message clear
□ Code review requested (marked URGENT)
□ Approval obtained
□ Merged to main
□ Production tag created
□ Tag pushed to remote
□ Deployed to production
□ Smoke tests passed
□ Error logs monitored (2+ hours)
□ Users notified
□ GitHub Release created
□ Incident documented
Total Time: ___ minutes
```
---
## 🔍 Post-Incident
After emergency is resolved:
1. **Document what happened**
- Root cause analysis
- Why it wasn't caught before
- What testing was missed
2. **Schedule postmortem** (within 24 hours)
- Review what went wrong
- Discuss prevention
- Update processes if needed
3. **Plan prevention**
- Add test coverage
- Update CI/CD checks
- Improve monitoring
4. **Communicate findings**
- Share with team
- Update documentation
- Prevent recurrence
---
## 📞 Emergency Contacts
When issue detected:
1. **Notify**:
- Release Engineer
- DevOps
- Product Owner
- Affected Team
2. **Communication Channel**:
- Slack: #emergency-releases
- Time-sensitive decisions on call
3. **Decision Maker**:
- Product Owner approves rollback vs hotfix
- Release Engineer executes
- DevOps monitors infrastructure
---
## 🔗 Related
- [OVERALL_RELEASE_PLAN.md](./OVERALL_RELEASE_PLAN.md) - Main release strategy
- [MOBILE_RELEASE_PLAN.md](./MOBILE_RELEASE_PLAN.md) - Mobile-specific process
- [../../CHANGELOG.md](../../CHANGELOG.md) - Version history
---
**Last Updated**: 2026-03-05
**Severity Levels**:
- 🔴 CRITICAL: Service down, data loss, security (< 1 hour)
- 🟠 HIGH: Major feature broken, workaround available (< 4 hours)
- 🟡 MEDIUM: Minor feature affected (next release OK)

564
docs/RELEASE/MOBILE_RELEASE_PLAN.md Normal file
View File

@@ -0,0 +1,564 @@
# Mobile App Release Plan
**For Staff Mobile & Client Mobile Apps**
---
## 📱 Overview
This document covers release procedures for:
- **Staff Mobile App** (aka "Worker Mobile") - `krow-withus-worker-mobile`
- **Client Mobile App** - `krow-withus-client-mobile`
Both apps:
- Built with Flutter
- Distributed to iOS & Android app stores
- Maintain independent versions
- Have independent CHANGELOGs
- Share backend infrastructure
---
## 🏷️ Tag & Release Naming
### Tag Format
```
krow-withus-<app>-mobile/<environment>-v<major>.<minor>.<patch>
```
### Examples
**Staff Mobile (Worker Mobile)**
```
krow-withus-worker-mobile/dev-v0.1.0
krow-withus-worker-mobile/stage-v0.2.0
krow-withus-worker-mobile/prod-v1.0.0
krow-withus-worker-mobile/prod-v1.0.1-hotfix.1
```
**Client Mobile**
```
krow-withus-client-mobile/dev-v0.1.0
krow-withus-client-mobile/stage-v0.2.0
krow-withus-client-mobile/prod-v1.0.0
```
### GitHub Release Names
```
Krow With Us - Worker Mobile - DEV - v0.1.0
Krow With Us - Worker Mobile - STAGE - v0.2.0
Krow With Us - Worker Mobile - PROD - v1.0.0
Krow With Us - Client Mobile - DEV - v0.1.0
Krow With Us - Client Mobile - STAGE - v0.2.0
Krow With Us - Client Mobile - PROD - v1.0.0
```
---
## 📝 CHANGELOG Management
### Location
Each app has its own CHANGELOG in the `apps/mobile/` directory structure:
```
apps/mobile/
├── packages/
│ ├── features/
│ │ ├── staff/
│ │ │ ├── authentication/CHANGELOG.md
│ │ │ ├── home/CHANGELOG.md
│ │ │ ├── payments/CHANGELOG.md
│ │ │ ├── shifts/CHANGELOG.md
│ │ │ └── ... (other staff features)
│ │ └── client/
│ │ ├── dashboard/CHANGELOG.md
│ │ ├── orders/CHANGELOG.md
│ │ └── ... (other client features)
│ └── ... (other packages)
├── apps/
│ ├── staff_app/CHANGELOG.md ← Staff app root
│ └── client_app/CHANGELOG.md ← Client app root
└── CHANGELOG.md ← Consolidated (optional)
```
### App-Level CHANGELOG Format
**File**: `apps/mobile/apps/staff_app/CHANGELOG.md`
```markdown
# Staff Mobile App - Change Log
## [0.2.0] - 2026-03-15
### Added
- Feature X implementation
- Feature Y enhancement
- New UI component Z
### Fixed
- Bug fix for issue #123
- Crash when loading payments
### Changed
- Updated design system
- Improved performance
### Deprecated
- Removed old API endpoint
## [0.1.0] - 2026-03-01
### Added
- Initial release
- Authentication with phone & OTP
- Shift browsing and booking
- Clock in/out functionality
- Payment history view
```
### Consolidated CHANGELOG (Optional)
**File**: `apps/mobile/CHANGELOG.md` (at root of mobile folder)
High-level overview of both apps:
```markdown
# Krow Workforce - Mobile Apps - Change Log
## Staff Mobile v0.2.0 + Client Mobile v0.1.0 - 2026-03-15
### Staff Mobile v0.2.0
- Feature improvements
- Bug fixes
### Client Mobile v0.1.0
- Initial release
## Previous versions...
```
---
## 📝 Version Files
### Staff Mobile App
**Primary Version File**: `apps/mobile/apps/staff_app/pubspec.yaml`
```yaml
name: staff_app
description: "Krow With Us - Staff App"
# Version format: MAJOR.MINOR.PATCH+BUILD_NUMBER
version: 0.1.0+1
environment:
sdk: '>=3.10.0 <4.0.0'
flutter: '>=3.38.0 <4.0.0'
```
**Rules**:
- Update version before each release
- Bump build number (+1) every build
- SemVer only for version part (before +)
### Client Mobile App
**Primary Version File**: `apps/mobile/apps/client_app/pubspec.yaml`
```yaml
name: client_app
description: "Krow With Us - Client App"
version: 0.1.0+1
environment:
sdk: '>=3.10.0 <4.0.0'
flutter: '>=3.38.0 <4.0.0'
```
---
## 🚀 Release Workflow
### Step 1: Create Release Branch
```bash
cd /Users/achintha/Documents/GitHub/krow-workforce
# For Staff Mobile
git checkout -b release/staff-mobile-v0.2.0
# For Client Mobile
git checkout -b release/client-mobile-v0.2.0
```
---
### Step 2: Update Version Numbers
#### Staff Mobile Example (v0.1.0 → v0.2.0)
**File**: `apps/mobile/apps/staff_app/pubspec.yaml`
```yaml
# Old
version: 0.1.0+5
# New
version: 0.2.0+6
```
#### Client Mobile Example (v0.1.0 → v0.2.0)
**File**: `apps/mobile/apps/client_app/pubspec.yaml`
```yaml
# Old
version: 0.1.0+3
# New
version: 0.2.0+4
```
---
### Step 3: Update CHANGELOG
**File**: `apps/mobile/apps/staff_app/CHANGELOG.md`
Add entry at **top**:
```markdown
# Staff Mobile App - Change Log
## [0.2.0] - 2026-03-05
### Added
- New shift details page with profile gating
- Benefits overview section
- Auto-match functionality
### Fixed
- Payment history display bug
- Clock-in location verification
### Changed
- Updated design system components
- Improved shift booking flow
## [0.1.0] - 2026-02-15
...
```
---
### Step 4: Commit Changes
```bash
cd /Users/achintha/Documents/GitHub/krow-workforce
# Stage changes
git add apps/mobile/apps/staff_app/pubspec.yaml
git add apps/mobile/apps/staff_app/CHANGELOG.md
# Commit
git commit -m "chore(staff-mobile): bump version to 0.2.0
- Updated pubspec.yaml version: 0.1.0 → 0.2.0
- Updated build number: 5 → 6
- Updated CHANGELOG.md with v0.2.0 changes"
```
---
### Step 5: Create Pull Request
```bash
# Push release branch
git push origin release/staff-mobile-v0.2.0
# Create PR (GitHub CLI)
gh pr create \
--title "Release: Staff Mobile v0.2.0" \
--body "## Release: Staff Mobile v0.2.0
### Changes
- See CHANGELOG.md for full list
### Testing
- [ ] All tests passing
- [ ] Manual testing complete
- [ ] CodeMagic build successful
### Checklist
- [x] Version updated
- [x] CHANGELOG updated
- [x] Branch created from main
- [ ] Approved by team lead"
```
---
### Step 6: Merge to Main
Once PR is approved:
```bash
# Switch to main
git checkout main
git pull origin main
# Merge (fast-forward only)
git merge --ff-only release/staff-mobile-v0.2.0
# Push to remote
git push origin main
# Delete release branch
git push origin --delete release/staff-mobile-v0.2.0
```
---
### Step 7: Create Git Tag
```bash
# For DEV release
git tag -a krow-withus-worker-mobile/dev-v0.2.0 \
-m "Staff Mobile v0.2.0 - Dev Release
Features:
- Shift details improvements
- Benefits overview
- Auto-match functionality
Testing:
- All unit tests passing
- Manual QA on dev environment"
# For STAGE release
git tag -a krow-withus-worker-mobile/stage-v0.2.0 \
-m "Staff Mobile v0.2.0 - Stage Release"
# For PROD release
git tag -a krow-withus-worker-mobile/prod-v0.2.0 \
-m "Staff Mobile v0.2.0 - Production Release"
```
**Push tags**:
```bash
git push origin krow-withus-worker-mobile/dev-v0.2.0
git push origin krow-withus-worker-mobile/stage-v0.2.0
git push origin krow-withus-worker-mobile/prod-v0.2.0
```
---
### Step 8: Create GitHub Release
1. Go to: GitHub → Releases → Draft a new release
2. Fill in:
```
Tag version: krow-withus-worker-mobile/dev-v0.2.0
Release title:
Krow With Us - Worker Mobile - DEV - v0.2.0
Description:
## 🎯 What's New in v0.2.0
### ✨ Features
- Shift details page with profile completion gating
- Benefits overview with sick leave tracking
- Auto-match shift recommendations
### 🔧 Improvements
- Faster payment history loading
- Better shift booking UX
- Improved clock-in reliability
### 🐛 Bug Fixes
- Fixed payment display date issue
- Fixed location verification on iOS 15+
- Fixed crash when no shifts available
## 📦 Installation
**iOS**: Download via TestFlight (internal) or App Store
**Android**: Download via Play Store
## 🔗 Dependencies
Requires:
- Backend API v0.1.0+
- DataConnect schema v0.3.0+
## ⚠️ Known Issues
- Location permissions take 5-10 seconds on first install
- Workaround: Grant permissions in Settings app
## 📝 Notes for QA
- Test on actual device, not emulator
- Verify clock-in with GPS enabled
- Test all payment history edge cases
---
Release Date: 2026-03-05
Build Number: 6
```
3. **Optional**: Attach build artifacts (APK/AAB from CodeMagic)
4. **Click**: "Publish release"
---
## 🔄 Deployment Flow
### Dev Release → Staging
After dev is tested:
```bash
# Create stage tag from same commit
git tag -a krow-withus-worker-mobile/stage-v0.2.0 \
krow-withus-worker-mobile/dev-v0.2.0 \
-m "Staff Mobile v0.2.0 - Stage Release"
git push origin krow-withus-worker-mobile/stage-v0.2.0
# Deploy using CodeMagic or manual process
```
### Staging Release → Production
After QA approval:
```bash
# Create prod tag from same commit
git tag -a krow-withus-worker-mobile/prod-v0.2.0 \
krow-withus-worker-mobile/stage-v0.2.0 \
-m "Worker Mobile v0.2.0 - Production Release"
git push origin krow-withus-worker-mobile/prod-v0.2.0
# Deploy to production
```
---
## 📱 App Store Distribution
### iOS App Store
**Version Name**: Match pubspec.yaml version (0.2.0)
**Build Number**: Match pubspec.yaml build number (+6)
**Steps**:
1. Ensure TestFlight build passed
2. Submit to App Review
3. Apple reviews (3-5 days)
4. Release to users (can be phased)
### Google Play Store
**Version Name**: Match pubspec.yaml version (0.2.0)
**Version Code**: Match pubspec.yaml build number (6)
**Steps**:
1. Upload APK/AAB from CodeMagic
2. Fill in release notes (from CHANGELOG)
3. Submit for review
4. Google reviews (hours to 24h)
5. Release to users (can be phased, e.g., 10% then 100%)
---
## 🔧 Pre-Release Checklist
Before creating tags:
- [ ] All PRs merged to main
- [ ] Code review complete
- [ ] Tests passing (unit, widget, integration)
- [ ] No lint/analysis errors: `flutter analyze`
- [ ] Pubspec.yaml version updated
- [ ] Build number incremented
- [ ] CHANGELOG.md updated with date
- [ ] Screenshots prepared (fresh)
- [ ] Release notes drafted
- [ ] No hardcoded strings (use translations)
- [ ] No debug prints remaining
- [ ] Performance acceptable (app launch < 3 seconds)
- [ ] Screen lock/unlock works
- [ ] Deep links tested
- [ ] Notifications working
- [ ] GPS/location working
- [ ] Camera permissions working
- [ ] All user-facing text reviewed
---
## 🎯 Release Cadence
### Development Releases (dev)
- **Frequency**: Weekly
- **Day**: Monday 10:00 UTC
- **Process**: Quick, test in dev only
### Staging Releases (stage)
- **Frequency**: Bi-weekly (on sprint/feature completion)
- **Day**: Wednesday before production
- **Process**: Full QA testing, 1 week in staging
### Production Releases (prod)
- **Frequency**: Monthly (end of sprint)
- **Day**: Sunday/Monday morning (low traffic)
- **Process**: Full validation, market distribution
---
## 🔗 Related
- [OVERALL_RELEASE_PLAN.md](./OVERALL_RELEASE_PLAN.md) - General strategy
- [HOTFIX_PROCESS.md](./HOTFIX_PROCESS.md) - Emergency procedures
- [../../CHANGELOG.md](../../CHANGELOG.md) - Root-level history
---
## 📞 Common Questions
**Q: What if I need to release just one app (not both)?**
A: Completely fine! Each app is independent. Release when ready.
**Q: Do I need to update the root CHANGELOG?**
A: Optional. If you do, keep it high-level and reference app-specific CHANGELOGs.
**Q: What about shared packages inside mobile/?**
A: If shared package updated, mention in both app CHANGELOGs.
**Q: How do I handle breaking changes?**
A: MAJOR version bump (0.x → 1.x) and clearly document in CHANGELOG.
**Q: Can I release dev and stage on different days?**
A: Yes, no fixed schedule for dev/stage. Prod should be consistent (Sundays).
---
**Last Updated**: 2026-03-05
**Owner**: Mobile Engineering Team
**Status**: Active

452
docs/RELEASE/OVERALL_RELEASE_PLAN.md Normal file
View File

@@ -0,0 +1,452 @@
# KROW Workforce - Overall Release Plan
**Document Version**: 1.0
**Created**: 2026-03-05
**Last Updated**: 2026-03-05
**Product Scope**: All products (Mobile, Web, Backend, Database)
---
## 📋 Overview
This document outlines the release strategy for KROW Workforce monorepo containing 5 products:
1. **Staff Mobile App** (Flutter - iOS/Android)
2. **Client Mobile App** (Flutter - iOS/Android)
3. **Web Dashboard** (React/Vite)
4. **Backend Services** (Node.js - Command API, Core API)
5. **Database** (Firebase Data Connect with PostgreSQL)
---
## 🔗 Versioning Strategy
### Semantic Versioning (SemVer)
All products use **Semantic Versioning 2.0.0**:
```
MAJOR.MINOR.PATCH-QUALIFIER
0.1.0
1.2.3-rc.1
```
- **MAJOR** (0→1): Breaking changes, major features
- **MINOR** (1→2): Backward-compatible new features
- **PATCH** (3→4): Bug fixes, minor improvements
- **QUALIFIER** (optional): `-rc.1`, `-beta.1`, `-hotfix.1`
### Version Independence
Each product maintains **independent versioning**:
- Products release on their own schedule
- No requirement to synchronize versions
- Can release major updates independently
---
## 🏷️ Git Tag Naming Convention
### Standard Format
```
<product>/<environment>-v<major>.<minor>.<patch>
```
### Products & Environments
| Product | Tag Prefix | Environments |
|---------|-----------|---------------|
| Staff Mobile | `krow-withus-worker-mobile` | dev, stage, prod |
| Client Mobile | `krow-withus-client-mobile` | dev, stage, prod |
| Web Dashboard | `web-dashboard` | dev, stage, prod |
| Command API | `command-api` | dev, stage, prod |
| Core API | `core-api` | dev, stage, prod |
| DataConnect | `dataconnect` | stage, prod |
### Environments
- **dev**: Development releases (daily/weekly), unstable
- **stage**: Staging releases (bi-weekly), pre-production testing
- **prod**: Production releases (monthly), stable, customer-facing
### Examples
```
krow-withus-worker-mobile/dev-v0.1.0
krow-withus-client-mobile/stage-v0.2.0
web-dashboard/prod-v1.0.0
command-api/dev-v0.2.1
core-api/prod-v0.1.0
```
---
## 📅 Release Cadence
### Development Releases (dev)
- **Frequency**: Weekly or as-needed
- **Scope**: Feature completions, bug fixes
- **Duration**: Not guaranteed stable
- **Deployment**: Dev environment only
- **Who**: Development team
### Staging Releases (stage)
- **Frequency**: Bi-weekly (typically mid/end of sprint)
- **Scope**: Sprint completion, feature milestones
- **Duration**: 1-2 weeks stability expected
- **Deployment**: Staging environment for QA
- **Who**: QA team validates
### Production Releases (prod)
- **Frequency**: Monthly or sprint-based
- **Scope**: Feature milestone completion, critical fixes
- **Duration**: 4+ weeks standard support
- **Deployment**: Production environment (customer-facing)
- **Who**: Product owner approves, DevOps deploys
---
## 🔄 Product Dependency & Deployment Order
### Critical Path (for synchronized releases)
Deploy in this order:
1. **DataConnect Schema** (if schema changed)
- Deploy schema changes first
- All APIs depend on schema availability
2. **Backend Services** (parallel OK)
- Command API
- Core API
- Both can deploy simultaneously
3. **Web Dashboard**
- Can deploy once backend ready
- Test API endpoints stable
4. **Mobile Apps** (parallel OK)
- Staff Mobile
- Client Mobile
- Both can deploy simultaneously, independent of web
### Independent Releases
Products **can release independently** if:
- No backend schema changes
- No breaking API changes
- No data migrations required
Example: Staff Mobile can release UI improvements without web/backend changes.
---
## 📝 CHANGELOG Management
### Location & Structure
Each major product maintains its own CHANGELOG:
```
apps/mobile/packages/features/staff/*/CHANGELOG.md
apps/mobile/packages/features/client/*/CHANGELOG.md
apps/web/CHANGELOG.md
backend/command-api/CHANGELOG.md
backend/core-api/CHANGELOG.md
CHANGELOG.md (root - high-level overview)
```
### Format
```markdown
| Date | Version | Change |
|------|---------|--------|
| 2026-03-05 | 0.1.0 | Initial release - [feature list] |
```
### What to Track
- Features added
- Bugs fixed
- Breaking changes (clearly marked ⚠️)
- Dependencies upgraded
- Migration steps (if applicable)
---
## ✅ Release Checklist
### Pre-Release (48 hours before)
- [ ] All PRs merged to main
- [ ] Code review complete
- [ ] All tests passing (unit, integration, E2E)
- [ ] No lint/type errors
- [ ] Mobile builds succeed (CodeMagic)
- [ ] Performance benchmarks acceptable
- [ ] Security scan completed
- [ ] CHANGELOG.md updated with all changes
- [ ] Documentation updated
- [ ] Team notified of pending release
### Release Day
- [ ] Update version numbers in all relevant files
- [ ] Update CHANGELOG with date
- [ ] Git commit: `git commit -m "chore: bump version to X.Y.Z"`
- [ ] Git push changes to main
- [ ] Create git tag: `git tag -a <product>/<env>-v<version> -m "Release message"`
- [ ] Push tags: `git push origin <tag-name>`
- [ ] Deploy to target environment
- [ ] Smoke tests pass
- [ ] Create GitHub Release page
- [ ] Notify stakeholders
### Post-Release (24 hours)
- [ ] Monitor error logs
- [ ] Verify all features work end-to-end
- [ ] Performance is acceptable
- [ ] No regressions reported
- [ ] Users updated if needed
- [ ] Document any issues
---
## 🔐 Protected Tags
### Branch Protection Rules
**Production tags require approval:**
- Tag pattern: `*/prod-v*`
- Require pull request review (1+ approval)
- Require status checks to pass
- Prevent force pushes
- Disable deletions
**Staging tags recommended:**
- Tag pattern: `*/stage-v*`
- Consider: Require at least 1 approval
- Status checks should pass
**Dev tags open:**
- Tag pattern: `*/dev-v*`
- No restrictions
- Allow fast iteration
---
## 🚨 Rollback Procedures
### For Production Issues
**If critical issue detected:**
1. **Identify** the product and issue
2. **Assess** impact and severity
3. **Decide** rollback vs hotfix
- Rollback: Undo entire release
- Hotfix: Fix and re-release (see HOTFIX_PROCESS.md)
4. **Execute** rollback:
```bash
# Revert commit
git revert <commit-hash> -m 1
git push origin main
# Or switch traffic back to previous version
# (depends on deployment infrastructure)
```
5. **Communicate** with users
6. **Plan** hotfix or next release
### Time Windows
- **Awareness**: 15-30 minutes (monitoring)
- **Decision**: 15-30 minutes (severity assessment)
- **Execution**: 15-60 minutes (rollback deployment)
- **Verification**: 30-60 minutes (smoke tests)
- **Communication**: Immediate + 24h updates
**Total**: 2-4 hours from detection to stable state
---
## 📊 Release Templates & Tools
### Git Commands
```bash
# Create tag
git tag -a krow-withus-worker-mobile/dev-v0.1.0 \
-m "Staff Mobile v0.1.0 - Feature X"
# Push tag
git push origin krow-withus-worker-mobile/dev-v0.1.0
# View tags for product
git tag -l "krow-withus-worker-mobile/*" --sort=-version:refname
# See what's in a tag
git show krow-withus-worker-mobile/dev-v0.1.0
# Delete tag (if mistake)
git tag -d krow-withus-worker-mobile/dev-v0.1.0
git push origin --delete krow-withus-worker-mobile/dev-v0.1.0
```
### GitHub Release Template
```markdown
# Krow With Us - Worker Mobile - DEV - v0.1.0
**Release Date**: [Date]
**Environment**: Development
## What's New
### ✨ Features
- Feature 1 description
- Feature 2 description
### 🔧 Improvements
- Improvement 1
- Improvement 2
### 🐛 Bug Fixes
- Bug fix 1
- Bug fix 2
## Dependencies
Requires:
- Backend API v0.1.0 or higher
- DataConnect schema v0.3.0 (if updated)
## Installation
[Download links & instructions]
## Known Issues
- Issue 1: [desc] (Workaround: ...)
## Support
contact: support@krow-workforce.com
```
---
## 🔄 Hotfix Releases
See [HOTFIX_PROCESS.md](./HOTFIX_PROCESS.md) for emergency procedures.
Quick summary:
1. Branch from production tag
2. Fix the issue
3. Bump PATCH version only
4. Test and deploy immediately
5. Create hotfix tag
---
## 📱 Mobile-Specific Release Process
See [MOBILE_RELEASE_PLAN.md](./MOBILE_RELEASE_PLAN.md) for detailed mobile app process including:
- Staff Mobile vs Client Mobile differences
- Build number management
- CodeMagic integration
- App store distribution
- CHANGELOG per app
---
## 🎯 Release Coordination
### Single Product Release
1. Update version files
2. Update CHANGELOG
3. Commit & push
4. Create tag
5. Deploy
6. Create GitHub Release
**Time**: 30-45 minutes (excluding testing)
### Multi-Product Release (e.g., v1.0.0)
**Pre-release phase** (1 week before):
- Code freeze announced
- QA testing begins
- No new features merged
**Release phase** (2-3 days):
- Staging release (all products)
- QA validation
- Product owner sign-off
**Production phase** (1 day):
- Deploy in dependency order
- Smoke tests each product
- Monitor 24 hours
- User communication
**Time**: 5-7 days total, 4 hours active deployment
---
## 📞 Roles & Responsibilities
| Role | Responsibility |
|------|-----------------|
| **Developer** | Keep code release-ready, update versions |
| **QA** | Test staging releases, validate prod |
| **Release Engineer** | Create tags, manage deployment, monitor |
| **Product Owner** | Approve releases, communicate timeline |
| **DevOps** | Infrastructure ready, deployment scripts |
---
## 📊 Success Metrics
Track these per release:
- **Lead Time**: Time from code commit to production
- **Deployment Frequency**: How often you release
- **Change Failure Rate**: % of releases needing rollback
- **Time to Recovery**: Time to fix production issues
- **User Adoption**: % of users on latest version
---
## 📚 Related Documentation
- [MOBILE_RELEASE_PLAN.md](./MOBILE_RELEASE_PLAN.md) - Mobile app releases
- [HOTFIX_PROCESS.md](./HOTFIX_PROCESS.md) - Emergency procedures
- [../../RELEASE_STRATEGY.md](../../RELEASE_STRATEGY.md) - Original detailed guide
- [../../CHANGELOG.md](../../CHANGELOG.md) - Root version history
---
## ✅ Implementation Status
- ✅ Versioning strategy: SemVer
- ✅ Environments: dev, stage, prod
- ✅ Tag naming: Product-specific with brand prefix
- ✅ Product dependencies: Defined
- ✅ Release cadence: 3 levels
- ⏳ GitHub Actions: To be set up
- ⏳ Deployment automation: To be set up
---
**Next Step**: Review [MOBILE_RELEASE_PLAN.md](./MOBILE_RELEASE_PLAN.md) for app-specific process.