Configuration Management Tools: Version Control, Build Systems, and CI/CD Pipelines

UPI Study › Courses › Software Engineering › Free lessons › Lesson 14.5 Free with a free account

Configuration Management Tools: Version Control, Build Systems, and CI/CD Pipelines

Software Engineering · Chapter 14: Project Estimation, Configuration, and Change ControlSection 14.5 · lesson 90 of 1036 min · free with a free account

← Configuration Management ProcessesNext lesson: Tracking Control Items and Procedures in Configuration →

Earn 3 college credits for Software EngineeringRecommended for credit by NCCRS · Computer Science 301 · self-paced · one payment, lifetime access

In this lesson

Version control, build systems, and CI/CD pipelines - policy that enforces itself.

  • Explain why an SCM plan needs tooling at real scale
  • Describe commits, branches, and merges in version control
  • Explain why automated builds are a form of configuration control
  • Describe what CI and CD each add to the pipeline

Transcript

Everything said in the video, section by section (711 words). Read along, or search it.

Project Estimation, Configuration, and Change Control

Configuration Management Tools

An S C M plan describes what should be controlled, and when change is allowed. None of that holds up in practice without tools doing the enforcing. This section covers the tooling that turns configuration management from a policy on paper, into something that happens automatically.

From Policy to Tooling

Rules Nobody Has to Remember

The S C M plan and its scheduling policies describe what should happen. But at real project scale, none of it is reliable if it depends on everyone remembering to follow the rules manually. Three kinds of tool make configuration control practical. Version control. Build automation. And pipelines that chain them together with testing, into one continuous flow.

Version Control

Tracking Every Change

A version control system tracks every change made to a set of files over time. It records who changed what, and why, and makes it possible to recover any prior state. That turns a configuration item into something genuinely trackable and auditable. A commit is a recorded snapshot of a specific set of changes, with a description of what changed. A branch is a parallel line of development, so work can proceed on a change without disturbing the shared line until it is ready. And a merge combines changes from different branches back into one.

Build Automation

Source Into Something Runnable

Build automation assembles source code and other configuration items into a runnable form. It does that through a consistent, repeatable, defined process, rather than someone manually running the right steps in the right order. That removes a whole category of problems caused by inconsistent manual builds. A defined, automated build runs the same way every time, for everyone. And that is itself a form of configuration control. It guarantees reproducibility, which an S C M plan exists to protect.

CI/CD Pipelines

Chaining It All Together

A C I C D pipeline chains version control, automated builds, and automated testing into one continuous flow. Continuous integration is the automatic build-and-test step that runs every time code is merged. Continuous delivery, or deployment, extends that same pipeline further. It automatically prepares, or actually releases, a build that passes every check. Earlier material on continuous integration set aside the specific tools and pipelines that make this happen. This is that topic.

Figure 1

The Full CI/CD Pipeline

Here is the full pipeline. A commit is recorded in version control. The build is assembled automatically. Then automated tests check it. Commit, build, and test, repeated on every merge, is continuous integration. Continuous delivery or deployment extends the same flow through to deploy. And each stage runs automatically, without waiting for someone to remember to trigger it.

Table 1

Tools and Their Configuration Role

Here are the three kinds of tool, and the role each plays in configuration control. Version control tracks every change to files over time. It makes configuration item tracking and history possible at all. Build automation assembles source into a runnable form, consistently. It ensures reproducible, defined builds, instead of manual steps. And a C I C D pipeline chains version control, build, and test into one flow. It enforces the S C M plan's policies automatically, every time.

Apply It

The Build on 1 Laptop

Let's apply that. A team's release builds are made by hand, on one senior developer's laptop. One week, a build ships missing a configuration file. And nobody can reproduce exactly what went out. Build automation would have made every build defined and reproducible. And a pipeline would run that build the same way on every merge, and test it, before anything ships.

Key Terms

The Vocabulary of This Section

Let's lock in the key terms. A version control system is software that tracks every change to a set of files over time, and allows any prior state to be recovered. A commit is a recorded snapshot of a specific set of changes, along with a description of what changed. Build automation is a consistent, repeatable, automated process for assembling source code into a runnable form. And a C I C D pipeline is an automated flow chaining version control, build, and test, and often delivery, into one continuous process.

