Monday.com Development Workflow
Overview
This document describes how our development workflow integrates with Monday.com for task tracking, from ideation to production deployment.
Branch Strategy
The Release Train Model
We follow a release train model where code flows through branches in a predictable sequence. Once code is merged to development, it will automatically be included in the next release to staging, and from there to production.
Key Principles
1. All PRs target development (default)
- Every feature branch creates a PR against
development - This is the default branch for the repository
- No exceptions for normal feature work
2. No cherry-picking into staging
- We do NOT cherry-pick individual commits from development to main
- When development is merged to main (staging), ALL changes go together
- This keeps branches in sync and prevents merge conflicts
3. Release train cadence (usually weekly)
- Development is merged to main (staging) on a regular cadence
- Once merged, QA tests the full release on staging
- After QA approval, staging goes to production
4. Once you're on the train, you're going to production
- If your PR is merged to development before the release, it will be included
- There's no way to "skip" a release once merged to development
- Plan accordingly - if something isn't ready, don't merge it
How the Train Works
Branch Responsibilities
| Branch | Purpose | Owner | Testing |
|---|---|---|---|
| development | Active development, default for all PRs | Developers | Developer testing |
| main | Staging environment | QA (Stephanie) | Full QA testing |
| production | Live application | DevOps | Production monitoring |
Developer Workflow
- All new PRs target the development branch (default)
- Developers are responsible for ensuring code quality before merging to main
- Stephanie tests on staging (main) - only requests help on development when needed
- Code must be in good state by the time it reaches main
Hotfix Process
Sometimes bugs need to be fixed faster than the normal weekly train. Think of it like this: the train runs on a schedule, but sometimes you need to take a taxi instead.
When to Use a Hotfix
| Situation | Use Hotfix? | Example |
|---|---|---|
| Bug affects revenue | Yes | Payment processing broken |
| Bug blocks all users | Yes | App won't load |
| Bug affects one customer | Maybe | Depends on severity |
| Bug is annoying but not blocking | No | UI glitch, wait for train |
| Feature request | Never | Always use the train |
Hotfix Levels
We have three levels, depending on urgency:
Standard Hotfix (Can Wait for Staging Test)
When: Bug is important but you have time to test on staging first.
Monday.com Flow:
- Create task in Monday (or use existing bug report)
- Mark as High Priority
- Developer fixes on development branch
- Cherry-pick to staging → Ready for Testing
- QA tests on staging
- Cherry-pick to production → Done
Timeline: Same day or next day
Urgent Hotfix (Skip Development, Go to Staging)
When: Bug is critical. You need to skip development but still want QA to test.
Monday.com Flow:
- Create task marked Urgent with 🔥 emoji in title
- Developer creates PR directly to main (staging)
- Notify QA immediately (Slack/call)
- QA tests on staging → fast approval
- Deploy to production → Done
- Developer back-merges to development
Timeline: Within hours
Emergency Hotfix (Production is Down)
When: Production is broken. Every minute costs money or users.
Monday.com Flow:
- Create task marked EMERGENCY 🚨
- Notify team lead immediately
- Developer creates PR directly to production
- Deploy immediately (no staging test)
- Verify fix in production
- Back-merge to staging and development
- QA does post-deployment verification
Timeline: Within minutes
Emergency hotfixes skip QA testing. Only use when production is critically broken and users are affected RIGHT NOW.
Hotfix Communication
| Level | Who to Notify | How |
|---|---|---|
| Standard | Team in standup | Monday.com comment |
| Urgent | QA + Team Lead | Slack message |
| Emergency | Everyone | Slack + Phone call |
After Any Hotfix
- Update Monday task with what was fixed and when
- Add post-mortem notes if it was an emergency
- Verify branches are synced (developer responsibility)
- Consider: Could this have been caught earlier?
For technical git commands, see Git Workflow - Hotfix Process.
Monday.com Groups
Product-Related Groups
These groups manage the product ideation and planning lifecycle:
- Inbox - New items to be triaged
- Brainstorming - Ideas being explored
- Missing Info - Items needing clarification
- On Hold - Paused items
Development Groups
Tasks move through these groups as they progress through development:
Development States
1. Ready to be Tackled
Description: Task has been verified, groomed, and is ready for development.
Entry Criteria:
- Requirements are clear
- Acceptance criteria defined
- No blockers identified
Exit: Developer picks up the task
2. Assigned (Optional)
Description: Task is assigned to a specific developer to help organize the process.
Notes:
- Assignments are suggestions, not mandatory
- Developers can reassign if someone else is better equipped
- Developers can pick up unassigned tasks
3. In Progress
Description: Developer is actively working on the task.
Entry: Developer picks up the task and starts work
Automation: Task automatically moves to the "In Progress" group
Exit: Pull Request is created
4. Code Review
Description: A Pull Request has been created and is awaiting review.
Entry: PR created with Monday task link in description
Automation:
- Task automatically moves to "Code Review" group
- Monday task receives notification with PR details
Exit: PR is approved and merged to development
5. Merged to Development (Dev Testing)
Description: PR has been merged to the development branch. Developer performs final testing before promoting to staging.
Entry: PR merged to development branch
What happens:
- Code is deployed to development environment
- Developer verifies the feature works as expected
- Developer ensures no regressions
Exit: Developer pushes/merges changes to main branch
6. Ready for Testing (Staging)
Description: Code has been pushed to main branch and deployed to staging.
Entry: Changes merged/pushed to main
Automation:
- Task automatically moves from "Dev" to "Stage"
- Status set to "Ready for Testing"
Owner: QA (Stephanie)
Exit: QA approves or requests changes
7. Ready for Production
Description: QA has approved the feature and it's ready for production deployment.
Entry: Stephanie marks task as approved
Exit: Deployed to production
8. Done
Description: Feature is live in production.
Entry: Deployed to production branch
Changes Required
Description: QA found issues during testing that need to be addressed.
Entry: Stephanie identifies issues during staging testing
Automation: Task moves to "Changes Required" group
Exit: Developer fixes issues and creates new PR
Complete Workflow Diagram
Automations
Monday.com automations handle the following transitions automatically:
GitHub-Triggered Automations
| Trigger | Action | Details |
|---|---|---|
| PR Created | Set status to "Code Review" | Task/subtask linked in PR gets status updated |
| PR Merged to development | Set status to "Deployed to Dev" | Task/subtask ready for dev testing |
| Commits pushed | Post notification | Commit details posted to linked Monday task |
Status-Triggered Automations
| Status Change | Action |
|---|---|
| In Progress | Move task to "In Progress" group |
| Code Review | Move task to "Code Review" group |
| Changes Required | Move task to "Changes Required" group |
For Developers
Daily Workflow
- Pick a task from "Ready to be Tackled" (follow priority order)
- Move to In Progress when you start working
- Create PR with Monday task link in description (targets development branch)
- Code Review happens automatically when PR is created
- PR Merged to development - test your changes on dev environment
- Push to main once verified - task moves to "Ready for Testing" on staging
- If changes requested by QA - fix and create new PR
PR Requirements
Every PR must include the Monday task URL in the description:
https://pivotapp.monday.com/boards/[board_id]/pulses/[task_id]
This enables automatic tracking and status updates.
For QA (Stephanie)
Testing Workflow
- Monitor "Ready for Testing" group for new items
- Test on staging (main branch deployment)
- Approve → Mark as "Ready for Production"
- Request Changes → Move to "Changes Required" with notes
When to Test on Development
Only request developer help on development branch when:
- Complex feature needs early feedback
- Unable to reproduce issue on staging
- Urgent pre-staging validation needed
Related Documentation
- Git Workflow - Technical details on fast-forward, rebase, and merge strategies
- Monday-GitHub Integration - How commits and PRs link to Monday
- Monday-GitHub Integration Implementation - Technical implementation details