Bluewoo HRMS
Deployment

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
EnvironmentTriggerURLPurpose
LocalManuallocalhost:3000Development
PreviewCreate PRhrms-docs-pr-{n}-xxx.run.appPR Review
StagingMerge to mainhrms-docs-staging-xxx.run.appUAT/QA
ProductionManual triggerdocs.hrms.bluewoo.comLive

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

CheckpointAI ShowsYou VerifyYou Say
1Code diffCode is correct"OK to push"
2Preview URLFeature works"OK to merge"
3Staging URLNo regressions"OK to deploy"
4Production URLLive 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-name

Branch Naming Convention

TypeFormatExample
Featurefeature/descriptionfeature/add-dark-mode
Bug Fixfix/descriptionfix/broken-link
Documentationdocs/descriptiondocs/update-api-guide
Refactorrefactor/descriptionrefactor/simplify-nav

Step 2: Develop Locally

# Start dev server (hot reload)
npm run dev

# Open browser
open http://localhost:3000

Test Your Changes

npm run lint        # Run linting
npm run types:check # Type checking
npm run build       # Verify build

Step 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-name

Commit 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

TypeVersion BumpDescriptionExample
featMinor (0.X.0)New featurefeat: add dark mode toggle
fixPatch (0.0.X)Bug fixfix: resolve broken link
docsPatchDocumentationdocs: update API guide
stylePatchFormattingstyle: fix indentation
refactorPatchCode restructuringrefactor: simplify auth flow
perfPatchPerformanceperf: optimize image loading
testPatchTeststest: add unit tests for auth
buildPatchBuild systembuild: update webpack config
ciPatchCI/CDci: add deployment job
chorePatchMaintenancechore: update dependencies
revertPatchRevert commitrevert: 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 changed

Breaking 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 colon

Automatic Versioning

When commits are merged to main, semantic-release automatically:

  1. Analyzes commit messages since last release
  2. Determines version bump (major/minor/patch)
  3. Updates package.json version
  4. Generates CHANGELOG.md
  5. 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 --web

What Happens Automatically

  1. ✅ GitHub Actions runs tests
  2. ✅ Builds Docker image
  3. ✅ Deploys to Preview environment
  4. ✅ Comments on PR with preview URL
🚀 Preview deployed!
URL: https://hrms-docs-pr-42-xxxx.run.app

Step 5: Review and Merge

  1. Review the preview URL
  2. Verify changes look correct
  3. Merge the PR:
gh pr merge --squash

What Happens Automatically

  1. ✅ Preview environment is deleted
  2. Staging deploys automatically
  3. ⏸️ Production waits for manual trigger

Step 6: Deploy to Production (Manual)

After verifying staging, deploy to production:

Option A: Via GitHub Web UI

  1. Go to: ActionsBuild and DeployRun workflow
  2. Check "Deploy to production"
  3. Click "Run workflow"

Option B: Via CLI

gh workflow run deploy.yml -f deploy_production=true

Verify Production

curl -sI https://docs.hrms.bluewoo.com | head -5
open https://docs.hrms.bluewoo.com

Step 7: Cleanup

# Switch back to main
git checkout main
git pull origin main

# Delete local branch
git branch -d feature/your-feature-name

Integration 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 approval

During Session

1. Make changes
2. Commit frequently with clear messages
3. Push to feature branch
4. Create PR when step is complete

Session 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 updates

Rollback

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

Revert via Git

git revert HEAD
git push origin main
# Then manually trigger production deploy

Complete 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-guide

Quick Reference

Commands Cheat Sheet

ActionCommand
Create branchgit checkout -b feature/name
Push branchgit push origin feature/name
Create PRgh pr create
Check PR statusgh pr status
Merge PRgh pr merge --squash
Deploy to prodgh workflow run deploy.yml -f deploy_production=true
Check deploymentgh run list --limit 1
View logsgh run view --log
Rollbackgcloud run services update-traffic ...

Environment URLs


Best Practices

  1. Keep PRs small - Easier to review, less risk
  2. Test locally first - Don't rely solely on CI
  3. Write clear commit messages - Future you will thank you
  4. Review preview before merging - Catch issues early
  5. Verify staging before production - Last chance to catch issues
  6. Delete branches after merge - Keep repo clean

This workflow applies to hrms-docs and will be the template for HRMS app development.