Software Configuration Management

14.1 Software Configuration Management and Why Software Changes

14.1.1 Configuration Management as an Umbrella Activity

Why does a whole branch of software engineering exist just for keeping track of software? Think about the last time you worked on a document with several versions: "report_final.docx", "report_final2.docx", "report_FINAL_v3.docx". Now multiply that confusion by a team of ten developers, a million lines of code, and five years of changes. That is the problem this lecture solves.

Software configuration management (SCM) is an umbrella activity — a supporting workflow that runs through the entire software development lifecycle, just as an umbrella covers the whole body rather than one limb. It covers the policies (the rules about who may change what and when), the processes (the steps that a change travels through), and the tools (the software systems that store versions and coordinate the team) for managing changing software systems.

The word "umbrella" matters: configuration management is not one task done at one point in the project. It starts when the first component is written and it keeps running during testing, through delivery, and beyond, into maintenance and operation. It is not a phase — it is a continuous, background process that every other activity in the lifecycle depends on. Because it supports everything else, it is often called an umbrella activity in textbooks: like project management and quality assurance, it wraps around requirements analysis, design, coding, testing, and maintenance without being a phase of its own.

14.1.2 Why Software Systems Constantly Change

Software systems are constantly changing — in development, in maintenance, and in operation. The pressures are always there, and there is no stage of a system's life where they go away:

• Bugs are discovered and they have to be fixed. A single defect found by a customer in the field triggers a change to the code, a new version of the component, and eventually a new version of the system.
• System requirements keep changing, and those changes have to be implemented in new versions of the system. Business needs evolve, regulations change, and users ask for features they did not ask for at the start.
• New versions of hardware and system platforms are released, and the system has to be adapted to work with them. A new operating system release, a new processor family, or a new database version can force the software to change even when nothing else does.
• Competitors introduce new features in their systems, and the system has to match them. If a rival product ships a capability that yours lacks, market share starts to leak.

Every time a change is made to the software, a new version of the system is created. Managing evolving systems matters because it is easy to lose track of what changes and what component versions have been incorporated into each system version. Notice the two levels: a system version is built from many component versions, so the tracking problem is combinatorial — ten components with three versions each can combine into far more distinct systems than anyone can remember.

Versions exist for a reason. A version implements one of three kinds of intent:

• Proposals for change — new functionality requested by customers or developers;
• Corrections of faults — repairs of bugs and security vulnerabilities;
• Adaptations — adjustments for different hardware and operating systems.

Crucially, several versions may be under development and in use at the same time. A company may still support release 1.0 for old customers, have release 1.1 in testing, and develop version 2.0 for next year — all at once. This coexistence of versions, rather than any single version, is what makes configuration management necessary.

14.1.3 What Can Go Wrong Without Configuration Management

If there are no effective configuration management procedures in place, a team can waste effort modifying the wrong version of a system, deliver the wrong version of a system to customers, forget where the source code for a particular version of a system or a component is stored, and lose track of which version is the latest.

Configuration management is the professional answer to a very human problem: forgetting. A single developer forgets details over weeks; a team forgets them over days; a distributed team forgets them over hours. The tools do not just store files — they record who changed what, when, why, and which combination of component versions makes up any given system version.

In industry, configuration management is not a textbook nicety — it is the backbone of every serious development operation. Version control platforms such as Git (with hosting services like GitHub and GitLab) are the everyday face of configuration management, and regulatory standards such as ISO 9001 and the SEI's Capability Maturity Model (CMMI) require organizations to define and use configuration management procedures before they can be certified. For a large bank or an aircraft software supplier, the ability to reproduce exactly which code, with which fixes, went into a specific delivered system is not optional — it is a legal and safety obligation.

14.2 The Four Configuration Management Activities

14.2.1 Version Management, System Building, Change Management, and Release Management

Every software product's configuration management reduces to four activities. Before looking at the tools, learn the four names and what each one does — this is one of the most direct exam questions in the topic.

Two of these activities manage things (versions, releases) and two manage decisions (what to build, which changes to accept). Keeping that split in mind helps you remember the whole set: version management and release management are bookkeeping over artifacts; system building and change management are processes that consume and produce those artifacts.

14.2.2 How the Activities Fit Together

The four activities form a chain of dependencies. Start with component versions. Version management keeps those versions under control. System building then uses the correct versions to build the system, which creates system versions. Change management takes over from there, working from change proposals. Release management finishes the loop by preparing the software for external release and tracking the system versions that have been released for customer use — that is, the system releases.

Picture the flow as a cycle. A developer submits a change proposal; change management evaluates it; the approved change is implemented, which produces a new component version; version management stores it; system building assembles a new system version; release management ships it to customers; customers then report bugs, which start new change proposals — and the cycle repeats. The four activities interlock: a change proposal is the fuel for the cycle, component versions are the raw material, system versions are the product, and system releases are what customers actually see.

Because of the large volume of information to be managed and the relationships between configuration items, software tool support in the form of configuration management systems is essential. No human team can reliably remember which component versions belong to which system version across a project with thousands of files — the relationship is one-to-many in both directions, and only a database can keep it consistent.

14.2.3 Tool Support and Agile Development

Configuration management tools are used to store versions of system components, to build systems from these components, to track releases of system versions to customers, and to keep track of change proposals. They range from very simple tools that support a single configuration management task, such as bug tracking, to integrated environments that support all configuration management activities.

The moral is practical, not just theoretical: choose configuration management tooling to match the project's pace. A tiny solo project may only need version control; an agile team needs version control, build automation, and issue tracking integrated; a large product company needs all four activities automated in a single configuration management system, because the volume of information simply does not fit in anyone's head.

14.3 Development Phases and Multiple System Versions

14.3.1 Three Phases of Software Development

A software system is not "developed, then done". The development of a software product or a custom software system takes place in three distinct phases, and each phase has a different boss, a different kind of change, and a different rule about what may change:

The three phases differ in who authorizes a change: the development team in phase one, the testing/quality authority in phase two, and customer demand plus business decisions in phase three. A version of the system travels through all three phases; at each boundary it changes status, and the configuration management system records that status so everyone knows whether a given version is still accepting features or is frozen for testing.

14.3.2 A Multi-Version Example

For large systems there is never just one working version; there are always several versions at different stages of development, and several teams may be involved in developing the different system versions. One release may still be in customer use while a second is in testing and a third is receiving new features — all at the same time.

