Configuration Management & Change Control: Baselines, Versioning & Impact Analysis

Core Concepts: What is Configuration Management?

Definition & Purpose

Software Configuration Management (SCM) is the disciplined control of modifications to software artifacts (source code, documentation, databases, binaries) to ensure:

• Traceability: Linking changes to requirements, defects, or features.
• Consistency: All team members work on the same stable baseline.
• Accountability: Tracking who made what change when and why.

stateDiagram-v2
    [*] --> Idle: No active changes
    Idle --> Baseline: Freeze version (e.g., v1.0)
    Baseline --> Development: Team works on branches
    Development --> Integration: Merge changes
    Integration --> Testing: Validate against baseline
    Testing --> Release: Deploy to production
    Release --> [*]: End of lifecycle (or loop back for updates)

Why is SCM critical?

• Avoids "works on my machine" chaos: Ensures reproducibility.
• Supports compliance: Audit trails for regulatory bodies (e.g., NEPSE’s trading software).
• Reduces risk: Prevents unintended side effects from uncontrolled changes.

Key Components of SCM

1. Configuration Items (CIs)

Any deliverable that needs version control:

• Source code (.java, .py, .sql)
• Documentation (requirements, design specs, user manuals)
• Executables (compiled binaries, JAR files)
• Databases (schema scripts, seed data)
• Configuration files (.env, Dockerfile, webpack.config.js)

2. Baselines

A snapshot of approved CIs at a point in time. Baselines act as:

• Reference points for future changes (e.g., "v2.0 baseline" before adding a new feature).
• Gatekeepers for quality checks (e.g., code reviews before merging to main).

Example: eSewa’s payment API baseline (v3.2) is frozen before the monsoon season to avoid disruptions during high transaction volumes.

Change Control Process: How Changes Happen

Step-by-Step Workflow

1. Request Change: Developer submits a Change Request (CR) via a ticket (e.g., Jira, Trello).
2. Impact Analysis: Assess risks (e.g., "Will this break the Daraz order queue?").
3. Approval: Stakeholders (PM, QA, Dev Lead) sign off.
4. Implementation: Code/docs are modified in a branch (e.g., feature/payment-gateway).
5. Testing: Changes are validated against the baseline.
6. Integration: Merged into the main branch (e.g., main or develop).
7. Release: Deployed to production with a new version tag (e.g., v3.3).

sequenceDiagram
    Developer->>Jira: Submit CR #123 (Fix login bug)
    Jira->>PM: Approve/Reject
    PM->>QA: Test in staging
    QA->>Git: Merge to main
    Git->>CI/CD: Trigger build
    CI/CD->>Production: Deploy v3.3

Change Control Board (CCB)

A formal group (PM, Tech Lead, QA, Business Analyst) that:

• Reviews CRs for technical feasibility and business impact.
• Prioritizes changes using criteria like:
  • Urgency (e.g., security patch for a bank’s online banking).
  • Cost (e.g., Daraz’s discount feature vs. a minor UI tweak).
  • Risk (e.g., changing NTC’s billing system during peak hours).

Real Example:

Pathao’s Ride-Hailing System

• Change: Add "surge pricing" during traffic jams in Kathmandu.
• Impact Analysis:
  • Pros: Higher driver earnings, faster matches for users.
  • Cons: Potential backlash if prices spike too much.
  • Solution: CCB approved a gradual rollout with driver incentives.

Version Control Systems (VCS)

Tools to track changes and collaborate:

Branching Strategies

Configuration Management Responsibilities

Tools for SCM & Change Control

In the Real World

1. eSewa: Payment System Baselines

• Problem: eSewa processes 50,000+ transactions/hour during festivals.
• SCM Solution:
  • Baseline: Freezes the payment API (v4.2) 2 weeks before Dashain.
  • Change Control: Only critical security patches (e.g., PCI compliance fixes) are allowed.
  • Rollback Plan: If a change breaks transactions, revert to v4.1 instantly.

2. Daraz: Order Queue Management