Key Takeaways

What to Carry Forward

To pull this together. Tooling is what actually enforces an S C M plan's policies at real project scale. In version control, commits record changes, branches separate lines of work, and merges combine them. Automated builds guarantee reproducibility. Continuous integration builds and tests every merge. Continuous delivery extends the same pipeline through to release. And a policy built into a pipeline is far stronger than one that people have to remember.

About Software Engineering at UPI Study

Software Engineering (Computer Science 301) is a self-paced online course of 103 video lessons in 15 chapters, from process models and agile to requirements, design, user interfaces, reliability, security and project management. It carries a NCCRS credit recommendation for 3 semester credits.

Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Compare: Software Engineering vs Systems Analysis

Why take it here

Why students take Software Engineering with UPI Study

How professional software gets builtSoftware Engineering covers how teams turn requirements into working, maintainable software: process models, agile, requirements, design, testing, reliability and project management. It is a core course in computer science and software degrees.
Credit at a fraction of the priceThe same 3 credits can cost $750 or more at a US college. Here it is one payment, self-paced, with lifetime access.
Finish your degree soonerTransfer credits reduce the courses you still owe, so you can graduate earlier or lighten a heavy semester.
Strengthen an applicationA completed college-level course on an official transcript shows admissions and scholarship committees you can do the work.
Study on your own scheduleNo start dates, no deadlines. Watch the lessons, practice, and take the final when you are ready.
130,000+students helped with college creditsACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Where the credit goes

Universities that work with NCCRS

Software Engineering carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.

FAQ

Questions students ask us

About Configuration Management Tools: Version Control, Build Systems, and CI/CD Pipelines

What are commits, branches, and merges in version control?
A commit is a recorded snapshot of a specific set of changes with a description of what changed. A branch is a parallel line of development, letting work on a change proceed without disturbing the shared line until it is ready. A merge combines changes from different branches back into one. Together they let a version control system track every change and recover any earlier state.
What is the difference between continuous integration and continuous delivery?
Continuous integration is the automatic build-and-test step that runs every time code is merged, while continuous delivery extends the same pipeline to automatically prepare a build that passes every check for release. Continuous deployment goes one step further and actually releases it. Both rely on a CI/CD pipeline that chains version control, automated builds, and automated tests.
Why is build automation considered a form of configuration control?
Build automation is a form of configuration control because it guarantees reproducibility, which an SCM plan exists to protect. A defined, automated build assembles source code the same way every time, for everyone. Manual builds, such as release builds made by hand on one developer's laptop, can ship missing a file and leave nobody able to reproduce exactly what went out.
Why does configuration management need tools instead of manual rules?
At real project scale, an SCM plan is unreliable if it depends on people remembering to follow rules by hand. Version control, build automation, and CI/CD pipelines enforce its policies automatically on every change and every merge. A policy built into a pipeline runs whether or not anyone remembers it, which makes it far stronger than a rule written only on paper.

About the Software Engineering course

How many college credits is Software Engineering?
Software Engineering (Computer Science 301) carries a NCCRS credit recommendation for 3 semester credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
How much does Software Engineering cost and what is included?
$250, paid once, with lifetime access: all 103 video lessons, a practice quiz after each, the graded work and final exam, and an official transcript when you finish. Students who want several courses choose UPI Study PRO instead.
Which universities accept UPI Study credits?
UPI Study has signed partner agreements with universities such as Thomas Edison State University, University of the People and Charter Oak State College, and works with universities such as Penn State, SNHU and SUNY. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities. Use "Find my college" on this page to check yours.
How long does Software Engineering take?
It is self-paced with no deadlines. The 103 lessons total about 11 hours of video; most students add reading and practice time and finish in a few weeks to a few months, on their own schedule.
How are the exams done?
Quizzes and assignments are online in the course. The final exam is taken online with proctoring; a person on the UPI Study team checks assignments, usually within two days.
How do my credits reach my college?
When the course shows 100% complete, request the official transcript from your dashboard. It is sent to the college you name, and you can send it to more than one. Check your college first with "Find my college" on this page, or ask Athena.

Ready for the full course? Earn 3 credits in Software Engineering.

103 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.

Software Engineering
3 credits · NCCRS
Enroll →