These different versions may have common components as well as components, or component versions, that are unique to that system version. For example, versions 1.5 and 2.4 may both use the same ReportGenerator component version, while each has its own unique modules. The configuration management systems keep track of the components that are part of each version and include them as required in the system build — shared components do not have to be copied per version, only referenced by each version's definition.

14.3.3 Configuration Management and Quality Management

In large configuration management projects, configuration management is sometimes part of software quality management, and the quality management team is responsible for both quality management and configuration management. The two disciplines meet at a natural point: quality decides whether a version is good enough, and configuration management controls what happens to it afterwards.

When a pre-release version of the software is ready, the development team hands it over to the quality management team. The quality management team checks that the system quality is acceptable. Only then does it become a controlled system, which means that all changes to the system have to be agreed on and recorded before they are implemented.

This handover is the moment the system's status changes from "work in progress" to "controlled". Once controlled, a change requires prior agreement — typically via the change management process described later in this lecture — and a record. The practical effect is that the system's evolution becomes an auditable history rather than a stream of undocumented edits: at any time you can answer what was changed, by whom, and with whose approval.

14.4 Configuration Management Terminology and Standards

14.4.1 The Core Vocabulary

Every field has its own words, and configuration management has more than most. There are many specialized terms used in configuration management, and unfortunately they are not standardized — different tools and different companies use overlapping words for the same ideas. The key ones, grouped by what they describe:

A handy way to keep the core four straight: a version is one snapshot of one item, a codeline is the timeline of that item, a baseline is a chosen snapshot of the whole system (one item from each codeline), and the main line is the timeline of those system snapshots. Everything else in the vocabulary — repository, workspace, release, branch, merge — exists to serve one of those four.

14.4.2 Why Terminology Is Not Standardized

Why can't the field simply agree on words? The history explains it. The first systems in which software configuration management was used reflected the processes and terminology of hardware configuration management — these were military software projects, and they borrowed words like baseline and configuration item from the hardware world, where tracking physical parts and their revisions had been done for decades. Commercial software developers did not necessarily know those military procedures, so they often invented their own terms for the same concepts. Agile methodologies have also devised new terminology in order to distinguish the agile approach from traditional configuration management methods — a practice that adds yet more words for the same underlying ideas.

The result is a vocabulary that overlaps from product to product, so it pays to learn the underlying ideas, not just the labels. When you meet an unfamiliar tool, do not ask "what is its baseline called?" — ask "how does it define a system version, and can it recreate it from its components?" The idea survives the word.

14.4.3 Configuration Management Standards

Because configuration management matters for quality, it is also a matter of standards. The definition and use of software configuration management standards are essential for quality certification under both the ISO 9001 standards and the Software Engineering Institute's Capability Maturity Model (CMMI) — the SEI's maturity model whose higher levels require defined, managed, and measured processes, configuration management among them. A company seeking certification must show that it has written configuration management procedures and that it follows them.

Notation and naming note: the lecture mentions ISO 9001, which is part of the ISO 9000 family of quality management standards; reference texts sometimes write "ISO 9000" to mean the whole family. The maturity model is the SEI's Capability Maturity Model, commonly abbreviated CMMI (Capability Maturity Model Integration). And the IEEE configuration management standard is IEEE 828-2012 — the source's spoken "IEEE 820" is a slip; 828 is the correct number.

Agile methods rarely use these standards because of the document overhead involved; they keep the documentation to the minimum required for the project. Most of their documentation takes the form of stories, which capture the requirements, and test cases, which are used in test-driven development. Where a certification-driven company writes process documents and change records for every step, an agile team writes just enough — the story and its tests — and relies on frequent integration to keep quality high instead of formal documentation.

14.5 Version Management: Codelines, Baselines, and Main Lines

14.5.1 Codelines and Baselines

Version management is the process of keeping track of the different versions of software components and of the systems in which these components are used. It also involves ensuring that changes made by different developers do not interfere with each other. In other words, version management is the process of managing codelines and baselines — one sentence that captures the whole topic.

The distinction between the two is the heart of the topic:

• A codeline is a sequence of versions of source code, with later versions in the sequence derived from earlier versions. Codelines normally apply to components of a system, so there are different versions of each component. Picture a single file's history: A1.1 → A1.2 → A1.3, each derived from the one before — that is codeline A.
• A baseline is a definition of a specific system version. The baseline specifies the component versions that are included in the system, plus the libraries used, the configuration files, and other system information such as external components. Picture a recipe: "take A1.3, B1.2, C1.1, link with library L1 and library L2, plus external component Ex1" — that is a baseline.

The contrast in one line: a codeline is the history of one component; a baseline is the snapshot of one whole system. Codelines are the raw timelines; baselines are the horizontal cuts across them at chosen moments. A system with components A, B, and C has three codelines and potentially many baselines — one for every system version you ever need to rebuild.

14.5.2 Specifying a Baseline with a Configuration Language

A baseline may be specified using a configuration language, in which you define what components should be included in a specific version of the system. It is possible to specify an individual component version, say x.1.2, or simply to specify the component identifier x. If you simply include the component identifier in the configuration description, the most recent version of that component should be used.

The language gives the baseline author two levels of precision:

• Pin a version: component x version 1.2 means exactly this version, no matter what happens later. This is what you want when reproducing a delivered system.
• Follow the latest: component x means the most recent version of x at the time of building. This is what you want during active development, when you always build against the newest code.

Baselines are very important because you often have to recreate an individual version of the system. For example, a product line may be instantiated so that there are specific versions for each system customer. If a customer reports bugs in the system that have to be repaired, you may have to recreate the version that was delivered to that specific customer. A car manufacturer's navigation system, for instance, may ship ten variants — one per car model — each a different baseline; when a dealership reports a fault in the variant for one model, the fix has to be applied to exactly that baseline, which only works if the baseline is stored and recreatable.

14.5.3 The Baseline Example

14.5.4 The Main Line

A codeline is a sequence of versions of a single component. A baseline is the collection of the various components (the latest versions or whatever versions are appropriate), libraries, and external components that make up a version of the system. As the component versions change, you get the next baseline, and the sequence of baselines is called the main line: a sequence of system versions developed from an original baseline.

In the example above, baseline 1 and baseline 2 are two points on the main line — the main line is simply the story of the system as a whole, told baseline by baseline. Where a codeline's axis is time within one component, the main line's axis is time within the whole system: baseline 1, then baseline 2, then baseline 3, each a consistent, buildable system. The main line is what continuous integration rebuilds, what releases are cut from, and what everyone means when they say "the system as it currently stands".

14.6 Version Control Systems

