If you have made it this far, it is because at some point you have lived through — or been told about — a scene like this one: Friday afternoon, someone builds the project on their laptop, uploads the files to a server and crosses their fingers. This lesson is the starting point for leaving that scene behind. We are going to define precisely what the acronym CI/CD means, distinguish the three practices hiding behind it (because there are three, not two) and settle the vocabulary we will use throughout the course. This is not a lesson about tools or configuration: it is the lesson that makes everything else make sense. If you confuse Continuous Delivery with Continuous Deployment — the industry's most common mistake — the rest of the course will sound like noise. By the end, you will be able to name every piece of the process and you will understand why the team behind our example project, Reservalia, has a serious problem.

1. The problem CI/CD sets out to solve
2. What continuous integration (CI) is
3. What continuous delivery is
4. What continuous deployment is
5. The two "CD"s head to head
6. The full flow: from commit to production
7. Core vocabulary for the course
8. Common mistakes and tips
9. Exercises
10. Conclusion

Throughout the course we will work on a fictional project called Reservalia, a SaaS appointment booking platform for small businesses: hair salons, dental clinics, car repair shops. The team is small: Marta (tech lead), Diego (backend developer) and Nuria (SRE). We will look at it in detail in lesson 01-04; for now all that matters is how they work today:

• Diego builds on his laptop. The version of Node he has installed is not exactly the one on the server.
• He uploads the resulting files over SFTP to a single production server.
• He runs the database migrations by hand, pasting SQL into a psql console.
• Tests are run "whenever someone remembers".
• All of this happens on Friday afternoons and takes about 3 hours.
• The result: two serious production incidents last quarter.

This process is not bad through carelessness: it is bad by design. Every one of those steps depends on one specific person, at one specific moment, not making a mistake. And people do make mistakes.

There is a second problem, less visible but just as expensive. Imagine Marta and Diego each work on their own branch for two weeks:

• Marta rewrites the email notification system.
• Diego changes the appointment data model to support recurring bookings.

Neither of them touches the other's work, apparently. But the day they try to merge both branches, conflicts appear in 40 files, the signature of a function they both use has changed, and Marta's tests fail because of a schema change Diego made. What should have been an afternoon turns into three days of "sorting out the integration".

That is integration hell: the cost of merging grows non-linearly with the time branches live apart.

The key intuition, which will come back again and again in this course: if something hurts, do it more often. Merging hurts because you do it rarely. Deploying hurts because you do it rarely. The counter-intuitive answer from CI/CD is to increase the frequency until each individual operation becomes trivial.

Definition. Continuous integration is the practice whereby every team member integrates their work into the mainline at least once a day, and every integration is verified automatically by a build-and-test process that runs in a clean, shared environment.

There are three ideas inside that definition, and all three matter equally:

1. Integrate often. Each person's code returns to the main branch within hours, not weeks. If your branch lives for three weeks, you are not doing CI even if you have a CI server configured.
2. Verify automatically. Merging is not enough: an automated system builds, runs the tests and checks quality. Without automated verification, integrating often just means breaking the main branch more often.
3. In a clean, shared environment. Not on Diego's laptop. On a machine that starts from scratch every time, so that "it works on my machine" stops being a valid sentence.

It is worth defusing three very widespread misunderstandings:

When a team genuinely adopts CI, it signs an unwritten contract:

• The main branch is always healthy. If the build is red, fixing it is the team's number one priority, above any feature.
• Nobody goes home with a broken build. The change is reverted and investigated calmly the next day.
• Every change is verified before it is integrated, not after.

Without that contract, automation turns into a traffic light everyone ignores. We will come back to this in module 2.

Definition. Continuous delivery is the practice of keeping software always in a deployable state, so that any version that has passed the pipeline can be taken to production at the push of a button, at any moment, with a known level of risk.

Continuous delivery takes continuous integration for granted and adds a layer on top: it is not enough for the code to build and pass the tests; there must be an artifact that is built, versioned, tested in production-like environments and ready to deploy.

The key phrase is "at the push of a button". In continuous delivery:

• The technical process of deploying is fully automated.
• The decision to deploy is still human.

That human decision is not a flaw in the system: it is a deliberate choice. There can be perfectly legitimate reasons not to deploy automatically:

• A marketing campaign that starts on Tuesday, with a feature that must not be visible before then.
• A regulatory compliance requirement demanding recorded approval.
• A team that does not yet trust its test suite enough.

What matters is that, when someone decides to deploy, there is no manual work to do: only to authorise it.

Definition. Continuous deployment is the practice whereby every change that passes the automated pipeline is deployed to production automatically, with no human intervention.