• Problem: During sales (e.g., 11.11), Daraz’s order queue grows exponentially.
• SCM Solution:
  • Versioned Microservices: Each service (inventory, checkout, shipping) has its own Git repo.
  • Feature Flags: New features (e.g., "one-click checkout") are hidden until fully tested.
  • Impact Analysis: Before deploying, the CCB checks if the change affects the order timeout threshold (currently 30 seconds).

3. NTC: Billing System Updates

• Problem: NTC’s billing system must comply with Nepal’s Electricity Act 2019.
• SCM Solution:
  • Baseline: v2.5 is locked until all compliance changes are tested.
  • Audit Trail: Every change to the billing algorithm is logged (e.g., "Adjusted surcharge for industrial users").
  • Rollback: If a new tax rule causes errors, revert to the previous baseline.

Worked Example: Kathmandu Traffic Route Optimization

Scenario: The Kathmandu Metropolitan City (KMC) wants to optimize traffic routes using a real-time traffic management system. The software has two versions:

• v1.0: Static routes (no AI).
• v2.0: Dynamic routes (uses ML to reroute during accidents).

Change Request (CR):

"Add real-time accident detection using camera feeds."

Steps:

1. Impact Analysis:

   • Pros: Reduces congestion by 15% (per KMC’s pilot study).
   • Cons: Requires new APIs with Ncell’s emergency services.
   • Risk: If the ML model fails, routes may worsen traffic.

2. Baseline Decision:

   • Freeze v1.0 as the fallback baseline.
   • Develop v2.0 in a separate branch (feature/accident-detection).

3. Testing:

   • Simulate 500 accidents in a staging environment (mirror of Kathmandu’s roads).
   • Validate that reroutes don’t increase travel time by >10%.

4. Deployment:

   • Roll out v2.0 in phases:
     • Phase 1: Thamel (high traffic).
     • Phase 2: Full city (after 2 weeks of monitoring).

Visualization:

graph TD
    A["Current Baseline: v1.0"] -->|"CR Approved"| B["Dev Branch: feature/accident-detection"]
    B --> C["Test in Staging: Simulated Accidents"]
    C -->|"Passes QA"| D["Merge to v2.0"]
    D --> E["Deploy to Thamel"]
    E --> F["Monitor for 2 Weeks"]
    F --> G["Deploy to Full City"]
    G --> H["New Baseline: v2.1"]

Common Pitfalls & How to Avoid Them

Exam Tip

What Examiners Want to See

1. Definitions with Examples:

   • "Baseline" → Not just a definition, but how eSewa uses it for payment stability.
   • "Change Control Board" → Describe who sits on it (PM, QA, Dev Lead) and how Pathao prioritizes changes.

2. Process Diagrams:

   • Draw a sequence diagram for a CR workflow (like the one above).
   • Show a state diagram for version transitions (e.g., Dev → Test → Release).

3. Real-World Applications:

   • Link Git branching to Daraz’s feature flags.
   • Explain why NTC needs strict baselines (regulatory compliance).

4. Pros/Cons Tables:

   • Compare Git vs. SVN for a Nepalese bank’s software.
   • List advantages/disadvantages of trunk-based vs. Git Flow.

5. Worked Examples:

   • Must include:
     • A problem statement (e.g., "Kathmandu traffic jams").
     • Impact analysis (risks vs. benefits).
     • Step-by-step solution (branching, testing, rollback).

Common Mistakes to Avoid

• ❌ Describing SCM as just "using Git" (it’s broader: baselines, CCB, audits).
• ❌ Ignoring non-code artifacts (docs, databases, configs).
• ❌ Forgetting rollback plans (examiners love this detail!).
• ❌ Generic answers (e.g., "SCM is important" → how?).

Quick Revision Checklist

• Can you define baseline, configuration item, and change request with examples?
• Can you draw a sequence diagram for a CR workflow?
• Can you explain how Daraz uses feature flags for controlled releases?
• Can you list 3 tools for version control and 1 tool for CI/CD?
• Can you describe how NTC’s billing system uses SCM for compliance?