[00:02] Give me 5 minutes and I'll show you how code gets from a laptop to production environment for millions of users. A developer writes some code on their laptop. A few hours later, that exact code is running for millions of people
[00:16] around the world. And imagine a human barely touched it along the way. Let me show you that journey because it is one show you that journey because it is one of the most satisfying things in all of
[00:29] engineering. Now, let's start with the old way so the modern one makes sense immediately. A developer finishes their code, copies the files onto the live code, copies the files onto the live server by hand, restarts it, and hopes
[00:42] nothing breaks. If something is wrong, the website goes down and everyone panics to fix it under pressure. It's slow, it's stressful, risky, and it's easy to make mistakes that takes the whole site offline. The modern way,
[00:58] the exact opposite of this, uses a pipeline to replace the old do it manually and hope for the best way. So, think of a pipeline like an assembly
[01:10] line for code, and let's walk through the stations of that assembly line one by one. Step one, developer pushes their code to a shared place like GitHub, and pushing that code is the only manual step. Everything after this is
[01:25] automatic. Step two, that push automatically triggers tests. So, the pipeline runs hundreds of checks. Does the new code work? Did it break something that used to work before? If any test fails, the code changes are
[01:41] If any test fails, the code changes are rejected right away before it ever gets near a real user. So, this is your safety net. Step three, if the tests pass, the code is packaged into a container
[01:54] image. That sealed box with the application and everything application needs packaged inside of it. So, it runs the same way no matter where it lands. Step four. The package is sent first to a staging
[02:11] environment. So, staging is a copy of the real environment. Like a simulation, basically. Where the team can see basically. Where the team can see exactly how the application changes will
[02:23] behave on real environment. Your actual users on real environment. Your actual users never see staging. This is for testing or preparing for the actual environment. Step five. If tests on staging
[02:37] environments look good, the package then goes to production. Which is the real environment your users actually see. Now, obviously, there's already a previous version of the application
[02:50] running on production. So, the old version needs to be stopped and the new version deployed. But, here's an interesting point. Smart teams do not just flip to the new version for everyone at once. They release it to 10%
[03:07] everyone at once. They release it to 10% of users first. So, 90% of users still get the old version. Only 10% see the new one. Why? Because you can't possibly test everything before. No matter how careful you are
[03:20] and how many stages you have before. So, if something still slipped through the if something still slipped through the tests, and if anything breaks, only 10% them. And you can roll it back immediately
[03:35] to the previous version. So, this allows teams to observe the new version carefully, maybe for a few hours. If everything looks fine, then roll it out everything looks fine, then roll it out to everyone else. Now, the names. This
[03:48] to everyone else. Now, the names. This whole assembly line is called CI/CD. CI is the automatic testing every time the code changes. CD is the automatic delivery of those code changes to the users. And together, they turn a scary
[04:04] manual all-hands event into this repeatable boring process. And boring is exactly what you want when millions of people use your app actively. You want
[04:16] predictable outcomes without any surprises. So, the journey is push, surprises. So, the journey is push, test, package, staging, production. Happening automatically many times a day with a safety net at every step with
[04:33] automated tests and an undo button at the end. Building that pipeline is actually a huge part of what DevOps engineers do. And it is the reason companies can ship updates constantly without causing a mess for
[04:49] constantly without causing a mess for their entire set of users.