It is continuous delivery without the button. The manual gate is removed: if the pipeline is green, the change reaches users. No meetings, no deployment windows, no Friday afternoons.

This sounds reckless and, without solid foundations, it is. Continuous deployment only works if it rests on:

• A test suite the team genuinely trusts (module 2).
• Progressive deployment strategies — canary, blue-green — to limit the blast radius (module 3).
• Feature flags to separate "deploying code" from "enabling a feature" (module 3).
• Automatic rollback when metrics degrade (module 3).
• Monitoring that spots the problem before the customer does (module 3).

Note something important: continuous deployment is not a mandatory goal for every team. It is an option. A great many excellent organisations deliberately stop at continuous delivery. What is non-negotiable is the ability to deploy at any moment; whether you use it automatically or not is a decision that depends on context.

Here is the core of the lesson. The CI/CD acronym is deliberately ambiguous, and that causes constant confusion in interviews, documentation and team conversations.

One way of remembering it that works very well:

• Delivery = "we can deploy whenever we want" → the capability is automated, the decision is human.
• Deployment = "we deploy whenever the pipeline allows it" → the decision is automated too.

And an inclusion relationship worth committing to memory:

Read it from the bottom up: there can be no continuous deployment without continuous delivery, and no continuous delivery without continuous integration. Any attempt to skip a rung produces a fragile system. If Reservalia tried to deploy automatically to production tomorrow without reliable tests, it would not have two incidents per quarter: it would have two per week.

Let us look at the journey a change of Diego's will make over the whole course. This diagram is the mental map of the entire course:

Read the diagram by identifying where each practice fits:

• From A to E (commit → build → test): this is continuous integration. We will build it in module 2.
• From F to I (artifact → registry → dev → staging): this is continuous delivery. Modules 2 and 3.
• The step J → L with no human intervention: this is continuous deployment. Module 3.
• M and N (monitoring and rollback): the safety net that makes all of the above possible. Module 3.

Let us now settle the terms. We will use them without defining them again, so this section is worth reading carefully. I have grouped them into families.

One detail we will use a great deal: the commit SHA is the canonical identity of a change. When we ask ourselves in module 3 "which exact version is in production?", the correct answer will never be "the latest one", but a specific SHA.

The hierarchy, visually:

There is a distinction about runners that will matter a great deal later on:

• Ephemeral: created clean for every job and destroyed when it finishes. It guarantees repeatability. It is the default model in GitHub Actions.
• Persistent: a machine reused across runs. It is faster (it keeps caches) but it accumulates state, and that state is a classic source of builds that "only work the second time". Typical of old Jenkins installations.

The last two deserve elaboration, because they are the most widely misunderstood.

Promotion: build once, deploy many times. This is one of the golden rules of CI/CD. The artifact tested in staging must be the very same binary that reaches production, byte for byte. If you rebuild for production, you are deploying something nobody has ever tested.

And what not to do:

If the artifact is the same in all three environments, how does the configuration change then? From the outside: environment variables and secrets injected at deployment time. The artifact does not know which environment it lives in.

Reproducible build. Two builds of the same commit giving the same result is not automatic: you have to earn it. The usual enemies are:

• Unpinned tool versions (plain node instead of node@20.11.0).
• Dependencies with no lock file, which resolve to the latest available version.
• Installing with npm install (which can modify the lock) instead of npm ci (which respects it strictly).
• Timestamps or absolute paths baked into the artifact.

This is exactly Diego's problem: he builds on his laptop, with his version of Node and his node_modules accumulated over months. His build is not reproducible, and that is why nobody can rebuild what is in production.

Mistake 1: believing that "CD" always means the same thing. When someone says "we have CI/CD", always ask: "is the production deployment triggered by a person or by the pipeline?". It is the only question that disambiguates. In a job interview, telling delivery apart from deployment and explaining why you would choose one or the other puts you ahead of most candidates.

Mistake 2: thinking CI/CD is a tool you install. GitHub Actions does not give you continuous integration, just as buying a pair of trainers does not make you fit. The tool executes; the practice is held up by the team. A team with three-week branches and a hugely expensive CI server is not doing CI.

Mistake 3: rebuilding the artifact for every environment. If the deploy to production compiles again, what reaches users is not what was validated in staging. Build once, promote the same artifact. We will formalise this in lesson 02-06.

Mistake 4: confusing deployment with release. Deploying is putting the code into production; releasing is enabling the feature for users. With feature flags you can deploy on Monday and enable on Thursday. They are two separate operations, and separating them reduces risk enormously. We will look at this in 03-05.

