Development Workflow
Step-by-step guide for developing, testing, and deploying changes
Development Workflow
This guide explains the complete workflow for making changes, from local development to production deployment.
Overview
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Local │ → │ Preview │ → │ Staging │ → │ Production │
│ Branch │ │ (PR) │ │ (main) │ │ (manual) │
└─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘
Code Test UAT You Approve| Environment | Trigger | URL | Purpose |
|---|---|---|---|
| Local | Manual | localhost:3000 | Development |
| Preview | Create PR | hrms-docs-pr-{n}-xxx.run.app | PR Review |
| Staging | Merge to main | hrms-docs-staging-xxx.run.app | UAT/QA |
| Production | Manual trigger | docs.hrms.bluewoo.com | Live |
Branch Protection
The main branch is protected:
- ✅ No direct pushes allowed
- ✅ Pull requests required
- ✅ Tests must pass before merge
- ✅ Enforce for admins - Even admins cannot bypass
Mandatory Checkpoint Gates
ENFORCED
When working with AI agents, these 4 checkpoints require explicit human approval. AI will NOT proceed without your confirmation at each gate.
┌─────────────────────────────────────────────────────────────────┐
│ PHASE A: Code Changes │
│ 1. Create feature branch │
│ 2. Make code changes │
│ 3. Commit changes │
│ │
│ 🛑 CHECKPOINT 1: "Code ready. OK to push?" │
│ └── You verify code diff, say "OK to push" │
├─────────────────────────────────────────────────────────────────┤
│ PHASE B: Pull Request │
│ 4. Push to GitHub │
│ 5. Create PR │
│ 6. Wait for preview (~5 min) │
│ │
│ 🛑 CHECKPOINT 2: "Preview at [URL]. OK to merge?" │
│ └── You verify preview works, say "OK to merge" │
├─────────────────────────────────────────────────────────────────┤
│ PHASE C: Staging │
│ 7. Merge PR to main │
│ 8. Wait for staging (~5 min) │
│ │
│ 🛑 CHECKPOINT 3: "Staging at [URL]. OK to deploy production?" │
│ └── You verify staging works, say "OK to deploy" │
├─────────────────────────────────────────────────────────────────┤
│ PHASE D: Production │
│ 9. Trigger production deployment │
│ 10. Wait for production (~2 min) │
│ │
│ 🛑 CHECKPOINT 4: "Production live. Confirm complete." │
│ └── You verify production, say "Complete" │
└─────────────────────────────────────────────────────────────────┘Quick Reference
| Checkpoint | AI Shows | You Verify | You Say |
|---|---|---|---|
| 1 | Code diff | Code is correct | "OK to push" |
| 2 | Preview URL | Feature works | "OK to merge" |
| 3 | Staging URL | No regressions | "OK to deploy" |
| 4 | Production URL | Live and working | "Complete" |
Step 1: Create Feature Branch
# Ensure you're on main and up to date
git checkout main
git pull origin main
# Create feature branch
git checkout -b feature/your-feature-nameBranch Naming Convention
| Type | Format | Example |
|---|---|---|
| Feature | feature/description | feature/add-dark-mode |
| Bug Fix | fix/description | fix/broken-link |
| Documentation | docs/description | docs/update-api-guide |
| Refactor | refactor/description | refactor/simplify-nav |
Step 2: Develop Locally
# Start dev server (hot reload)
npm run dev
# Open browser
open http://localhost:3000Test Your Changes
npm run lint # Run linting
npm run types:check # Type checking
npm run build # Verify buildStep 3: Commit and Push
# Stage changes
git add .
# Commit with descriptive message
git commit -m "feat: add deployment workflow documentation"
# Push to remote
git push origin feature/your-feature-nameCommit Message Format (Conventional Commits)
REQUIRED
All commits must follow Conventional Commits format. GitHub Actions will reject PRs with non-conforming commit messages.
<type>: <description>
[optional body]
[optional footer]Commit Types
| Type | Version Bump | Description | Example |
|---|---|---|---|
feat | Minor (0.X.0) | New feature | feat: add dark mode toggle |
fix | Patch (0.0.X) | Bug fix | fix: resolve broken link |
docs | Patch | Documentation | docs: update API guide |
style | Patch | Formatting | style: fix indentation |
refactor | Patch | Code restructuring | refactor: simplify auth flow |
perf | Patch | Performance | perf: optimize image loading |
test | Patch | Tests | test: add unit tests for auth |
build | Patch | Build system | build: update webpack config |
ci | Patch | CI/CD | ci: add deployment job |
chore | Patch | Maintenance | chore: update dependencies |
revert | Patch | Revert commit | revert: undo dark mode feature |
Breaking Changes
Add ! after the type or BREAKING CHANGE: in the footer:
# Method 1: Bang after type
feat!: redesign authentication API
# Method 2: Footer
feat: redesign authentication API
BREAKING CHANGE: API endpoints have changedBreaking changes trigger a Major version bump (X.0.0).
Examples
# Good commit messages
git commit -m "feat: add employee dashboard"
git commit -m "fix: resolve login timeout issue"
git commit -m "docs: update deployment guide"
git commit -m "refactor: simplify database queries"
# Bad commit messages (will be rejected)
git commit -m "update stuff" # Missing type
git commit -m "Feature: add login" # Wrong case (Feature vs feat)
git commit -m "feat add login" # Missing colonAutomatic Versioning
When commits are merged to main, semantic-release automatically:
- Analyzes commit messages since last release
- Determines version bump (major/minor/patch)
- Updates
package.jsonversion - Generates
CHANGELOG.md - Creates GitHub Release
Commits since last release:
- feat: add employee dashboard → minor bump
- fix: resolve login issue → patch bump
- docs: update guide → patch bump
Result: 1.2.0 → 1.3.0 (feat triggers minor)The version displays automatically on the homepage.
Step 4: Create Pull Request
# Create PR via CLI
gh pr create --title "feat: your feature" --body "Description"
# Or open in browser
gh pr create --webWhat Happens Automatically
- ✅ GitHub Actions runs tests
- ✅ Builds Docker image
- ✅ Deploys to Preview environment
- ✅ Comments on PR with preview URL
🚀 Preview deployed!
URL: https://hrms-docs-pr-42-xxxx.run.appStep 5: Review and Merge
- Review the preview URL
- Verify changes look correct
- Merge the PR:
gh pr merge --squashWhat Happens Automatically
- ✅ Preview environment is deleted
- ✅ Staging deploys automatically
- ⏸️ Production waits for manual trigger
Step 6: Deploy to Production (Manual)
After verifying staging, deploy to production:
Option A: Via GitHub Web UI
- Go to: Actions → Build and Deploy → Run workflow
- Check "Deploy to production"
- Click "Run workflow"
Option B: Via CLI
gh workflow run deploy.yml -f deploy_production=trueVerify Production
curl -sI https://docs.hrms.bluewoo.com | head -5
open https://docs.hrms.bluewoo.comStep 7: Cleanup
# Switch back to main
git checkout main
git pull origin main
# Delete local branch
git branch -d feature/your-feature-nameIntegration with AI Coding Sessions
When working with AI agents (Claude Code, Cursor), integrate with this workflow:
Session Start
1. Read PROJECT_STATE.md (current phase/step)
2. Read WHAT_EXISTS.md (built components)
3. Create branch: git checkout -b feature/phase-X-step-Y
4. State understanding: "I'm on Phase X, Step Y. I will do Z."
5. WAIT for approvalDuring Session
1. Make changes
2. Commit frequently with clear messages
3. Push to feature branch
4. Create PR when step is completeSession End
1. Verify preview looks correct
2. Merge PR → Staging deploys
3. If phase complete: trigger production deploy
4. Update PROJECT_STATE.md
5. Commit state file updatesRollback
Quick Rollback via Cloud Run
# List recent revisions
gcloud run revisions list --service=hrms-docs --region=europe-west6 --limit=5
# Rollback to previous revision
gcloud run services update-traffic hrms-docs \
--to-revisions=hrms-docs-PREVIOUS_REVISION=100 \
--region=europe-west6Revert via Git
git revert HEAD
git push origin main
# Then manually trigger production deployComplete Example
# 1. Start fresh
git checkout main && git pull
# 2. Create branch
git checkout -b docs/add-employee-guide
# 3. Develop
npm run dev
# ... make changes ...
# 4. Test
npm run lint && npm run build
# 5. Commit and push
git add .
git commit -m "docs: add employee management guide"
git push origin docs/add-employee-guide
# 6. Create PR
gh pr create --title "docs: add employee management guide"
# 7. Wait for preview, review it
# 8. Merge
gh pr merge --squash
# 9. Verify staging
open https://hrms-docs-staging-446839292792.europe-west6.run.app
# 10. Deploy to production (when ready)
gh workflow run deploy.yml -f deploy_production=true
# 11. Verify production
open https://docs.hrms.bluewoo.com
# 12. Cleanup
git checkout main && git pull
git branch -d docs/add-employee-guideQuick Reference
Commands Cheat Sheet
| Action | Command |
|---|---|
| Create branch | git checkout -b feature/name |
| Push branch | git push origin feature/name |
| Create PR | gh pr create |
| Check PR status | gh pr status |
| Merge PR | gh pr merge --squash |
| Deploy to prod | gh workflow run deploy.yml -f deploy_production=true |
| Check deployment | gh run list --limit 1 |
| View logs | gh run view --log |
| Rollback | gcloud run services update-traffic ... |
Environment URLs
| Environment | URL |
|---|---|
| Local | http://localhost:3000 |
| Preview | (check PR comment) |
| Staging | https://hrms-docs-staging-446839292792.europe-west6.run.app |
| Production | https://docs.hrms.bluewoo.com |
Best Practices
- Keep PRs small - Easier to review, less risk
- Test locally first - Don't rely solely on CI
- Write clear commit messages - Future you will thank you
- Review preview before merging - Catch issues early
- Verify staging before production - Last chance to catch issues
- Delete branches after merge - Keep repo clean
This workflow applies to hrms-docs and will be the template for HRMS app development.