< Back
Purpose
Ensure changes to our codebases are controlled, reviewed, tested, and auditable across both desktop and cloud products.
1. Scope
This process applies to:
-
Desktop Application (Electron, built from GitHub tags)
-
Cloud Service (Rails app on Heroku, also built from tags)
- All environments: development, staging, production
2. Source Control
- All code is version-controlled in GitHub repositories.
- Changes are made via Pull Requests (PRs) on feature branches.
- Direct commits to
main are prohibited.
3. Change Workflow
-
Create Branch
- Branch from
main
- Use descriptive names (e.g.
fix/login-bug, feature/sql-editor-syntax)
-
Open PR
- Target:
main or release candidate branch
- Include clear description of change, motivation, and any relevant issue links
-
Code Review
- All PRs require at least one approval from another team member
- Reviewer ensures:
- Tests pass
- No security regressions
- Code follows standards
- Optional: include screenshots or recordings for UI changes
-
Merge
- After approval and CI passes
- Merge commit preferred
-
Tag
-
Desktop app: Tag merged commit with version (e.g.
v3.1.0)
-
Cloud service: Tag for deploy (e.g.
v3.1.0)
4. Build & Release
4.1 Desktop App
- Tagged builds trigger packaging and signing via CI
- Final binaries are uploaded to GitHub Releases and other distribution channels
4.2 Cloud Service
- Tagged commits are deployed to Heroku (via CI/CD or manual process)
- Environment variables and secrets are managed via Heroku config vars
5. Emergency Fixes
- Create
hotfix/* branch from the latest tag
- PR directly into
main
- Follow standard review and tagging process
- Merge back into feature branches if necessary
6. Audit & Logging
- GitHub PRs and tags serve as the change log
- Heroku logs all deployments
- Backup procedures and monitoring are handled via existing infra policies
7. Review
- This process is reviewed quarterly or after any significant tooling or infra change