Change, Configuration and Version Management

Introduction

Software systems rarely remain unchanged after development begins. Requirements are clarified, defects are discovered, security risks emerge, technologies become obsolete, and users request new capabilities. Although change is necessary, uncontrolled change can produce conflicting files, broken builds, undocumented decisions, schedule overruns, and software that no longer matches its approved requirements.

Change, configuration and version management provide the discipline needed to control this evolution. Change management determines how proposed modifications are evaluated, approved, implemented and verified. Configuration management identifies the components that make up a product and maintains their integrity. Version management records the history of those components so that teams can collaborate, reproduce earlier states and release dependable software.

These practices are closely related but not identical. A change is a proposed alteration to an approved product or project plan. A configuration item is a controlled component, such as source code, a requirements document, a test script, an infrastructure definition or a release package. A version is a particular state of a configuration item. A baseline is an approved, stable reference point against which future changes are assessed.

Learning Objectives

By the end of this chapter, students should be able to:

1. Explain the relationship between change control, configuration management and version control.
2. Identify configuration items and establish appropriate baselines.
3. Design a practical change-control workflow with traceability and approval records.
4. Apply version-control concepts such as commits, branches, merges, tags and pull requests.
5. Describe build, release, configuration-audit and rollback practices.
6. Evaluate the risks, limitations and governance responsibilities associated with managing change.

1. The Nature of Change in Software Projects

Software is an evolving product rather than a static manufactured object. A change may affect requirements, architecture, source code, databases, test cases, user documentation, schedules, contracts or operational procedures. The impact is often indirect. For example, changing a customer identifier may require database migration, interface changes, validation updates, test redesign and data-protection review.

Common sources of change include:

• new or clarified stakeholder requirements;
• defects and failed tests;
• legal, regulatory or contractual obligations;
• security vulnerabilities;
• changes in external APIs or operating systems;
• performance or usability improvements;
• infrastructure and deployment changes; and
• lessons learned during operations.

Not every change has the same urgency or risk. A spelling correction in an internal document is different from an emergency security patch or a database-schema modification. Effective management therefore classifies changes according to impact, urgency, risk and authorization requirements.

Change, configuration and version management compared

These disciplines form a governance chain. A proposed change is assessed by change management, implemented through controlled configuration and version practices, verified through builds and tests, and delivered through release management.

2. Configuration Management Foundations

Configuration management is the systematic identification, control, accounting and auditing of software configurations throughout the product life cycle. It is not limited to source code. A reliable product configuration may include:

• business and system requirements;
• architecture and design models;
• source code and generated code;
• database schemas and migration scripts;
• test plans, test data and automated tests;
• build scripts and dependency manifests;
• infrastructure-as-code files;
• user, installation and operations documentation;
• security and compliance evidence; and
• binaries, containers and deployment packages.

Configuration items

A configuration item (CI) is a component placed under formal control because its identity, integrity or history matters. Teams should not automatically control every temporary file. They should identify items whose alteration could affect functionality, quality, compliance, reproducibility or contractual commitments.

Each CI should have an identifier, owner, status and location. A useful record may contain:

Configuration identification establishes naming conventions, item categories, repository locations and relationships. Without identification, a project may contain several files called “final design,” each with uncertain authority.

Baselines

A baseline is a formally reviewed and approved set of configuration items that serves as a reference for further work. Typical baselines include:

• requirements baseline;
• architectural or design baseline;
• test baseline;
• release baseline; and
• operational baseline.

A baseline is not necessarily permanent. It may be changed through an authorized process. Once established, direct informal editing should be prohibited. A proposed alteration should create a new version or change record, preserving the earlier state for comparison and recovery.

Baselines support scope control. They clarify what was approved at a particular point, provide a basis for measuring change, and make it possible to reproduce a released system. A baseline is meaningful only when its contents, approval authority, date and status are recorded.

3. Change-Control Workflow

A change-control workflow converts an informal request into a controlled decision. A practical workflow contains the following stages.

Stage 1: Submit and record

A requester creates a change request (CR). The record should state the requested change, reason, business value, urgency, affected product area and requester. Supporting evidence may include a defect report, customer requirement, security advisory or regulatory notice.

Stage 2: Screen and classify

A designated coordinator checks whether the request is sufficiently clear, duplicates an existing request or should be handled as an incident. The request can then be classified, for example, as standard, normal or emergency:

• Standard change: low-risk, repeatable and pre-authorized.
• Normal change: requires impact analysis and explicit approval.
• Emergency change: must be implemented quickly to reduce serious harm, with retrospective review.

Classification should not become a way to bypass controls. Emergency procedures may shorten approval routes, but they should still record the decision, implementation and later review.

Stage 3: Analyse impact

The team evaluates effects on scope, cost, schedule, architecture, security, privacy, performance, testing, operations and contractual obligations. It should identify dependencies and affected configuration items. The analysis should distinguish facts from assumptions and identify who performed the assessment.

A simple risk-priority approach can help structure discussion. If probability and impact are assigned ordinal scores from 1 to 5, a risk score may be recorded as:

Here, R is the recorded risk score, P is the probability score and I is the impact score. This is an ordinal screening aid, not a probability theorem or a precise financial prediction. It is applicable only when the organization defines consistent scoring criteria. A score of 12 does not mean that the risk is twelve times more dangerous than a score of 1.

Stage 4: Decide and authorize

An appropriate authority approves, rejects, defers or requests further analysis. Authority may belong to a project manager, product owner, technical lead, change control board or customer, depending on the change category. Approval should be based on evidence rather than the seniority of the requester.

The decision record should include the decision, approver, date, conditions, implementation window and any required compensating controls. Separation of duties is valuable for high-risk changes: the person who implements a production change should not be the sole person who authorizes it.

Stage 5: Plan and implement

The team updates tasks, estimates, affected baselines and test plans. Implementation should occur in a controlled branch or workspace. The change request should be linked to commits, pull requests, build results and test evidence.

Stage 6: Verify and review

Verification may include code review, automated tests, security scans, user acceptance testing, migration rehearsal and operational checks. The required evidence depends on risk. A change is not complete merely because code has been written.

Stage 7: Close and communicate

After successful implementation, the record is updated with actual results, release information, unresolved issues and lessons learned. Relevant stakeholders receive release notes or operational instructions. If the change failed, the team records the rollback or corrective action rather than quietly deleting evidence.

4. Traceability and Approval Records

Traceability is the ability to follow an item or decision through related project artifacts. A traceability chain might connect:

Requirement → Change request → Design decision → Commit → Build → Test result → Release → Incident record.

Traceability supports impact analysis, defect investigation, compliance demonstrations and accountability. It also reduces the risk that a requirement is implemented without testing or that a code change is released without approval.

A requirements traceability matrix can be represented as follows:

Traceability should be proportionate. Excessive documentation can slow delivery and encourage superficial recording. The goal is useful evidence, not paperwork for its own sake.

Approval records should be durable and attributable. A suitable record includes the identity of the approver, role, timestamp, decision, version reviewed and conditions. Shared accounts, undocumented verbal approvals and editable spreadsheets without history weaken accountability.

5. Version Control and Collaboration

Version-control systems store the history of files and support controlled collaboration. Modern distributed systems allow each developer to have a complete or substantial local repository, while a shared service provides collaboration, review and backup.

Important concepts include:

• Repository: managed store of project history and files.
• Commit: recorded set of changes with author, time and message.
• Hash or revision identifier: value used to identify a particular repository state.
• Branch: separate line of development.
• Merge: integration of changes from different lines of development.
• Conflict: situation in which changes cannot be combined automatically.
• Tag: stable name attached to a particular revision, commonly used for releases.
• Pull or merge request: proposed integration accompanied by review and automated checks.

A good commit is coherent, limited in scope and explained by a meaningful message. For example, “Add retry limit to payment client; refs CR-032” is more useful than “updates.” Commits should avoid mixing unrelated formatting, refactoring and business changes because such mixing makes review and rollback difficult.

Branching strategies

A branching strategy should reflect team size, release frequency, risk and automation capability.

Trunk-based development keeps changes close to a main branch. Short-lived branches and frequent integration reduce divergence, but require reliable automated tests and small changes.

Feature branching gives each feature an isolated branch. It supports focused review but can produce integration problems if branches remain separate for too long.

Release branching creates a stabilization branch for a planned release while new work continues elsewhere. This can help organizations with formal release cycles, but it increases maintenance overhead.

