Change Management Policy¶

Overview¶

This document defines the change management process for HeliosDB-Lite, ensuring controlled, documented, and auditable changes to code, configuration, and infrastructure.

Change Categories¶

Standard Changes¶

Pre-approved, low-risk changes that follow documented procedures.

Change Type	Example	Approval	Lead Time
Dependency update (patch)	1.2.3 → 1.2.4	Automated	Immediate
Documentation update	README changes	1 reviewer	< 1 day
Bug fix (non-security)	Minor fixes	1 reviewer	< 1 day
Test additions	New test coverage	1 reviewer	< 1 day

Normal Changes¶

Routine changes requiring standard review and approval.

Change Type	Example	Approval	Lead Time
Feature implementation	New functionality	2 reviewers	2-5 days
Dependency update (minor)	1.2.x → 1.3.0	1 reviewer + CI	1-2 days
Configuration change	New settings	1 reviewer	1 day
Performance optimization	Code improvements	2 reviewers	2-3 days

Significant Changes¶

High-impact changes requiring extensive review.

Change Type	Example	Approval	Lead Time
Breaking API change	Protocol changes	3 reviewers + arch	1-2 weeks
Security-related change	Crypto updates	Security team	1 week
Dependency update (major)	1.x → 2.0	2 reviewers + test	3-5 days
Architecture change	Module restructure	Architecture review	2-4 weeks

Emergency Changes¶

Urgent changes to address critical issues.

Change Type	Example	Approval	Lead Time
Security patch	CVE remediation	Security lead	< 24 hours
Critical bug fix	Data corruption	2 reviewers	< 24 hours
Incident response	Active attack	Incident commander	Immediate

Change Request Process¶

1. Request Initiation¶

## Change Request

**Title**: [Brief description]
**Category**: [Standard/Normal/Significant/Emergency]
**Requestor**: [Name]
**Date**: [YYYY-MM-DD]

### Description
[Detailed description of the proposed change]

### Justification
[Why is this change needed?]

### Impact Assessment
- Affected components: [List]
- Risk level: [Low/Medium/High]
- Rollback plan: [Description]

### Testing Plan
[How will the change be tested?]

### Implementation Plan
[Step-by-step implementation]

2. Review & Approval¶

Category	Reviewers Required	Approval Authority
Standard	1 peer	Automated/Self
Normal	2 peers	Team lead
Significant	3 peers + specialist	Architecture team
Emergency	1 peer + lead	Security/Ops lead

3. Implementation¶

# Feature branch workflow
git checkout -b feature/change-description
git commit -m "feat: description"
git push origin feature/change-description

# Create pull request
gh pr create --title "feat: description" --body "$(cat change_request.md)"

4. Verification¶

Automated tests pass (CI)
Manual review completed
Security scan clean
Documentation updated
Changelog updated

5. Deployment¶

# Merge to main
gh pr merge --squash

# Create release (for tagged releases)
git tag -a v3.5.9 -m "Release v3.5.9"
git push origin v3.5.9

CI/CD Pipeline Controls¶

Automated Checks¶

# .github/workflows/ci.yml
name: CI

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build
        run: cargo build --all-features

      - name: Test
        run: cargo test --all-features

      - name: Clippy
        run: cargo clippy -- -D warnings

      - name: Security Audit
        run: cargo audit

      - name: License Check
        run: cargo deny check licenses

Branch Protection¶

# Required for main branch
branch_protection:
  required_reviews: 2
  dismiss_stale_reviews: true
  require_code_owner_review: true
  required_status_checks:
    - build
    - test
    - clippy
    - security-audit
  enforce_admins: true
  allow_force_pushes: false
  allow_deletions: false

Security-Sensitive Paths¶

Changes to these paths require security team review:

CODEOWNERS:
/src/crypto/          @security-team
/src/auth/            @security-team
/Cargo.toml           @security-team
/docs/compliance/     @security-team
/.github/workflows/   @devops-team @security-team

Release Process¶

Version Numbering¶

Semantic Versioning (SemVer): - MAJOR: Breaking changes (X.0.0) - MINOR: New features, backward compatible (0.X.0) - PATCH: Bug fixes, backward compatible (0.0.X)

Release Checklist¶

[ ] All tests passing
[ ] Security audit clean
[ ] CHANGELOG.md updated
[ ] Version bumped in Cargo.toml
[ ] Documentation updated
[ ] Release notes drafted
[ ] Tag created and pushed
[ ] Binaries built and published
[ ] Announcement prepared

Hotfix Process¶

# Create hotfix branch from latest release
git checkout -b hotfix/3.5.8 v3.5.8

# Apply fix
git cherry-pick <fix-commit>

# Update version
# Edit Cargo.toml: 3.5.8 → 3.5.9

# Tag and release
git tag -a v3.5.9 -m "Hotfix: description"
git push origin v3.5.9

# Merge back to main
git checkout main
git merge hotfix/3.5.8

Rollback Procedures¶

Code Rollback¶

# Revert specific commit
git revert <commit-hash>

# Rollback to previous version
git checkout v3.5.7
cargo build --release

Database Rollback¶

-- HeliosDB branch-based rollback
CHECKOUT BRANCH 'pre_change_branch';

-- Or time-travel query
SELECT * FROM users AS OF '2026-01-23T12:00:00Z';

Configuration Rollback¶

# Restore previous configuration
cp /etc/heliosdb/heliosdb.toml.backup /etc/heliosdb/heliosdb.toml
systemctl restart heliosdb

Audit Trail¶

Change Log Format¶

{
  "change_id": "CHG-2026-0001",
  "timestamp": "2026-01-24T12:00:00Z",
  "type": "normal",
  "description": "Add FIPS 140-3 support",
  "requestor": "developer@heliosdb.io",
  "approvers": ["reviewer1@heliosdb.io", "reviewer2@heliosdb.io"],
  "commit": "abc123",
  "pr_number": 456,
  "files_changed": 15,
  "lines_added": 500,
  "lines_removed": 100,
  "test_results": "passed",
  "security_review": "approved"
}

Retention¶

Record Type	Retention Period
Change requests	3 years
Approval records	3 years
Deployment logs	1 year
Rollback events	3 years