Deployment

A program is first created on the developer’s machine. It works there, but no one outside can access it. Deployment is the step in which this program is copied to and started on the computers that real users will later access it through. Usually these are powerful machines in a data center that run around the clock. After that, anyone with a browser or an app can use the software. In German this is also called “ausrollen” (rolling out) or “in Betrieb nehmen” (putting into operation).

The moment code meets real users

There is a wide gap between “it works on my machine” and “it works for everyone.” On the developer’s machine, exactly one person works with the program. After deployment, there might be a hundred thousand people at once. Bugs that never surfaced before suddenly appear: memory runs out, the database gets overloaded, a setting is missing. That’s why deployment is considered the riskiest moment in the life of a piece of software.

At the same time, it’s the only step that truly counts. Code that is never deployed is of no use to anyone. Companies therefore often measure their development teams by how often they deploy. Large internet services roll out several changes into production per day, some even several per hour. Small, frequent deployments are safer than rare, large ones, because if a problem occurs, it’s immediately clear which change is to blame.

With AI, there’s an added cost factor. Deploying a trained model means running expensive graphics cards continuously. Training is a one-time expense, whereas operation after deployment continues every day and generates ongoing costs.

From test system to rolling back

Nowadays a deployment almost always happens automatically. Developers upload their change to a shared code repository. An automation service detects this, builds a runnable package from it, and starts automated tests. Only if all tests pass does the package move on to the production systems, i.e., the machines with the real users. This process is called a pipeline.

Beforehand there are usually intermediate stages. On a test system, developers try out the change; on a so-called staging system, as exact a copy as possible of the real environment runs. Only after that comes the final step. So that no one notices anything in the process, two versions often run in parallel: the new one initially receives only one percent of users. If it runs stably, the share is increased. This cautious approach is called canary deployment, named after the canary birds used in old mines.

In case something does go wrong, the old version is kept ready. You then simply switch back, which is called a rollback. A good deployment system can do this within a few minutes. Incidentally, a common mistake is equating deployment with release. Deployment means: the software is on the server. Release means: users are actually allowed to see the feature. The two can be deliberately separated by shipping new features initially switched off.

Where you’ll run into the term in everyday life

If an app suddenly looks different overnight, a deployment has taken place. If an online shop is unreachable for ten minutes on a Tuesday evening “due to maintenance work,” that’s also a deployment. And if a service goes down for hours, a faulty deployment that first has to be rolled back is very often behind it.

In business news, the term usually comes up in the context of AI. When a company reports that a model has been “deployed,” this means: it is no longer just a research result but usable within a product. The term also matters to EU regulation. The AI Act distinguishes between providers, who develop an AI system, and operators, called “deployers” in the English text, who put it into use. Both have different obligations.

As a job title, you’ll encounter this topic under the abbreviation DevOps or, for AI models, MLOps. These people rarely write the actual application. Their job is to make sure the path from code to a running system works reliably and repeatably.