No branching model eliminates the need for communication and testing. Long-lived branches create merge debt: the effort and risk required to reconcile divergent histories.

Merge and review practices

Before merging, a change should normally have a clear purpose, linked work item, review by an appropriate colleague, successful automated checks and no unresolved high-severity findings. Reviewers should consider correctness, maintainability, security, performance, accessibility and compatibility—not merely coding style.

Protected main branches can require reviews, passing tests and signed or authenticated commits. These controls are useful only when exceptions are governed and emergency access is logged.

6. Builds, Releases and Reproducibility

A build transforms controlled inputs into outputs such as binaries, packages, containers or deployable infrastructure. A build should identify its source revision, dependency versions, tools, configuration and results. Reproducible builds aim to produce equivalent outputs when the same approved inputs are used, although absolute byte-for-byte identity may be difficult because of timestamps, compilers and external services.

Build pipelines commonly include:

1. source checkout;
2. dependency restoration;
3. compilation or packaging;
4. unit and integration testing;
5. static analysis and security checks;
6. artifact publication;
7. deployment to a controlled environment; and
8. acceptance or release approval.

A release is more than a version number. It is a tested combination of artifacts, configuration, data-migration instructions, release notes, approvals and deployment procedures. A release record should identify the source revision, artifact checksum where appropriate, environment assumptions, known limitations and rollback plan.

Semantic versioning is often useful when an API follows compatibility conventions. A version such as MAJOR.MINOR.PATCH communicates intended change categories: incompatible public-interface changes may increase MAJOR, backward-compatible functionality may increase MINOR, and backward-compatible fixes may increase PATCH. This convention is not universal law; organizations must define how it applies to their products.

Configuration must be separated from code where appropriate. Environment-specific values such as credentials, endpoints and feature flags should not be embedded in source code. Secrets require controlled storage, limited access, rotation and audit records.

7. Configuration Status Accounting and Audits

Configuration status accounting records and reports the identity, state and history of configuration items. Useful reports include:

• items in each baseline;
• changes approved, implemented and pending;
• versions currently deployed;
• test and approval status;
• open deviations and waivers; and
• relationships between releases and source revisions.

A configuration audit checks whether the product and its records agree with approved requirements and baselines. Two complementary forms are common:

• Functional configuration audit: asks whether the system performs the required functions and whether verification evidence exists.
• Physical configuration audit: asks whether the delivered components, versions, labels, documentation and packaging match the approved configuration.

Audits should sample evidence, interview responsible personnel and record findings with owners and due dates. An audit is not merely a search for blame. It is a control that reveals undocumented work, unauthorized modifications and weaknesses in the process.

8. Detailed Illustrative Case: University Payment Portal

Background

A fictional university is developing a payment portal for tuition and accommodation fees. The initial release supports card payments and produces receipts. During testing, the finance office requests automatic payment retries for temporary network failures. At the same time, a security adviser reports that excessive retries could create duplicate charges.

Problem

The request appears small but affects business rules, user messaging, payment-provider integration, database records, test scenarios, monitoring and operational procedures. Implementing it directly on the release branch could create financial and reputational risk.

Analysis

The product owner creates CR-032 and links it to the finance request. The technical lead identifies the following configuration items: payment requirements, retry design, payment-client code, database transaction logic, automated tests, user documentation and monitoring configuration. The security adviser requires idempotency keys so that repeated requests are recognized as the same transaction.

The change is classified as normal rather than standard because it affects financial transactions. The team assesses impacts on compatibility, privacy, reliability and release timing. It decides that retries will be limited to defined transient errors, with a maximum of two attempts and clear audit logging. The exact retry policy is documented as a requirement rather than hidden in code.

Approach and solution

The team updates the requirements baseline and design record. A short-lived branch is created from the approved development baseline. Commits reference CR-032. A pull request requires review by the technical lead and finance-domain representative. Automated tests cover successful payment, transient failure, permanent failure, duplicate request and timeout scenarios. A test environment uses a simulated payment provider.

The build pipeline runs tests and security analysis. A release candidate is tagged, deployed to a staging environment and subjected to user acceptance testing. The release record links the tag, build artifact, test results, approval decision and rollback procedure. The production deployment is scheduled outside peak payment hours, with monitoring enabled.

Outcome

