The Assembly Line

Narrated

It’s Sunday night. You just finished a new feature. You’re excited. You want it live. So you start the deployment ritual.

First, run the tests. Okay, they pass. Good. Now build the Docker container. Wait for that. Tag it with a version number. Push it to the container registry. Wait for that. SSH into the server. Pull the new container. Stop the old one. Start the new one. Check if it’s running. Test it manually one more time in production. Done.

That’s ten steps. On a good day, it takes twenty minutes. On a bad day, you forget one step. Maybe you forgot to run the tests. Maybe you pushed the wrong version tag. Maybe you stopped the old container before the new one was ready, and your app was down for two minutes while you scrambled. Maybe you did everything right, but you were tired and deployed to the wrong server.

This ritual is where most production incidents come from. Not from bad code. From bad process. Humans are terrible at doing the same ten steps perfectly every single time. We get tired. We get distracted. We skip things. We make typos.

You know what’s great at doing the same ten steps perfectly every single time? A robot.

CI/CD is the practice of automating everything between “I pushed my code” and “it’s live for users.” CI stands for continuous integration, which means every push automatically gets tested and built. CD stands for continuous delivery, which means every successful build automatically gets deployed. Together, they’re an assembly line for your software.

You’ve already started building this assembly line. In Lesson 24, you set up tests that run on every push. That’s the first station. Now we’re going to build the rest of the line: build, package, store, and deploy. Push your code, walk away, and it goes live on its own, but only if everything checks out.