Deployment

Software is first created on the computers of the developers. There it runs only for them and is not reachable by anyone else. For it to become usable for everyone, it must be brought to the computers that offer the service publicly. This exact step is called deployment, in German often “ausrollen” (rolling out). When an app suddenly has a new button overnight, a new version has been deployed. The process itself often takes only minutes today, even though the work beforehand may have taken weeks.

Why the move to the server is the most delicate moment

Up until deployment, a bug is harmless. At most it bothers the person who is currently programming. Afterward, the same bug hits all users at once. A broken deployment can bring down a banking app, an online shop, or a chatbot for hours. That is why companies treat this step with far more caution than the programming itself.

How often a company rolls out says a lot about it. Large internet companies deploy multiple times a day, some even hundreds of times. Classic corporations with old technology sometimes only manage it every few months. Frequent, small deployments are considered safer, because each change stays manageable. If something goes wrong, you immediately know which of the few changes is to blame.

In the business press, the term therefore appears as a metric. “Deployment frequency” measures how quickly a company brings new ideas to its customers. Whoever rolls out faster can react faster to competition and customer wishes. This speed has by now become a tangible competitive advantage.

From line of code to running service

Before rolling out, the code usually runs through an automated chain of checks. A program builds a runnable package from the written code. Then tests run, meaning small check programs that play through typical cases. Only once all tests have passed does the package move on. This chain is called a pipeline, because the change flows through it like through a pipe.

Most companies operate several separate environments. In the test environment, the team tries out the new version with sample data. In the production environment lies the real data of real customers. The jump from one to the other is the actual deployment. This is comparable to a dress rehearsal in an empty hall before the audience arrives.

To reduce risk, everything is rarely switched over at once. In a staged rollout, one percent of users first get the new version. If everything looks good, ten percent follow, then a hundred. If bugs turn up, the team switches back to the old version. This switching back is called a rollback and, in well-built systems, is a matter of seconds.

Deployments in news, apps, and AI services

You often encounter the word without noticing it. A mobile game that reports an update in the morning has a deployment behind it. The outage notice “We are working on a solution” also often follows a faulty rollout. Well-known outages at banks, airlines, or social networks can often be traced back to a single failed rollout.

In artificial intelligence, the term carries an additional meaning. A trained model is at first just a huge file of learned numerical values. Only deployment makes it available on powerful computers and retrievable through an interface. Before that, no one can chat with the model. That is why weeks sometimes pass between the announcement of a new model and its availability.

A common misconception is that deployment is the same as release. A deployment brings the code onto the server. A release makes a feature visible to users. The two can be separated: code can already have been deployed long ago, while a switch in the background still keeps the feature hidden. Companies use this to unlock new features exactly at the planned time.