14.6.1 Centralized and Distributed Version Control

Version control systems identify, store, and control access to different versions of components. They are the workhorse of configuration management — everything else in this lecture assumes a version control system underneath. There are two types of modern version control systems:

Both types provide comparable functionality, but they implement that functionality in different ways. The word "comparable" is important: the difference between the two types is not what they let you do (track versions, record history, support concurrent work) but where the repository lives and how changes travel.

Comparison — centralized vs distributed:

When to pick which: a team that needs a strict, centrally controlled record of everything (common in large regulated organizations) may still use a centralized system; a team that wants offline work, cheap branching, and built-in backup — which is most modern and all open source teams — uses a distributed system.

14.6.2 Key Features of Version Control Systems

Whichever type is chosen, the functionality expected from a modern version control system is the same. The key features of these systems:

The five features form a natural order: identify each version, record how it came to be, isolate concurrent work, support the project as a unit, and store it cheaply. The last feature — storage management — may sound like an implementation detail, but it is examined in detail later in this lecture, because the two main strategies (deltas and compression) have very different costs and behavior.

14.7 Project Repositories and Private Workspaces

14.7.1 The Repository and Workspace Model

Most software development is a team activity, and several team members often work on the same component at the same time. To support independent development without interference, all version control systems use the concept of a project repository and a private workspace.

The project repository maintains the master version of all components, which is used to create baselines for system building. It is the authoritative store: what baselines are built from, what release managers tag, and what new team members start from. When modifying components, developers copy, or check out, these components from the central repository into their private workspace and work on the copies. When they have completed their changes, the changed components are tested and then checked back in to the repository.

The model is deliberately built on copies. A developer never edits the repository itself — that would let one person's half-finished work damage everyone else's. Instead, the repository holds the shared truth, each workspace holds an isolated copy, and the check-in step is the only door through which work re-enters the shared world. The centralized and distributed version control systems support independent development of shared components in different ways, but both honor this same two-place model.

14.7.2 The Centralized Workflow

In centralized systems, developers check out components, or directories of components, from the project repository into their private workspace and work on these components there. When their changes are complete and tested thoroughly, they check the components back into the repository. This creates a new component version that may then be shared.

If two or more people are working on the same component at the same time, each must check out the component from the repository into their private workspace. If a component has been checked out, the version control system warns other users who want to check out that component that it is already being worked on. The warning is informational, not a lock: both developers may still work in parallel. The system also ensures that when the modified components are checked in, the different versions are assigned different version identifiers and stored separately — so two parallel check-ins of the same component produce two distinct new versions rather than one overwriting the other.

14.7.3 The Distributed Workflow and the Clone Example

In a distributed version control system such as Git, a slightly different approach is used. A master repository is created on a server, and it maintains the code produced by the development team. Because it is a distributed system, instead of simply checking out the files they need, a developer creates a clone of the project repository, which is downloaded and installed on the developer's private workspace. This is called repository cloning.

The clone is not a partial copy of selected files — it is a complete repository: every component, every version, the entire history. From then on the developer works against their own local repository exactly as if it were the only one.

Once the changes are finished, the developer commits these changes, which updates their private repository. They may then push these changes to the project repository, or tell the integration manager that the changed versions are available, and the integration manager may then pull these files into the project repository.

14.8 Distributed Version Control in Open Source Development

14.8.1 Advantages of Distributed Version Control

The distributed model is not just a fashion — it buys three concrete advantages that the centralized model cannot offer:

These three advantages reinforce each other. Offline commits mean the developer's local repository is always a fresh, complete record of their work; that same local record is the backup that can restore the project; and the completeness of the clone is what makes local testing of the whole system possible.

14.8.2 Open Source Development and the Integration Manager Example

Distributed version control is essential for open source development, where several people may be working simultaneously on the same system without any central coordination. There is no way for the open source system manager to know when changes will be made — contributors appear and disappear, work at any hour, and owe no reporting duty to anyone.

In this case, in addition to a private repository on their own computer or workspace, developers also maintain a public server repository, to which they push the new versions of the components that they have changed. It is then up to the open source system manager to decide when to pull these changes into the definitive system version that is maintained as a baseline. The manager never forces anyone; contributors publish, and the manager selects. This is the "pull" model of coordination, in contrast to the "push" model of a corporate team where everyone commits into one shared trunk.

14.9 Branching and Merging

14.9.1 Why Codelines Branch

A consequence of the independent development of the same component is that codelines may branch. Rather than a linear sequence of versions that reflect changes to the component over time, there may be several independent sequences. This is normal in system development, where different developers work independently on different versions of the source code and change it in different ways. Imagine two developers both taking version V2.0 of a component: one produces V2.1 (adding a feature), the other produces V2.1.1 and V2.1.2 (fixing a bug on a released line). The codeline has now split into two parallel sequences — a branch.

Branches exist to isolate work-in-progress. It is generally recommended that, when working on a system, a new branch should be created so that changes do not accidentally break a working system.

14.9.2 The Merge Example

At some stage it may be necessary to merge codeline branches to create a new version of a component that includes all the changes that have been made.

14.9.3 Automatic and Manual Merging

If the changes that were made involve completely different parts of the code, the component versions may be merged automatically by the version control system, simply by combining the code changes. This is the normal mode of operation when new features have been added; these code changes are merged into the master copy of the system. If Alice added a new function at the top of the file and Bob renamed a variable at the bottom, the system can combine the two edits line by line with no human involvement — their changes do not overlap.

However, the changes made by different developers sometimes overlap. The changes may be incompatible and may interfere with each other. Suppose both Alice and Bob edited the same function in incompatible ways — the system cannot choose which version is right, because both edits target the same lines. In that case, the developer has to check for the clashes and make changes to the component to resolve the incompatibilities between the different versions. This is the manual merge, and it is the most error-prone moment in version management: the merging developer must understand both changes, decide which semantics to keep, and possibly edit the code until the merged result is correct.

Two practical rules follow. First, automatic merges succeed when changes are disjoint — so teams that structure work so that members rarely edit the same code reduce merge problems by design. Second, when a merge is manual, it must be tested like any other change before it is trusted, because a bad merge silently loses or corrupts someone's work.

14.10 Storage Management: Deltas and Compression

14.10.1 Deltas and Recreating Old Versions

When version control systems were first developed, storage management was one of their most important functions. Since storage was expensive, it was very important to minimize the disk space used by the different copies of the components. Instead of keeping a complete copy of each version, the system stores a list of differences, called deltas (the changes between one version and another).

