CI/CD Pipelines - Simply Explained

0:00 Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. A CI CD pipeline is a factory line for software, and once you see it that way, you can't unsee it. Raw material goes in at one end, a checked and packaged product comes out the other, and the same steps run in the same order every single time. What surprises people is that the pipeline was never really about speed, because the teams that shipped the fastest are also the ones who recover the fastest. Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. By the time we finish the four letters in C, CD will stop being jargon, and you will know what every stage of that line is actually checking what a pipeline actually is. Start with the plainest version of the word.

0:40 A pipeline is a fixed list of steps that a computer runs the same way every time somebody changes the software. That's the whole idea. The factory line comparison is worth stretching a little further. A unit that fails inspection gets pulled off the line instead of being quietly boxed up, and the line itself doesn't care who built the unit. Humans forget steps. We forget the boring ones, and we forget them late on a Friday. Which is exactly when a mistake is most expensive. The pipeline doesn't forget because the steps get written down once and then run in exactly the same way for every change after that. That consistency is what makes the setup worth it. Nobody has to remember the checklist by heart, and nobody has to guess. At the end of the day whether the last change was safe to ship. A pipeline isn't a tool you buy off a shelf. It's a habit with a machine attached, and the teams that get the most out of one usually changed how they work, rather than which software they installed.

1:25 There's a story from two thousand and nine that makes this real and will come back to it later. A company back then was pushing new code to its live website about fifty times a day, which sounds like it should have ended in disaster. For now, hold on to one thing the pipeline only makes sense once you know what it replaced and what it replaced. Was a process so painful that engineers still tell stories about it decades later. The problem it was built to solve. Go back to the nineteen eighties because the origin story explains the whole idea. A young Martin Fowler took a summer internship at a large electronics company, and his manager walked him through a huge, windowless warehouse full of programmers working in cubicles. The detail that matters most came next. Their code had been written for a couple of years, and by then the separate pieces were being merged together, and they had been merging for months.

2:05 Nobody really knew how long it would take to finish. That is the failure everyone was living with. And it has a name. Engineers call it integration hell, which is the point where putting everybody's work together takes longer than writing it did in the first place. The everyday version is smaller and much more familiar. Two people edit the same thing. One change lands first, and the second person spends an afternoon untangling work. That was perfectly fine that morning. The real cost isn't the merging itself, it's the timing. Because when the problem surfaces weeks after it was created, the person who created it has already forgotten what they were thinking. There's also a brutal little phrase in this world, which is that something worked on my machine. It means the software passed on one computer and failed somewhere else. And that sound is a manual process, quietly lying to you. So the fix was never a cleverer merge tool.

2:47 The fix was to integrate small pieces constantly, instead of one enormous piece at the end, and to let a machine check the result every single time. Fowler's description of a healthy team is almost boring to read, and that's the point. Any single developer's work is only a few hours away from the shared project, and it can be folded back in within minutes. The two numbers tell the story. Months of integration sit on one side, minutes sit on the other, and the only real difference is how often people did the merging and who was checking. Conflicts found within hours are cheap. Almost nothing has changed yet. The fix is small and the person still remembers why they wrote the line in question. Conflicts found weeks later are expensive because the surrounding work has moved on and you're rebuilding something you can no longer fully picture. If you build power apps or flows instead of writing code, this still lands on you every time you edit a solution that someone else is also editing.

3:34 You're living inside the same story just with a friendlier screen. That fix has a name, and the name comes first in the acronym. What continuous integration really means. Continuous integration is the first of the three words, and also the oldest. Continuous integration means everyone merges their work into the shared main copy at least once a day, and an automated build with tests checks it every time. Take the words apart because each half is doing a job. Continuous means all the time rather than once at the very end, An integration means combining your work with everybody else's. Martin Fowler, who wrote the canonical description of this, is strict about what counts. If any test fails, the build is red and the team stops to fix it because almost green is still red. That strictness isn't perfectionism for its own sake.

4:15 A red build that stays red as a pipeline nobody trusts, and a pipeline nobody trusts is one that people quietly work around. The daily part is doing more work than it looks like. A change that sits alone for a week is a change nobody else can see. And surprises are exactly what break a release on the night it matters most. One more piece of the habit is easy to overlook. The build has to be fast. A check that takes an hour is a check people stop waiting for, and a check nobody waits for might as well not exist. In nineteen ninety one, Grady Booch proposed the term continuous integration. Extreme programming made it a core practice in nineteen ninety seven and the first well-known open source tool for it, cruise control, arrived in two thousand and one. None of this needs a fancy product, either. The core of continuous integration is a shared main copy, a build that tests itself and the discipline to fix it.

