menu
save_alt Unduh

Change Management Policy

Change management procedures for code and infrastructure

< 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

  1. Create Branch
    • Branch from main
    • Use descriptive names (e.g. fix/login-bug, feature/sql-editor-syntax)
  2. Open PR
    • Target: main or release candidate branch
    • Include clear description of change, motivation, and any relevant issue links
  3. 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
  4. Merge
    • After approval and CI passes
    • Merge commit preferred
  5. 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