The key insight: consecutive versions of a file usually differ only slightly — a few lines changed here, a function added there. Storing the full text of every version would duplicate the 99% that did not change; storing only the differences is dramatically cheaper. A delta is that difference: a list of the changed lines (or changed regions) between two versions.

By applying these deltas to a master version, usually the most recent version, the previous version can be recreated. Similarly, by applying the deltas one by one, the original version can be recreated. The version sequence is ordered by creation date, and each delta is just the change from one version to the next; you apply these changes in reverse to revert back to the original version of the code.

Let the versions be $V_{1.0},V_{1.1},V_{1.2},V_{1.3}$ in creation order, with delta $D_1$ the change $V_{1.0}\to V_{1.1}$, $D_2$ the change $V_{1.1}\to V_{1.2}$, and $D_3$ the change $V_{1.2}\to V_{1.3}$. The system stores $V_{1.3}$ in full. Recreating the earlier versions means undoing the deltas in reverse order:

$$V_{1.2}=D_3^{-1}(V_{1.3}),V_{1.1}=D_2^{-1}(V_{1.2}),V_{1.0}=D_1^{-1}(V_{1.1})$$

where $D_i^{-1}(V)$ means undo the change recorded in delta $D_i$ when it was applied to produce the next version. Each step is a mechanical application of stored differences — no creativity needed, so the whole chain runs automatically.

When a new version is created, the system simply stores a delta, a list of differences between the new version and the older version, and this delta is used to create the new version. In a diagram, the earlier versions of a component are shown as shaded boxes, because they are automatically recreated from the most recent component version, version 1.3. The one full copy sits at the right end of the sequence; everything to its left is materialized on demand.

Deltas are usually stored as a list of changed lines, and by applying these automatically, one version of a component can be created from another. Since the most recent version of a component is the one most likely to be used, most systems store that version, version 1.3 in the example, in full, including the source code, and the deltas define how to recreate the earlier system versions when required. Storing the newest version in full is a deliberate trade-off: it is the version fetched most often, so its fetch must be instant; older versions are fetched rarely, so their cost is paid in recreation time rather than storage.

14.10.2 Git's Compression Approach and Packed Files

One problem with the delta-based approach to storage management is that it can take a long time to apply all of the deltas. A very old version may sit behind a long chain of differences, and reconstructing it means replaying the whole chain — the oldest versions are the most expensive to read. Storage is now relatively cheap, especially in the cloud, and Git uses an alternative, faster approach.

Git does not use deltas but applies a standard compression algorithm to the stored files and their associated meta information. It does not store duplicate copies of files, so retrieving a file simply involves decompressing it, with no need to apply a chain of operations. The trade-off is direct: Git spends a little more disk space (a compressed full copy of each distinct file) to save a lot of time — decompression is fast, while replaying a delta chain is not.

Git also uses the notion of packed files: several smaller files are combined into an indexed single file. This reduces the overhead associated with lots of small files. A repository of thousands of tiny files would waste space and slow access (file-system overhead per file); packing them into one indexed file amortizes that cost, and the index lets the system find any contained file quickly. Deltas are still used within packed files, to further reduce their size — so the delta idea has not disappeared, it has been demoted to a secondary optimization applied inside compressed packs.

The history is instructive: deltas were invented when disk space was the scarce resource; compression-plus-packing is what a world of cheap storage and expensive time chose instead. Both approaches answer the same question — how do we store many versions without paying for every version in full? — with different trade-offs between space and speed.

14.11 System Building

14.11.1 What System Building Means

System building is the process of creating a complete executable system by compiling and linking the system components, using the system building tools and the version control system. An executable system version can be created with an automated build system, so the whole build runs with a single command, or even a single mouse click.

The building blocks are more than just source code. A build assembles the checked-out component versions, externally provided libraries, data files (such as a file of error messages), and configuration files that define the target installation — and it must know the versions of the compiler and other tools to use. The output is an executable system version plus test results. Because so many inputs must be brought together in the right versions, an automated build tool is not a luxury: hand-assembling a large system is both slow and error-prone, which is why build tools always make sense.

14.11.2 Features of Build Tools

The tools for system integration and building include some or all of the following features:

14.11.3 Build Scripts

A build script is a definition of the system to be built. It includes information about the components, the dependencies between them, and the versions of the tools used to compile and link the system. The configuration language used to define the build script includes constructs to describe the system components to be included in the build and the dependencies between them.

The build script is the build's recipe — it states the ingredients (components), their relationships (dependencies), and the kitchen equipment (tool versions). Because the script is a file, it can itself be stored and versioned, so the team can say exactly which build script produced which executable — an important piece of the release documentation story later in this lecture. In modern practice, tools like Make (with Makefiles), Apache Maven, Gradle, or Jenkins pipelines are the everyday faces of build scripts, but the concept is the same: one declarative definition of how the system is assembled.

14.11.4 The Three Platforms Involved in Building

Building itself is a complex process and is very potentially error prone, partly because as many as three different platforms may be involved. Each platform plays a different role, and the differences between them are a classic source of build problems.

14.12 Continuous Integration

14.12.1 The Idea of Continuous Integration

Agile methods recommend that very frequent system builds should be carried out, with automated testing used to discover bugs and software problems. Frequent builds are part of agile development, and they are part of continuous integration. In keeping with the agile notion of making many small changes, continuous integration involves rebuilding the main line frequently, after source code changes have been made.

The idea rests on a simple observation about how integration problems happen: two developers working independently can each be perfectly right about their own change, and yet the combination of their changes can break the system. The longer the team waits between integrations, the more such combinations pile up, and the harder it is to find which pair of changes caused the failure. Continuous integration shrinks that window from weeks to hours: integrate a small change, build, test — and if something breaks, the suspect change set is tiny.

14.12.2 The Continuous Integration Steps

The steps in continuous integration, in order:

There are tools, such as Jenkins, that support continuous integration. These tools can be set up to build the system as soon as the developer has completed a repository update. The tool watches the repository, and every push triggers the extract → build → test cycle automatically; the results are reported back to the team, so a broken build becomes visible to everyone immediately.

14.12.3 Advantages and Limits of Continuous Integration

The advantage of continuous integration is that it allows problems caused by interactions between different developers to be discovered and repaired as soon as possible. The most recent system in the main line is a definitive working system. That second sentence is the payoff: at any moment, "the system" means something specific and trustworthy — the latest baseline on the main line — rather than a guess about which combination of half-finished work might work today.

