Module 1: DevOps Foundations

What DevOps Actually Means

Ask ten people what DevOps is and you may get ten answers: a job title, a set of tools, a team, a pipeline. That confusion costs organisations money, because they buy tools or rename a team and then wonder why nothing improves. Before you learn any practice in this course, you need a clear, working definition you can explain to a manager, a developer and a system administrator alike.

Where the word came from

The term grew out of the operations and agile communities around 2009. Patrick Debois organised the first DevOpsDays conference in Ghent, Belgium, that year, and the name stuck. In the same period, engineers at large web companies were talking publicly about deploying many times a day instead of a few times a year. The common thread was frustration: agile methods had made development teams faster, but releasing software to production was still slow, manual and risky, because operations work had not changed.

So DevOps began as a response to a real problem: the gap between writing code and running it reliably for customers.

A working definition

A practical definition you can use is this:

DevOps is a way of working in which the people who build software and the people who run it share responsibility for delivering value to users quickly, safely and reliably, supported by automation, measurement and continuous learning.

Notice what is in that sentence and what is not. It talks about people, shared responsibility, flow of value, safety and learning. It does not name a tool. Tools matter a great deal, and you will meet many of them, but they serve the way of working rather than define it.

A useful summary of the parts of DevOps is the acronym CALMS, popularised by Jez Humble and others:

If an initiative only touches one letter, usually Automation, it is incomplete.

Worked example: two release days

Consider a hypothetical Nairobi fintech that runs a mobile lending app. Under its old model, developers finish features over six weeks and hand a large release package to the operations team on a Friday. Operations reads an instruction document, runs database changes by hand and restarts servers late at night. On one release, a configuration value for the M-Pesa callback URL is wrong. Customers repay loans but their balances do not update. Developers say the code was fine; operations says they followed the document. It takes most of Saturday to find the cause, and nobody owns the fix.

Now picture the same company after adopting DevOps practices:

1. Changes are small and merged into the main branch daily, with automated tests running on every change.
2. Configuration, including the callback URL for each environment, is stored in version control and reviewed like code.
3. A pipeline deploys the same tested package to a staging environment, then to production during working hours.
4. Dashboards show repayment processing rates, and an alert fires if callbacks start failing.
5. The developer who made the change and an operations engineer watch the release together and can roll back in minutes.

The wrong URL would most likely be caught in review or staging. If it slipped through, the alert would surface it within minutes, and rollback would be one command. No single tool made the difference; the combination of shared ownership, automation, small changes and monitoring did.

Common mistakes to avoid

• Treating DevOps as a job title only. Hiring a "DevOps engineer" and expecting them to fix delivery alone often creates a new silo between developers and operations.
• Buying tools first. A pipeline tool will automate a broken process just as faithfully as a good one. Understand the flow of work first.
• Ignoring operations knowledge. DevOps does not mean developers replace operations. Skills in networking, security, capacity and reliability remain essential and must be shared.
• Measuring activity instead of outcomes. Counting builds or tickets closed says little. Measure how quickly and safely value reaches users.

Throughout this course you will build on this definition. Each later lesson adds one practice, and each practice should connect back to the same goal: faster, safer delivery of value with people who share responsibility for the result.