Testing reveals that a timeout can leave the local transaction state uncertain. The team adds a reconciliation process rather than immediately retrying every timeout. The change is delayed by one day but avoids a potentially serious duplicate-charge problem. Release 1.4.0 is approved with documented limitations and monitoring instructions.

Learning points

The case demonstrates that change control is not a barrier to useful work. It exposes dependencies, creates evidence and encourages appropriate safeguards. Traceability connects the financial request to implementation and testing. Version control preserves the prior release, while configuration and release records make the deployed system identifiable.

9. Challenges, Ethics and Governance

Common challenges

Process overload: Excessive approval layers encourage teams to avoid the official process. Controls should be risk-based and automated where possible.

Configuration drift: Environments gradually differ from approved definitions. Infrastructure-as-code, automated reconciliation and periodic audits reduce drift.

Unreviewed emergency work: Urgent changes may be necessary, but retrospective review is essential.

Dependency uncertainty: A project may build differently when external dependencies change. Lockfiles, internal mirrors, vulnerability monitoring and tested upgrade procedures help manage this risk.

Merge conflicts and integration debt: Frequent, small integrations and clear ownership reduce the cost of divergence.

False traceability: Linking records without meaningful evidence creates an appearance of control. Links should lead to substantive requirements, reviews and test results.

Ethical and governance considerations

Change decisions can affect privacy, accessibility, safety, financial fairness and employment. A technically successful change may still be unacceptable if it weakens consent, excludes users with disabilities or increases surveillance without justification. Project teams should assess stakeholders beyond the person requesting the change.

Access to repositories and deployment systems should follow least privilege. Audit logs should be protected from unauthorized alteration. Retention periods must respect contractual, legal and privacy requirements; storing every personal detail indefinitely is not automatically good governance.

Technology and AI

Automation can classify requests, generate release notes, detect configuration drift and summarize differences. AI-assisted coding can accelerate implementation, but generated code requires the same review, testing, licensing checks and security assessment as human-written code. AI systems may also expose confidential requirements or source code when external services are used. Organizations should define approved tools, data-handling rules, human approval responsibilities and evidence requirements.

10. Best Practices for Diploma-Level Practice

1. Define configuration items before the project becomes complex.
2. Establish a baseline at each significant approval or release point.
3. Give every change a unique identifier and record its rationale.
4. Link changes to requirements, commits, tests and releases.
5. Keep commits small, coherent and understandable.
6. Protect the main branch and require review for consequential changes.
7. Automate builds and tests, but retain human judgment for risk decisions.
8. Store deployment configuration and infrastructure definitions under control.
9. Keep secrets out of repositories.
10. Record emergency changes and review them afterward.
11. Make release artifacts identifiable and recoverable.
12. Conduct audits proportionate to risk and act on their findings.
13. Define rollback and recovery procedures before deployment.
14. Treat documentation, test cases and operational instructions as configuration items.

Chapter Summary

Change management provides a controlled method for deciding whether and how software changes should be made. Configuration management identifies the product components, establishes baselines and records their status. Version management preserves the history of files and supports collaboration through repositories, commits, branches, merges and tags.

A sound workflow records a request, classifies it, analyses impact, obtains appropriate authorization, implements it under version control, verifies the result and closes the record with evidence. Traceability connects requirements, decisions, code, builds, tests and releases. Build and release practices make delivered software identifiable and recoverable, while configuration audits compare actual products with approved records.

Effective controls must be proportionate. Too little control creates instability and accountability gaps; too much creates delay and encourages workarounds. Professional practice therefore combines risk-based governance, automation, security, ethical consideration and clear human responsibility.

Key Terms

Configuration item: A controlled component whose identity, integrity or history matters.

Configuration management: Identification, control, accounting and auditing of product configurations.

Baseline: An approved set of configuration items used as a reference point.

Change request: A recorded proposal to alter an approved product, process or plan.

Change control: The process of evaluating, authorizing, implementing and verifying changes.

Traceability: The ability to follow relationships among requirements, work, code, tests and releases.

Repository: A managed store containing files and their version history.

Commit: A recorded, identifiable set of changes.

Branch: An independent line of development.

Merge: Integration of changes from different branches.

Merge conflict: A condition in which changes cannot be combined automatically.

Tag: A stable name attached to a particular repository revision.

Build: The controlled transformation of source and dependencies into an artifact.