Although continuous integration is a good idea, it is not always possible to implement this approach to system building. Two limits, both practical:

• Large systems build too slowly. If the system is very large, it may take a very long time to build and test, especially if integration with other application systems is involved; it may be impractical to build the system being developed several times per day. When one full build and test run takes a day, "continuous" integration is a contradiction.
• Different development and target platforms block local testing. If the development platform is different from the target platform, it may not be possible to run the system tests in the developer's private workspace, because there may be differences in hardware, operating system, or installed software. So more time is required for testing the system.

For large systems, or for systems where the execution platform is not the same as the development platform, continuous integration is usually impossible. The next topic describes what teams do in exactly those circumstances: a daily build system, which keeps the benefits of frequent integration at a pace the project can actually sustain.

14.13 Daily Builds

14.13.1 How a Daily Build Works

In the circumstances where continuous integration is impossible, frequent system building is supported using a daily build system. The daily build keeps the core idea of continuous integration — build often, test after every build — but paces it to once a day, which is feasible even for systems that take many hours to build and test.

The fixed 2 PM deadline is the mechanism that makes the daily build work. Because everyone must deliver by the same time, the build is a daily, ritual event: the team knows that whatever they have at 2 PM is what gets integrated that day, which forces regular integration habits even without continuous integration infrastructure.

14.13.2 Why Frequent Builds Help

The advantages of frequent builds of software:

• The chances of finding problems stemming from component interactions early in the process are increased. The whole point of integrating frequently is that interaction bugs — the ones that appear only when two components meet — surface while the involved code is still fresh and while the responsible developer still remembers the change.
• Frequent building encourages thorough unit testing of components. A developer knows their component will face the full system build and the predefined tests the same afternoon, so they unit-test it first; the pressure of the coming build pushes quality work forward.
• Psychologically, developers are put under pressure not to break the build. That is, they try to avoid checking in versions of the components that might cause the whole system to fail, so they are reluctant to deliver new component versions that have not been properly tested.

The consequence is that less time is spent during system testing, discovering and coping with software faults that could have been found by the developer in the private workspace. The daily build moves the discovery of faults earlier — out of the final system testing phase and into the day-to-day rhythm of development — where each fault is cheaper to find and cheaper to fix.

14.14 Minimizing Recompilation: File Signatures

14.14.1 Linking Source Code and Object Code

Compilation is a computationally intensive process, so tools that support system building are designed to minimize the amount of compilation required. They do this by checking whether a compiled version of a component is available; if it is, there is no need to recompile that component. This requires an unambiguous way of linking the source code of a component with its equivalent object code.

This linking is accomplished by associating a unique signature with each file where the source code of the component is stored. The corresponding object code, which has been compiled from the source code, has a related signature. The signature identifies the source code version, and it changes when the source code is edited. By comparing the two signatures on the source code and object code files, it is possible to decide whether the source code component was used to generate the object code component.

The reasoning is a simple yes/no test: if the object code was generated from this exact source, reuse it; otherwise, recompile. The signature is the identity card that makes the comparison possible — the build system reads the source file's signature and the object file's signature and asks: do they match?

14.14.2 Modification Timestamps

The first type of signature is the modification timestamp. The signature on the source code file is the time and date when the file was modified. If the source code file of a component has been modified after the related object code file, the system assumes that recompilation, to create a new object code, is necessary.

The rule is a comparison of two times. Let $t_s$ be the last modification time of the source file and $t_o$ the last modification time of the object file:

$$\text{recompile}⟺t_s>t_o$$

If the source was edited after the object code was produced, the object code is stale — it does not reflect the current source — so it must be regenerated. If the source is older than the object code, the object code is up to date and compilation is skipped. The timestamp is free (the operating system records it automatically) and the comparison is instant, which is why it is the classic first approach.

14.14.3 Source Code Checksums

The second type is the source code checksum. The signature on the source code file is a checksum calculated from the data in the file. The checksum function calculates a unique number using the source text as input. If you change the source code even by one character, this will generate a different checksum, so you can be confident that source code files with different checksums are actually different.

The checksum is a number computed from the file's content — think of it as a fingerprint of the text. Because the computation involves every character, a one-character edit produces a completely different fingerprint. The checksum is assigned to the source code just before the compilation, and it uniquely identifies the source file. The build system then tags the generated object code file with the checksum signature. If there is no object code file with the same signature as the source code file to be included in the system, recompilation of the source code is necessary.

The decision rule now becomes: recompile if and only if no object file carries the same checksum as the source file.

14.14.4 Comparing the Two Approaches

The object code files are normally not versioned, so with the first approach, the modification timestamp approach, only the most recently compiled object code file is maintained in the system. This object code file is normally related to the source code file by name: it has the same name as the source code but with a different suffix. For example, the source file comp.java may generate the object file comp.class. Because source and object files are linked by name, it is usually not possible to build different versions of a source code component into the same directory at the same time. The compiler would generate object files with the same name, so only the recently compiled versions would be available.

The checksum approach has the advantage that many different versions of the object code of a component can be maintained at the same time. The checksum signature, rather than the file name, is the link between the source code and the object code files; the source code files and object code files have the same signature. When you recompile a component, it does not overwrite the object code, as would normally be the case when timestamps are used. Instead, it generates a new object code file and tags it with the source code signature. So parallel compilation is possible, and different versions of the component may be compiled at the same time with the checksum approach.

Comparison — timestamp vs checksum signatures:

When to pick which: the timestamp approach is simple and cheap and serves most projects, where one current object per component is all that is needed; the checksum approach costs a little bookkeeping and buys the ability to build several versions of a component side by side — which matters in large systems where different baselines need different compiled versions at the same time.

14.15 Change Management: Goals, Tools, and the Process Model

14.15.1 Why Change Management Matters

Change is a fact of life for any software system, particularly large software systems. Organizational needs change, and requirements change during the lifetime of the system and during the development of the system itself. To ensure that the changes are applied to the system in a controlled way, you need a set of tools that support the change management process.

Without a process, changes arrive as a flood of uncoordinated demands — a phone call here, an email there, a manager's request in a corridor — and each one is implemented or ignored depending on who shouts loudest. Change management replaces that chaos with a decision system. It is intended to ensure that the evolution of the system is controlled and that the most urgent and cost-effective changes are prioritized. Note the two goals: control (changes happen through a defined route, and the system's evolution is recorded) and prioritization (the limited development capacity is spent on the changes that matter most and cost least).

