• Home
  • BVSSH
  • Engineering Enablement
  • Playbooks
  • Frameworks
  • Good Reads
Search

What are you looking for?

Standard : Infrastructure changes are peer reviewed and version controlled

Purpose and Strategic Importance

This standard ensures that all infrastructure changes — including infrastructure-as-code, configuration updates, and environment changes — are made through version-controlled systems and are subject to mandatory peer review. This improves system reliability, increases traceability, and reduces the risk of human error.

Aligned to our "Architect for Change" and "Secure by Design" policies, this standard promotes safer, auditable, and higher-quality infrastructure operations. Without it, changes become risky, undocumented, and harder to diagnose or recover from when failures occur.

Strategic Impact

Clearly defined impacts of meeting this standard include greater system resilience, reduced change-related outages, improved auditability for compliance, and stronger cross-team collaboration and learning.

Risks of Not Having This Standard

  • Untracked and unverified infrastructure changes leading to service outages
  • Increased difficulty diagnosing and recovering from incidents
  • Higher risk of security vulnerabilities due to unauthorized changes
  • Lack of audit trail for compliance and governance requirements
  • Knowledge silos and reduced team collaboration

CMMI Maturity Model

Level 1 – Initial

  • People & Culture

    • Infrastructure changes are made manually without formal oversight.
    • No peer review practices or expectations for environment changes.
  • Process & Governance

    • Changes are applied directly to systems with little or no documentation.
  • Technology & Tools

    • No use of version control for infrastructure artifacts.
    • Change records, if any, are ad-hoc or offline.
  • Measurement & Metrics

    • No measurement of change volumes, failures, or recovery efforts.

Level 2 – Managed

  • People & Culture

    • Teams recognize the need for change control but apply it inconsistently.
  • Process & Governance

    • Some critical changes are logged manually or communicated informally.
    • Partial documentation practices for major updates.
  • Technology & Tools

    • Basic use of scripts or infrastructure-as-code, but without standardization.
    • Version control may exist but is not enforced.
  • Measurement & Metrics

    • Informal tracking of major incidents linked to change activities.

Level 3 – Defined

  • People & Culture

    • Peer review of infrastructure changes becomes a standard team expectation.
    • Engineers value change traceability and quality assurance.
  • Process & Governance

    • All infrastructure changes require peer-reviewed pull requests before merging.
    • Only approved, version-controlled artifacts are applied to environments.
  • Technology & Tools

    • Infrastructure-as-code (IaC) is maintained in repositories (e.g., Git).
    • Automated tests or validations are included as part of infrastructure pipelines.
  • Measurement & Metrics

    • Change approval rates, rollback rates, and error rates are tracked.

Level 4 – Quantitatively Managed

  • People & Culture

    • Teams reflect on peer review effectiveness and adjust practices for quality.
    • Infrastructure knowledge sharing improves through review discussions.
  • Process & Governance

    • Infrastructure changes include automated checks (e.g., policy as code, compliance scans).
    • Risk scoring or change impact assessments guide review intensity.
  • Technology & Tools

    • Automated change pipelines enforce validations and guardrails.
    • Audit trails are automatically generated from version control events.
  • Measurement & Metrics

    • Time-to-approve vs. time-to-deploy metrics are tracked and optimised.
    • Change-induced incident rates are continuously monitored.

Level 5 – Optimising

  • People & Culture

    • Infrastructure peer review is seen as a key opportunity for learning and improvement.
    • Teams continuously innovate infrastructure processes to enhance resilience and delivery speed.
  • Process & Governance

    • Dynamic policies adjust change control based on historical success and complexity.
    • Predictive insights inform risk-based review prioritisation.
  • Technology & Tools

    • Integrated toolchains detect anomalies in change patterns and recommend actions.
    • Continuous feedback loops refine infrastructure design and governance based on change data.
  • Measurement & Metrics

    • Year-over-year reduction in change-related incidents.
    • Increased percentage of successful, incident-free infrastructure deployments.

Key Measures

  • % of infrastructure changes peer reviewed before deployment
  • % of infrastructure changes tracked in version control
  • Average time from change proposal to deployment
  • Change-induced incident rate (measured pre- and post-standard adoption)
  • Compliance rate against infrastructure change policies
Associated Policies
  • Architect for Change
  • Secure by Design
Associated Practices
  • Policy as Code
Associated Measures
  • Infrastructure as Code (IaC) Coverage
  • Compliance Coverage
  • Percentage of Services Scanned
  • Time to Remediate Vulnerabilities

Technical debt is like junk food - easy now, painful later.

Awesome Blogs
  • LinkedIn Engineering
  • Github Engineering
  • Uber Engineering
  • Code as Craft
  • Medium.engineering