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

Normal Changes

Routine changes requiring standard review and approval.

Change Type	Example	Approval	Lead Time
Feature implementation	New functionality	2 reviewers	2-5 days
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 vX.Y.Z -m "Release vX.Y.Z"
git push origin vX.Y.Z

CI/CD Pipeline Controls

Automated Checks

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: static analysis
        run: static analysis checks -- -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
    - static analysis
    - security-audit
  enforce_admins: true
  allow_force_pushes: false
  allow_deletions: false

Security-Sensitive Paths

Changes to cryptography, authentication, the dependency manifest, compliance documents and CI workflows require security team review (enforced with code-owner rules).

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

Hotfix Process

# Create hotfix branch from latest release
git checkout -b hotfix/X.Y.Z vX.Y.Z

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

# Update version
# Bump the patch version: X.Y.Z → X.Y.(Z+1)

# Tag and release
git tag -a vX.Y.(Z+1) -m "Hotfix: description"
git push origin vX.Y.(Z+1)

# Merge back to main
git checkout main
git merge hotfix/X.Y.Z

Rollback Procedures

Code Rollback

# Revert specific commit
git revert <commit-hash>

# Rollback to previous version
git checkout <previous-release-tag>
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@example.com",
  "approvers": ["reviewer1@example.com", "reviewer2@example.com"],
  "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