Change management is the process of analyzing the costs and benefits of proposed changes, approving those changes that are cost-effective, and tracking which components in the system have been changed. The definition has three verbs — analyze, approve, track — and the next topics expand each one: analysis and costing in 14.16, approval by the change control board in 14.16, and tracking through the change request form and derivation histories.

14.15.2 The Change Management Process Model

The model of a typical change management process shows the main change management activities and the roles involved: customer support (which checks change requests), development, product development (the change control board), and the customer who submits the change requests. Four roles, each with a different job: the customer proposes, customer support checks, development assesses and implements, and the change control board decides.

The process should come into effect when the software is handed over for release to the customer, or for deployment in an organization. It is a process for delivered software — during development, changes flow through much lighter channels, as described later. Most variants of this process are in use, depending on whether the software is a custom-built system, a product line, or a commercially available off-the-shelf product. The size of the company also makes a difference: small companies use a less formal process than large companies that work with corporate or government customers. However, all change management processes should include some way of checking, costing, and approving changes — those three steps are the irreducible core that every variant keeps.

14.15.3 Tools Supporting Change Management

Tools to support change management may be relatively simple, like issue tracking or bug tracking systems, or software that is integrated with configuration management systems for very large packages. You may have a large configuration management system, such as Rational ClearCase — the widely used commercial configuration management package with which change management tools are integrated in large-scale systems.

Small systems like issue tracking systems allow anyone to report a problem or make a suggestion for a system change, and they keep track of how the development team has responded to the issues. These systems do not impose a process on the users, so they can be used in many different settings — the same issue tracker can serve a five-person start-up and a university course project, because the tool only records, it does not enforce. More complex configuration management and change management systems are built around process models for the change management process, and they automate the entire process of handling requests, from the initial customer proposal to the final change approval by the change control board and the change submission to the development change management process. In these systems, the process is built into the tool: a request cannot skip its required steps, and each role's approvals are enforced.

Comparison — simple issue trackers vs integrated change management systems:

14.15.4 The Change Request Form

The change management process is initiated when a system customer completes and submits a change request describing the change required to the system. This could be a bug report, where the symptoms of the bugs are described, or a request to add some new functionality to the system. Some companies handle bug reports and new requirements separately, but in principle both are simply change requests. The distinction between them is organizational, not fundamental: a bug report and a feature request both say "make the system different", and the change management process treats them the same way.

A change request may be submitted using a simple change request form. The stakeholders involved may be system owners or users, beta testers, developers, or even the marketing department of a company. The electronic change request forms record information that is shared between all groups involved in the change management process. As the change request is processed, information is added to this form to record the decisions made at each stage of the process; at any time, it represents a snapshot of the change request.

The form is the memory of the change. It starts as the proposer's description and grows into a complete dossier: every role adds its contribution, and whoever looks at the form at any moment sees the change request's current state — proposed, checked, costed, approved, implemented, or validated.

In addition to recording the change required, the change request form records the recommendations about the change, the estimated costs of the change, and the dates when the change was requested, approved, implemented, and validated. The change request form may also include a section where a developer outlines how the change may be implemented. The degree of formality in the change request form varies, depending on the size and type of the project and the organization that is developing the system. In a large, complex system-engineering project, the form is typically very detailed — components affected, associated components, change assessment, priority, implementation notes. For smaller projects, the change request should still be formally recorded, but the form should focus on describing the change required, with less emphasis on implementation issues; the system developers can then decide how to implement the change and estimate the time required to complete the change implementation. The rule for small projects: record the what, leave the how to the developers.

14.16 The Change Management Process: Checking, Assessment, and Approval

14.16.1 Checking the Change Request

After the change request has been submitted, it is checked to ensure that it is valid. The checker may be from a customer or application support team; for internal requests, it may be a member of the development team. The change request may be rejected at this stage.

14.16.2 Assessment and Costing

For a valid change request, the next stage in the process is change assessment and costing. This function is usually the responsibility of the development and maintenance teams, because they can work out what is involved in implementing the change.

The assessment proceeds in three moves, each building on the previous:

1. Impact check. The impact of the change on the rest of the system must be checked. To do this, you must identify all of the components affected by the change. If making the change means that further changes are required elsewhere in the system, this will increase the cost of implementing the change — a change is rarely local to the one screen the user mentioned.
2. Module assessment. The required changes to the system modules are assessed — what exactly has to be modified in each affected module, and how much work each modification is.
3. Cost estimation. Finally, the cost of making the change is estimated, taking into account the cost of changing related components. The estimate is the number the decision makers will weigh against the benefits.

The output of this stage is a change request form completed with the affected components, the change assessment, and an estimated effort — exactly the fields seen on the example form in the previous topic.

14.16.3 Approval and the Change Control Board

Following this analysis, a separate group decides whether it is cost-effective for the business to make the change to the software. For defense and government systems, this group is often called the change control board (CCB). In industry, it may be called a product development group, or even a change control board as well.

The product development group is responsible for making decisions about how a software system should evolve. This group should review and approve all change requests, unless the changes simply involve correcting minor errors on screen displays, web pages, or documents; these requests should be passed to the development team for immediate implementation or correction. Small cosmetic fixes do not justify a full board meeting — the board delegates them so the system is not held hostage by its own process.

The CCB, or product development group, considers the impact of the change from a strategic and organizational point of view, rather than simply a technical point of view. The development team already answered "can we do it, and how much does it cost?" — the board answers a different question: "should the business do it, and when?" It decides whether the change in question is economically justified, and it prioritizes the accepted changes for implementation. The accepted changes are passed back to the development group, and the rejected change requests are closed, with no further action taken.

14.16.4 Factors That Influence the Decision

The factors that influence the decision on whether or not to implement the change:

14.17 Change Management in Different Contexts

14.17.1 Change Requests for Off-the-Shelf Products

For commercial off-the-shelf products, the company making the product is not directly involved in decisions about system evolution, and the relevance of the change to a particular customer's business is not an issue. The product maker cannot run a board meeting for every customer; instead, the change request sources are internal. Change requests for these products come from the customer support team, the marketing team, and the developers themselves.

Each of the three sources sees a different side of the product:

• Customer support. The requests may reflect suggestions and feedback from customers, or analysis of what is offered by competing products. The customer support team may submit change requests associated with bugs that have been discovered and reported by customers after the software has been released; customers may use a web page or email to report these bugs. A bug management team then tracks these requests and bug reports, checks if they are valid, and translates them into formal system change requests. Support is the team that turns raw customer noise into formal, filtered change requests.
• Marketing. The marketing staff may also meet with customers and investigate competitive products; they may suggest changes that should be included to make it easier to sell a new version of the system, to new as well as to existing customers. Marketing's changes are about marketability: features that close the gap with competitors or that give salespeople a reason to upgrade customers.
• Developers. The system developers themselves may have good ideas about new features that can be added to the system. The people closest to the code often see opportunities that no customer asked for.