4:58 At the moment it breaks. Integration is only the first part of the story, though. The other two words in the acronym are the ones people actually confuse, and they're worth pulling apart on their own. Delivery versus deployment. Two words, one letter apart, and most explanations blur them together. Delivery and deployment aren't the same thing, and the difference decides what your pipeline is allowed to do on its own. Continuous delivery means the software is always in a state where it could be released on demand. Whenever the team chooses, you keep the button available and press it when the business is ready, which might be today and might be next month. Continuous deployment goes one step further. Every change that passes the pipeline goes live automatically, and nobody pushes anything because the pipeline already did. The line between them fits in one breath delivery means you can deploy at any time, and deployment means you actually do every time a change gets through.

5:43 There's a practical way to feel the difference. A team doing continuous delivery could ship right now, but is holding for a launch. A team doing continuous deployment has emerged. Change live before lunch and nobody had to announce it. Fowler offers a test that cuts through any argument about labels. Ask whether a business sponsor could request that the current version go live at a moment's notice, and nobody would panic. If the answer is yes, you have delivery. The order only runs one way. You can't automate a release that isn't ready. So continuous deployment needs continuous delivery first, and delivery needs that daily integration habit underneath it. There's a reason teams bother with all of this. Smaller and more frequent releases mean less goes wrong at once, and whatever does go wrong is easier to undo, which beats holding a giant release together with hope.

6:25 Fowler describes one retailer that rolled out a new online system in careful steps. It went first to the company's own employees, then to a group of invited customers, and only after that, to everyone. Notice what delivery doesn't demand either. It doesn't force you to deploy constantly, and plenty of teams stay excellent at delivery while releasing on a schedule. The business picked. With those two words sorted out, the pipeline itself gets much easier to walk through as walking through the stages. Now we get to the machinery in the order a change actually travels. A pipeline is really just a sequence, and each stage has one job, which is why a beginner can follow it without knowing the tools. Everything starts with a trigger. Something sets the run going, and most of the time that something is a saved change. Though it can also be a schedule or a person pressing a button.

7:07 Next comes the build. The machine takes the code and turns it into something runnable. It does the compiling and packaging that a human used to do by hand, and it never varies. Then the tests run. These range from tiny unit tests that check a single function to security scans that look for known problems in the libraries you pulled in. The goal isn't perfection, it's catching the cheap mistakes before a customer finds them. The run then produces an artifact, which is the finished versioned package that everything downstream will use. This is where the most important rule in the whole pipeline lives, which is that you build the package once and then move that same package forward. Rebuilding for each environment is a quiet disaster because you end up testing one thing and shipping a slightly different thing. The version that passed in the test environment has to be the exact version that reaches production, or the test proved nothing.

7:50 The order is fixed on purpose. You can't test a package you haven't built, and you can't deploy a package that failed its tests. So each stage exists partly to protect the next one. Finally, the package gets deployed first into a test environment and then into production with the pipeline repeating the same steps and reporting the same results each time. If you have ever clicked through a manual release checklist, you already understand the value here. The machine doesn't get tired after a long day, and it never skips the boring line. The names change from tool to tool, but the shape doesn't. As your pipelines organizes all of this into stages, jobs and steps and GitHub actions keeps the same idea in workflow files. Power platform has its own pipelines feature too, and it lets a maker deploy a solution with a few clicks.

8:31 Naming the stages is the easy part though. The interesting moment is the one where a pipeline stops on purpose and waits for a person, environments and the gate. Before production. A pipeline can build and test perfectly and still pause. And that pause is a design choice rather than a flaw. It happens at the environment boundary. So the environment idea is worth 30s. An environment is simply a copy of the world where your software runs and most teams keep a ladder of them. Development comes first, then a test environment that looks like production and then production itself. The latter exists for one reason. You want to meet the surprises somewhere that isn't the live one. A bug in a test environment costs a bug report, and a bug in production costs customers. Automation deliberately stops at one point. In tools like Azure Pipelines, you can attach a manual approval to a production stage, and the run simply waits until a person says yes.