Mistake 5: using long-lived branches and calling it CI. If your branch has 60 commits and two weeks of life, you will integrate badly even with a thousand green tests. Integration frequency is the practice; tests are the mechanism.

Tip 1: start by measuring, not by automating. Before writing your first workflow, write down how long your deployment takes today and how many times a month it fails. Without a baseline you will not be able to show the investment was worth it. Lesson 01-05 is about exactly this.

Tip 2: the pipeline is production code. It lives in the repository, it is reviewed in pull requests and it is versioned like everything else. A .github/workflows/ci.yml edited by hand through a web interface is technical debt from minute one.

Tip 3: if it hurts, do it more often. This is the principle that sums up the entire course. Merges hurt because they are rare; deployments are scary because they are exceptional. Increasing frequency forces you to automate, and automating removes the pain.

For each situation, say whether it describes continuous integration, continuous delivery, continuous deployment or none of the three, and justify your answer in one sentence.

1. The team has a server that runs the tests every night at 3:00 against the main branch. Feature branches are merged every three weeks.
2. Every pull request triggers a build and tests in 6 minutes. If they are green, it can be merged. Deployments are still manual, over SFTP.
3. On merging to main, the pipeline builds a Docker image, deploys it to staging and runs smoke tests. Marta presses "Deploy to production" whenever she considers it appropriate.
4. On merging to main, the pipeline deploys to production for 5% of traffic, watches errors for 10 minutes and, if all goes well, completes the deployment. Nobody intervenes.
5. Diego builds on his laptop and uploads over SFTP on Fridays.

The following pseudo-script is Diego's manual process. Identify at least four reasons why the resulting artifact is not reproducible, and propose a fix for each one.

Write a mermaid diagram of Reservalia's target pipeline with these conditions, using the terms trigger, stage, job, artifact, environment and promotion correctly:

• It is triggered when merging to main.
• A verification stage with two parallel jobs: test-api and test-web.
• If both pass, one artifact is built, tagged with the commit SHA.
• The artifact is deployed to staging automatically.
• It is promoted to prod only after manual approval from Marta.

Solution to Exercise 1

1. None of the three. This is a nightly build. There is test automation, but branches live for three weeks: this is not continuous integration, it is late integration verified overnight. Verification arrives up to 21 days after the change that broke it.
2. Continuous integration. Every change is verified automatically before it is integrated and the feedback cycle takes minutes. There is no continuous delivery because there is no deployable artifact and no automated deployment: deploying is still a manual process.
3. Continuous delivery. The whole technical path to production is automated (build, artifact, staging, smoke tests) and only one manual gate remains: Marta's decision. This is the canonical example of delivery.
4. Continuous deployment. There is no human intervention between the merge and production. The essential safety net is there too: progressive deployment (5% canary) and automated verification before completing.
5. None of the three. This is manual deployment with late integration. It is Reservalia's starting point.

Solution to Exercise 2

Four would have been enough; if you found more, that is an even better sign.

Solution to Exercise 3

Points that had to appear and are worth checking in your version:

• The trigger is a repository event, not a manual action.
• test-api and test-web are parallel jobs inside the same stage, not separate stages.
• A single artifact is built, tagged with the SHA (not with the date, nor with "latest").
• What goes to production is the same artifact that was validated in staging: that is promotion, not a rebuild.
• The manual gate places this pipeline in continuous delivery. Remove that gate and it would be continuous deployment.

In this lesson we have laid the foundations of the course:

• The enemy has two faces: integration hell (merging late and all at once) and manual deployment (processes that depend on one person not making a mistake). Reservalia suffers from both.
• Continuous integration means integrating often and verifying automatically in a clean environment. It is a team practice before it is a tool.
• Continuous delivery keeps software always deployable: the process is automated and the decision is human.
• Continuous deployment removes that last manual gate, and it is only sensible with reliable tests, progressive deployment, monitoring and rollback.
• The three stack up: no deployment without delivery, and no delivery without CI.
• And we have a shared vocabulary: repository, commit, branch, trigger, pipeline, stage, job, runner, artifact, environment, promotion and reproducible build. Two golden rules we will repeat until the very end: build once and promote the same artifact, and pin versions so that the build is reproducible.

You now know what CI/CD is. Marta's logical question when she presents this to her team will be a different one: "and what does this give us, and what is it going to cost us?". Because setting up a pipeline is not free: it consumes configuration time, maintenance and execution minutes. In the next lesson, Benefits of CI/CD, we will look honestly at both sides of the scales: what a team like Reservalia's gains, how each benefit is measured, and in which situations CI/CD gives back less than it costs.