CI/CD Engineering Should Be Taught as an Engineering System — Not Just a Pipeline

Continuous Integration and Continuous Delivery have become central to modern software engineering. Yet, in many learning environments, CI/CD is still introduced mainly through tools: configure a pipeline, trigger a build, run a few tests, and deploy an application.

That is useful — but it is not enough.

Real-world software delivery is much broader.

A delivery system is shaped by architecture, source-control strategy, build engineering, test architecture, security, infrastructure, deployment, observability, engineering economics, team practices, and continuous learning. A pipeline is only one visible part of that larger system.

This is the thinking behind a university elective I have been developing:

CI/CD Engineering: Principles, Practices & Anti-Patterns

The objective is not to teach students how to operate a particular CI/CD tool. It is to help them learn how to reason about software delivery as an engineering system.

Why another course on CI/CD?

Students today may already encounter DevOps, software testing, cloud computing, software engineering, Git, containers, automation, and related technologies during their education.

The challenge is that these subjects are often learned separately.

In industry, they do not operate separately.

A poor architectural decision can create a slow build.

A slow build can reduce integration frequency.

Reduced integration frequency can increase change size.

Larger changes can create longer feedback cycles.

Weak test architecture can create unreliable confidence.

Flaky tests can cause teams to ignore failures.

Weak observability can prevent teams from understanding what happens after deployment.

And eventually, a technically “green” pipeline may still produce a release that nobody is confident enough to deploy.

This interconnected nature of software delivery is what the course is designed to explore.

Learning through anti-patterns

One of the key teaching approaches is the use of CI/CD engineering anti-patterns.

Instead of starting only with ideal practices, students begin with a recognizable engineering problem.

• Why are developers integrating only once every few days?
• Why does a pipeline take several hours?
• Why are hundreds of tests executed for a very small code change?
• Why does the build remain green even though critical quality evidence is missing?
• Why are flaky tests repeatedly rerun rather than fixed?
• Why are security and non-functional testing performed only toward the end of a release?
• Why does deployment still require extensive manual intervention despite significant CI investment?

These are not simply tool problems.

They are symptoms of deeper engineering-system conditions.

The learning model therefore follows a simple progression:

Recognize → Diagnose → Transform → Measure

Students first recognize the observable failure pattern.

They then diagnose the underlying causes using engineering evidence.

Next, they design an appropriate transformation.

Finally, they define how improvement should be measured.

The intention is to build diagnostic thinking rather than encourage memorization of tools, commands, or anti-pattern names.

What does the course cover?

The proposed elective is organized into five broad academic units.

1. Foundations of Continuous Engineering

Students begin by examining CI/CD as an end-to-end engineering capability. Topics include engineering intent, measurable outcomes, planning, solution slicing, CI architecture, architecture runway, and the fundamentals of anti-pattern-based reasoning.

2. Architecture, Source Control and Integration Flow

This section looks at architecture-aware pipelines, component boundaries, build graphs, staged pipelines, selective execution, branching strategies, trunk-oriented development, integration cadence, sources of truth, and the important concept of a Definition of Green.

3. Quality Engineering and Test Architecture

Testing is treated as an architectural capability rather than simply a pipeline stage. Students explore shared quality ownership, the test pyramid, accidental test pyramids, flaky tests, coverage versus test sufficiency, non-functional testing, and measurable quality feedback.

4. Secure Delivery, Infrastructure and Operations

Continuous engineering must also include infrastructure, security, and software supply-chain evidence.

Topics include Infrastructure as Code, environment reproducibility, static-analysis governance, security and safety integration, SBOM, open-source governance, deployment automation, approval strategies, rollback, recovery, and configuration management.

5. Observability, Economics, AI and Continuous Improvement

The final unit extends CI/CD into telemetry, value-stream thinking, flow and queue analysis, engineering cost, technical debt, AI-assisted engineering, comprehension debt, experimentation, learning systems, and continuous improvement.

Learning should produce engineering evidence

A course like this should not end with students simply demonstrating that a pipeline executes successfully.

Students should be able to explain:

• Why was the pipeline designed this way?
• What evidence is required before a change can progress?
• How does the architecture influence CI?
• Where are the major feedback delays?
• What should run immediately after a developer change?
• What can run later?
• How is risk incorporated into test strategy?
• How do we know whether delivery performance is actually improving?

This is why the proposed course includes hands-on diagnostic exercises.

Students work with a deliberately imperfect software project and delivery workflow. Across the semester, they build evidence about that system and gradually improve it.

Typical exercises include:

• Baselining a repository and identifying delivery anti-patterns
• Modelling component dependencies and the CI build graph
• Designing staged pipelines
• Defining stage-specific Definitions of Green
• Analysing and restructuring test architecture
• Investigating flaky tests
• Integrating static-analysis governance
• Generating and examining SBOM evidence
• Improving environment reproducibility
• Adding delivery telemetry
• Studying feedback time, queues and failures
• Designing deployment, rollback and recovery mechanisms

The capstone: Diagnose and Transform a Software Delivery System

The semester culminates in a practical capstone.

Student teams analyse an imperfect software-delivery system and work through a complete engineering improvement cycle:

Baseline → Recognize → Diagnose → Prioritize → Transform → Measure → Defend

The expected outputs include a current-state delivery architecture, anti-pattern evidence, a prioritized improvement backlog, a target CI/CD architecture, Definition of Green, quality/security/observability strategy, an improvement measurement plan, and a final technical defense.

This is important because industry rarely presents engineers with perfectly defined problems.

Engineers need to examine incomplete evidence, understand constraints, identify systemic causes, make trade-offs, and defend their decisions.

That is the capability the course is intended to develop.

Where does AI fit?

AI-assisted engineering is becoming part of software-development workflows, so it should also become part of how we teach modern software engineering.

The course therefore allows students to explore AI for areas such as requirements clarification, code review, test generation, pipeline analysis, and technical documentation.

But AI assistance does not remove engineering accountability.

Students must validate generated outputs, understand the resulting system, and retain responsibility for quality, security, and technical decisions.

An important concept here is comprehension debt: what happens when the velocity of generating or changing software increases faster than the engineering team's understanding of that software.

As AI accelerates engineering work, this question will become increasingly important.

Tool-agnostic by design

Universities should be able to use GitHub, GitLab, Jenkins, Azure DevOps, open-source tooling, or whatever platforms are appropriate for their environment.

The engineering concepts should remain stable even as tools change.

Students should therefore be assessed primarily on the quality of their engineering decisions and evidence — not their ability to memorize vendor-specific commands.

From industry experience back into academia

This course proposal is connected to my broader work on CI/CD Engineering Anti-Patterns, which organizes recurring software-delivery failure modes into 45 anti-patterns across 10 engineering themes.

The book provides the detailed practitioner cases and engineering patterns, while the university course converts those ideas into a more conventional academic structure with learning outcomes, laboratories, assessment, outcome mapping, and a semester-long capstone.

My objective is to help strengthen the bridge between what students learn about software engineering and the complex delivery systems they will encounter in industry.

CI/CD should not be understood merely as automation around a source-code repository.

It is an engineering system.

And learning how to diagnose and continuously improve that system is becoming a fundamental software-engineering capability.

Feedback and collaboration

I would especially welcome feedback from faculty members, university curriculum boards, software-engineering practitioners, DevOps/platform leaders, researchers, and students.

If you are involved in software-engineering education and believe this could be useful as an elective, industry course, faculty-development programme, or postgraduate module, I would be glad to hear your perspective.

Are we teaching CI/CD as a collection of tools — or are we preparing engineers to understand and improve the complete software-delivery system?