Because no single customer owns the product, the "benefits of the change" question is answered for the whole market rather than for one business — a change that helps thousands of customers across companies scores higher than one that deeply helps a single buyer.

14.17.2 Change Management During Development

The change request process described earlier is initiated after the system has been released to customers. During development, when new versions of the system are created through daily or even more frequent system builds, there is no need for a formal change management process. Problems and requested changes are recorded in an issue tracking system, and discovered problems are discussed in daily meetings. The formality is tuned to the context: before release, changes are cheap and fast and are handled with lightweight tools; after release, changes reach real users, so every change earns its way through the checking, costing, and approval gates.

The division of labor during development:

• Changes that only affect individual components are passed directly to the developer concerned, who either accepts them or makes a case for why they are not required. The developer owns their component; a change touching only their code is their call.
• However, an independent authority, such as the system architect, should assess and prioritize changes that cut across the system modules and that have been produced by different development teams. Cross-cutting changes affect multiple owners, so no single developer can judge them; the architect steps in as the neutral authority to keep the system's overall design coherent.

14.17.3 Agile Methods and Refactoring

In some agile methods, customers are directly involved in deciding a change. They decide whether a change should be implemented: when they propose a change to the system requirements, they work with the team to assess the impact of the change, and then decide whether the change should take priority over the features planned for the next increment of the system. The customer is not just a requester — they are a planner, sitting with the team and trading the proposed change against the features already scheduled for the next increment.

However, changes that involve software improvement are left to the discretion of the programmers working on the system. There is a sharp line in agile change management: requirements changes belong to the customer, but code quality changes belong to the programmers.

14.17.4 Derivation Histories

As the development team changes the software components, they should maintain a record of the changes made to each component. This record is sometimes called a derivation history for the component. The derivation history answers, for each version of a component: what was changed, by whom, when, and why — which change request triggered it?

A good way to keep the derivation history is in a standardized comment at the beginning of the component's source code. This comment should reference the change request that triggered the software change — linking the code directly to the decision trail of change management. These comments can be processed by scripts that scan all components for derivation histories and then generate component change reports. Because the comment format is standardized, the record is machine-readable: a script walks every component in the system and produces a report of which components were changed for which change requests — the raw material for release notes and audits. For documents, records of the changes incorporated in each version are usually maintained in a separate page on the front of the document.

// SICSA project (XEP 6087)
// APP-SYSTEM/AUTH/RBAC/USER_ROLE
// Object: currentRole
// Author: R. Looek
// Creation date: 13/11/2012
//
// Modification history
// Version  Modifier   Date        Change      Reason
// 1.0      J. Jones   11/11/2009  Add header  Submitted to CM
// 1.1      R. Looek   13/11/2009  New field   Change req. R07/02

14.18 Release Management

14.18.1 Major and Minor Releases

Release management is the fourth stage of software configuration management; it means managing the multiple releases of a system. A system release is a version of a software system that is distributed to customers. Release management sits at the commercial end of configuration management: version management tracks what exists, release management decides what reaches customers, when, and in what form.

For mass market software, it is usually possible to identify two types of releases:

14.18.2 What a Release Contains

A software product release is not just the executable code of the system. The release will also include many other items:

• Configuration files, for defining how the release should be configured for particular installations. Different customers may run the same release with different settings — data center vs small office, one database or another.
• Data files, such as files of error messages in different languages, which are needed for successful system operation. The executable is useless if its supporting data does not ship with it.
• An installation program, used to help install the system on the target hardware. The installer is part of the release, not an afterthought.
• Electronic documentation as well as paper documentation, including user manuals for the system.
• Packaging and associated publicity, designed for that particular release or patch, whether it is major or minor. Even a free patch ships in packaging that identifies it.

Preparing and distributing a system release for mass market products is an expensive process. In addition to the technical work involved in creating a release distribution, advertising and publicity material have to be prepared, and marketing strategies may have to be designed to convince customers to buy the new release of the system. The release is a product in the commercial sense — its cost includes not only engineering but also packaging, advertising, and sales support.

Careful thought must be given to the release timing. If the releases are too frequent, or require hardware upgrades, customers may not move to the new release, especially if they have to pay for it. If the system releases are infrequent, few and far between, market share may be lost as customers move on to alternative systems.

14.18.3 Factors That Decide Release Timing

The technical and organizational factors to take into account when deciding when to release a version of a software product:

The four factors pull in different directions — competition pushes release dates earlier, marketing may pin them to a calendar, platform changes force them, and technical quality decides whether a fix waits for a release or rides an emergency patch. Release timing is a balancing act across all four, not the result of any single rule.

14.19 Release Creation and Release Documentation

14.19.1 The Release Creation Steps

Once you decide to create a release, release creation is the process of creating the collection of files, documentation, and versions of the components that are to be included in the system release. The release creation process includes several steps:

The ordering matters: tagging comes first because everything else — configuration descriptions, manuals, installer scripts, web pages — must describe that exact set of components; the master image comes last because it can only be assembled once all its parts exist and match.

14.19.2 Releases for Custom Systems

For custom software or software product lines, the complexity of the system release and management process depends on the number of system customers. The release model scales with customer diversity: a single product with a million customers needs a handful of releases; a product line with fifty customers may need fifty.

Special releases of the system may be required or produced for each customer, and individual customers may be running several different releases of the system at the same time, on different hardware. When the software is part of a complex system of systems, several different variants of the individual systems may have to be created.

14.19.3 Documenting Releases for Long-Lived Systems

When a system release is produced, it must be documented to ensure that it can be recreated exactly the same way as it is installed at the customer site in future. This is particularly important for customers' long-lifetime embedded systems, such as defense systems and those that are used in controlling very complex machinery. These may have a long lifetime, 30 years or more, and the customers may use a single release of these systems for many years and may require specific changes to that release long after it has been superseded or is no longer available.

The documentation must answer one question, years later: given a customer's exact installed system, can we rebuild it byte-for-byte? That requires:

To document a release, you have to record the specific versions of the source code components that were used to create the executable code. You must keep copies of the source code files, the corresponding executables, and all data and configuration files. It may be necessary to keep copies of the older operating systems and other support software, because they may still be in operational use in the organization. Fortunately, this no longer means that the older hardware has to be maintained: the older operating systems can be run on a virtual machine — the 1998 operating system runs inside a 2026 server with no original hardware needed.

You should also record the versions of the operating systems, the libraries, the compilers, and the other tools used to build the software, because these tools may be required in order to build exactly the same system at some later date. Accordingly, you may have to store copies of the platform software and the tools used to create the system in the version control system, along with the source code of the target system. The version control repository becomes the time capsule of the whole engineering environment, not just the application code.

14.20 Release Installation and Software as a Service

14.20.1 The Data File Scenario

When planning and installing new system releases, you cannot assume that the system customers will always install new system releases. Some system users may be happy with an existing system and may not consider it a worthwhile effort to absorb the cost of changing to a new release, because they are happy with the older release. So new releases of the system cannot rely on the installation of previous releases.

14.20.2 Software as a Service

One benefit of delivering software as a service, or SaaS, is that it avoids all of these problems. It simplifies both release management and system installation for customers. With SaaS, there is no "installation" at the customer site at all: the software runs on the provider's servers, so the release problem moves from thousands of customer machines to a set of servers the provider controls.

The software developer is responsible for replacing the existing release of a system with a new release, which is made available to all customers at the same time. Every customer gets the new release simultaneously — no version fragmentation, no customers stuck on release 1 while release 3 is current, no data files that exist on some sites and not others. In one stroke, the entire data file scenario dissolves.

However, this approach requires that all servers running the services be updated at the same time. The simultaneity that solves the customer-side problem creates a provider-side problem: if server A runs release 3 while server B still runs release 2, different customers see different versions of the service — exactly the fragmentation SaaS was meant to eliminate. To support server updates, specialized distribution management tools, such as Puppet, have been developed for pushing new software to the servers. Puppet-class tools manage server fleets as configurations: the operator declares the desired state (release 3, this configuration), and the tool pushes it to every server, verifies it, and reports back — making a fleet-wide update a single coordinated operation rather than a login-and-update-by-hand exercise.

The comparison is stark: with installed software, a release reaches customers one upgrade decision at a time, over years; with SaaS, a release reaches every customer in one coordinated push — and the price is that the push must be perfect, because it happens to everyone at once.

14.21 Summary: The Configuration Management Picture

14.21.1 The Four Processes Recapped

Configuration management is the management of an evolving software system. When maintaining a system, a system team is put into place to ensure that the changes are incorporated into the system in a controlled way, and that records are maintained with details of the changes that have been implemented. The main configuration management processes are version control, system building, change management, and release management — the same four activities introduced in topic 14.2, now seen with the full machinery each one involves:

The four processes form the loop drawn at the start of the lecture: change proposals enter change management, approved changes become new component versions under version control, system building assembles them into system versions, and release management decides which system versions reach customers — whose feedback then generates the next change proposals. Configuration management is, in one sentence, the discipline that keeps that loop controlled and its history recorded.

14.21.2 Where to Go Next

To learn more about software configuration management, useful resources include the book Configuration Management Best Practices published by Addison-Wesley — a broad, practical treatment that also covers hardware configuration management and large systems — a Git and Subversion comparison (a widely referenced wiki comparison of the two version control systems), the book Software Configuration Management Patterns: Effective Teamwork, Practical Integration, and writing on Agile Configuration Management for Large Organizations — a web article describing configuration management practices for agile development at scale. All four resources approach the same discipline from different angles: the best-practices book for the big picture, the Git/SVN comparison for tool choice, the patterns book for teamwork practices, and the agile article for how the practices scale to large companies.

Together with this lecture, those resources complete the picture: configuration management is not a department or a phase — it is the controlled, recorded management of an evolving system, exercised through version control, system building, change management, and release management, every day of the system's life.

Exam Guidance Summary

• Exam note: You need to broadly understand the configuration management process and the activities involved in the configuration management of a large system, to be able to answer questions in the exam. Know all four activities: version management, system building, change management, and release management, and how they fit together. Expect questions that ask you to define an activity, name its inputs and outputs, or trace a change through the process — the ability to explain how the four activities connect is the strongest single preparation.
• Exam note: This topic comes from the textbook chapter on configuration management in Pressman's Software Engineering, Indian Edition, 8th edition, where configuration management is covered in a separate chapter, alongside other chapters on managing software projects. Work through that chapter — the definitions, the activity model, and the terminology there match what the exam asks.
• Exam note: Review the slides on configuration management and prepare yourself for the upcoming examination. The slides carry the diagrams (the activity chain, codelines and baselines, the continuous integration cycle) that tie the verbal explanations together.
• Exam note: Quiz 3 will be uploaded shortly, and an announcement will be made about it. Watch for the announcement so you take the quiz while the material is fresh.

Key Industry Applications

• Real-world: Subversion (SVN) is a widely used centralized version control system; Git is a widely used distributed version control system. Both are used across the software industry for version management — from small start-ups to large enterprises, virtually every professional software organization runs on one of these two models.
• Real-world: Jenkins is a widely used tool that supports continuous integration, building a system as soon as a developer completes a repository update — the automation that makes the seven-step continuous integration cycle practical on real teams.
• Real-world: Build systems integrate with test automation tools such as JUnit to check that a build has not been broken by changes — the test-automation feature of build tools in everyday practice, and a standard part of CI pipelines.
• Real-world: Large configuration management suites such as Rational ClearCase automate the change management process, from the initial customer proposal to approval by the change control board — the integrated alternative to simple issue trackers in big, formal organizations.
• Real-world: Distributed version control is essential for open source development, where developers push to public repositories and an integration manager pulls accepted changes into the definitive baseline — the model behind every major open source project, from the Linux kernel to web frameworks.
• Real-world: Specialized distribution management tools such as Puppet push new software to servers, supporting software-as-a-service (SaaS) delivery where all customers get the new release at the same time — how modern cloud services roll out updates to entire server fleets in one coordinated operation.
• Real-world: Configuration management standards support quality certification under ISO 9001 and the Software Engineering Institute's Capability Maturity Model (CMMI), with generic standards such as IEEE 828-2012 tailored into company-specific standards — the compliance path used by organizations that must show controlled development.
• Real-world: Defense and long-lifetime embedded systems may stay on a single release for 30 years or more; releases must be documented so they can be recreated exactly, and older operating systems can be kept running on virtual machines — the extreme end of release documentation, where old platforms are preserved in software instead of hardware.