9:17 That's the honest trade. The machine handles the repetitive work and the remembering, and the human keeps the decision about the last door. Microsoft's own documentation calls manual approval a common check for controlling deployments to production, which tells you that even the most automated shops expect a human at that step. The same pattern shows up in the power platform world. With a gentler interface. A maker deploys a solution from development into a test environment. The deployment gets checked against the target before it starts, and then somebody approves the move into production. That gate exists because things do go wrong eventually, even with every check in place, most teams only think hard about that part after their first bad release. When a deploy goes wrong, every gate in the world will eventually let something through. So the real question isn't whether a release will break something.

10:00 The real question is how fast the team can put the last good version back. Begin with the simplest move, which is rollback. When a change misbehaves, the safest response is usually to restore the previous version and let people breathe. That is why keeping the last good package around matters so much. Everything else in this section is an answer to one question, which is how quickly you can undo this if it goes wrong. The strategies differ mainly in how much safety you buy and how much complexity you pay for it. A basic deployment swaps everything at once. It's simple, cheap, and the riskiest of the lot because there's no safe half to stand on while you fix the problem. A rolling deployment swaps the machines in batches, so some of them keep serving the old version while the rest update. It's simple to undo and gentler on your users, though it finishes more slowly and needs the old and new versions to tolerate each other.

10:43 Blue green deployment keeps two identical environments and flips traffic from one to the other, which makes rollback almost instant because you simply flip it back. The catch is cost. Since you're paying for a second environment to sit there waiting. Canary deployment sends the change to a small slice of. Users first watches the numbers and widens only if the slice stays healthy. It's the safest of the group and cheaper than blue green. And it's also the hardest to build because you're watching real traffic instead of a test. Now we come back to the story from earlier because this is where it lands. Back in two thousand and nine, a company called Imvu was averaging about fifty deploys a day. Its release script pushed each new version to a small set of machines serving the first few customers. A minute later, it checked the health data and it rolled back on its own. If anything looked wrong, that's a canary deployment with an automatic undo, and it was running long before any vendor put it on a menu.

11:29 Azure pipelines now ships those same strategies out of the box under the names run once, Rolling and Canary. So the recovery playbook is real and it's old. The failures that still happen usually come down to a short list of habits, and that list is worth walking through. The mistakes that break pipelines. If recovery is the hero of this story, the villain is usually a habit rather than a tool. Most broken pipelines fail in a handful of predictable ways, and every one of them is avoidable. The first and biggest is the giant batch. Research from the Dora program has studied software delivery for over a decade, and it keeps landing on the same advice. Make each change as small as you can. Small changes are easier to reason about, faster to move, and easier to undo. Then there are flaky tests, the ones that fail randomly and pass when you run them again.

12:13 A test like that teaches the whole team to ignore red, and once people ignore red, the pipeline is decoration. Imvu set the bar almost absurdly high here. Their standard was that a test shouldn't fail. More often than once in a million runs. They treated intermittent failures as bugs to hunt down rather than reruns to click. Rebuilding instead of promoting is another quiet killer. If the package you tested isn't the package you shipped, you tested nothing. And this is why the artifact gets built once and carried forward. Secrets deserve a mention, too. Passwords and keys belong in a secure store, such as a variable group in Azure Pipelines. Typing them into a script leaves them where everyone on the team can read them. Then there's ownership. When the build goes red and nobody feels responsible for it, the habit collapses because continuous integration works as a team promise rather than a plugin you install.

12:56 The last trap worth naming is the measurement trap. Dora warns that turning a metric into a target mostly invites people to game the number. Demand a certain number of deploys per day and you'll get that number rather than better work. The newest wrinkle is AI, and the research is more interesting than the headlines. Dora found that a rise in AI adoption was associated with better individual work, including a three point four percent improvement in code quality. The same research tied it to a small drop in delivery throughput and a larger drop in delivery stability. The lesson is that faster writing doesn't fix a slow pipeline. Where this leaves you, the short version is worth keeping in your pocket. Integration is merging your work constantly while a machine checks the door, delivery is staying ready to release at any moment.

13:36 Deployment is letting the pipeline release for you and the stages are just that checklist running in order. The reason all of it exists is simpler than the acronym suggests. The teams that ship the most are the teams that can undo the fastest. So speed and safety turn out to be the same skill rather than opposing ones. One question is worth sitting with after this. What is the one manual step in your own work that you would happily hand to a machine, if it would run it the same way every single time?