Artifact: A build output such as a package, binary or container.

Release: An approved, tested and packaged product version delivered for use.

Configuration drift: Divergence between an actual environment and its approved configuration.

Functional configuration audit: Audit of required functionality and its verification evidence.

Physical configuration audit: Audit of delivered components, versions, labels and documentation.

Rollback: Returning a system to a previously known acceptable state.

Pull or merge request: A proposed integration submitted for review and automated checking.

Review Questions

Short Answer Questions

1. Distinguish between change management, configuration management and version management.
2. What is a baseline, and why should it be formally approved?
3. Name four configuration items other than source code.
4. What information should a change request contain?
5. Explain the difference between a branch and a tag.

Long Answer Questions

1. Describe a complete change-control workflow from request submission to closure.
2. Explain how traceability supports impact analysis, testing and accountability.
3. Compare trunk-based development, feature branching and release branching.
4. Explain the purpose of configuration status accounting and functional and physical audits.
5. Discuss how build and release practices support reproducibility and rollback.

Analytical / Application Questions

1. A developer makes an urgent production fix without a change record. Design an appropriate retrospective control process and identify the evidence that should be retained.
2. A release passes functional tests but is built using an unrecorded dependency version. Analyse the configuration and governance risks and propose corrective actions.
3. A team has six-month-long feature branches and frequent merge failures. Recommend a revised version-management approach and justify it in terms of integration risk, review and delivery frequency.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes a baseline from an ordinary working file?

A. A baseline is an approved reference configuration used for controlled comparison.

B. A baseline is always the newest file in the repository.

C. A baseline is a temporary personal copy with no approval.

D. A baseline contains only executable source code.

Correct Answer: A. A baseline is an approved reference configuration used for controlled comparison.

Question 2

Which activity normally occurs during impact analysis?

A. Deleting the previous release history

B. Identifying effects on scope, schedule, security, testing and related items

C. Publishing the release before approval

D. Changing production configuration without evidence

Correct Answer: B. Identifying effects on scope, schedule, security, testing and related items

Question 3

What is the main purpose of a commit?

A. To erase all earlier repository history

B. To record an identifiable set of changes

C. To approve every project change automatically

D. To replace the need for testing

Correct Answer: B. To record an identifiable set of changes

Question 4

Which practice most directly reduces configuration drift?

A. Allowing manual production changes without records

B. Keeping environment definitions under version control and reconciling them automatically

C. Removing deployment documentation

D. Using different unrecorded settings in each environment

Correct Answer: B. Keeping environment definitions under version control and reconciling them automatically

Question 5

A tag in a version-control repository is most commonly used to:

A. Mark a particular stable revision, such as a release

B. Combine two conflicting branches automatically

C. Store passwords for deployment

D. Replace a requirements baseline

Correct Answer: A. Mark a particular stable revision, such as a release

Question 6

Which record provides the strongest approval evidence for a high-risk change?

A. An informal conversation with an unknown participant

B. A dated record identifying the approver, decision, version reviewed and conditions

C. A commit message containing only “fixed”

D. A deleted email thread

Correct Answer: B. A dated record identifying the approver, decision, version reviewed and conditions

Question 7

What is the primary purpose of a functional configuration audit?

A. To check whether required functions and verification evidence are present

B. To measure developer typing speed

C. To rename all repository branches

D. To remove obsolete user documentation without review

Correct Answer: A. To check whether required functions and verification evidence are present

Question 8

Why are short-lived branches generally easier to integrate than long-lived branches?

A. They eliminate the need for testing.

B. They reduce divergence and merge debt.

C. They prevent all defects automatically.

D. They make approval records unnecessary.

Correct Answer: B. They reduce divergence and merge debt.

Question 9

In the illustrative payment-portal case, why was idempotency important?

A. It ensured repeated requests could be recognized as the same transaction.

B. It increased the number of retries without limit.

C. It removed the need for database records.

D. It guaranteed that every network request would succeed.

Correct Answer: A. It ensured repeated requests could be recognized as the same transaction.

Question 10

Which item should normally be included in a release record?

A. Only the developer’s first name

B. The source revision, artifact identity, test evidence and rollback information

C. An untested collection of local files

D. A promise that no future changes will occur

Correct Answer: B. The source revision, artifact identity, test evidence and rollback information