DevOps & Deployment

A way of releasing a new version of an app with no downtime. You set up the new version on a second, identical environment running quietly alongside the live one. Once it's tested and looks good, you flip all visitors over to the new environment in an instant. And if something goes wrong, you flip back just as fast.

A careful way to launch a new version: instead of giving it to everyone at once, you send it to a small group first and watch how it performs. If everything looks healthy, you let in more people. If problems show up, you stop the rollout before most users ever notice.

An automatic assembly line for software. Every time someone saves a change, the system runs the tests, packages the new version, and (if everything looks good) puts it in front of users: all without anyone clicking a deploy button. It catches mistakes early and lets teams ship updates many times a day instead of once a month.

A neat little package that bundles an app together with everything it needs to run: the right tools, the right settings, the right helper files. Once it's packaged, the container will run the same way on any computer, which solves the classic 'but it worked on my laptop!' problem.

The act of putting a new version of an app or website live so real people can use it. In modern teams, deployments happen smoothly and often, sometimes many times a day, instead of being big, risky events that take all weekend.

The most popular tool for building and running containers. Those neat self-contained packages that hold an app plus everything it needs. Docker is what made containers easy enough for everyday use; saying 'I containerized it' usually means 'I used Docker.'

A setting handed to a program from the outside, instead of being baked into the code. It lets the same program behave differently depending on where it's running: for example, talking to a test database while you're developing and the real one in production.

A rule that says 'never edit a running server.' If you need a change, you build a fresh server with the new setup and throw the old one away. This avoids the messy situation where servers slowly drift apart over time as people make small tweaks nobody remembers.

Writing down what your servers, databases, and networks should look like in plain text files, instead of clicking around in a cloud dashboard to set them up by hand. Those files become the recipe: anyone can review them, save them, or use them to recreate the whole setup from scratch.

A traffic controller for containers. You tell it 'I want five copies of this app running at all times,' and it figures out which computers to run them on, restarts any that crash, and adds more when traffic spikes: all without anyone watching over it.

The ability to look at a running app from the outside and understand what's happening inside it. You can't open up the live system to peek around, so the app leaves a trail of clues, logs, numbers, timing data, that engineers can read when something goes wrong.

Going back to the previous, working version of an app after a new release turns out to be broken. Being able to roll back quickly is what lets teams take chances on releases. They know any mistake can be undone within minutes.

The careful way teams handle the sensitive things their apps need: passwords, API keys, signing tokens. The rules: never paste them into the code, never email them around, store them in a locked-down vault, and only hand them to the app at the moment it actually runs.

Production is the real, live version of the app that actual customers use. Staging is a private practice copy that looks and works just like production, where the team can test new changes safely. The whole point of staging is to catch problems before real users ever see them.