DevOps

Traditionally, two separate groups work on larger pieces of software. One writes the program code and builds new features. The other ensures that the program runs on the servers, stays reachable, and doesn’t crash. Servers are simply powerful computers that sit in a data center and answer requests from the internet. Conflict easily arises between the two groups: one wants to ship as many new features as possible, the other wants calm, because every change can break something. DevOps is the attempt to dissolve this separation and bundle both tasks into a single, shared team.

Why companies want to change their software daily

In the past, a new program version was a major event. A company would collect changes for months and ship them in a single package. If something went wrong, troubleshooting was tedious because hundreds of changes were new at the same time. Such releases therefore often took place at night or on weekends.

Today, large internet companies publish new versions multiple times a day. Amazon and Google report shipping thousands of changes per day. Each individual one is tiny, so the risk is small and a bug is found quickly. Anyone with an idea in the morning can test it on real users by evening.

For companies, this is an economic advantage, not just a technical one. Whoever reacts faster finds out sooner what customers really want. It also eliminates a lot of waiting time during which finished work sits around unused. That’s why DevOps appears so often in business reports and job postings.

The chain from code to server

The heart of DevOps is an automated chain called a pipeline. A developer saves their change in a shared code repository. A process then starts automatically: the code is built, checked, and tested. Only once all tests have passed does the new version go onto the servers.

The developers write these tests themselves. A test might check, for example, whether the login function still works after the change. If a test fails, the chain stops and no one has to intervene by hand. This constant checking and delivering is called Continuous Integration and Continuous Delivery, or CI/CD for short.

The servers themselves are also no longer set up by hand. Their configuration exists as a text file in the same repository as the program code. A tool reads this file and generates the appropriate environment from it. The advantage: you can rebuild an identical copy at any time, instead of laboriously reconstructing what someone configured two years ago.

DevOps in everyday life and in AI projects

You mostly notice good DevOps work by the fact that you don’t notice it. Apps on smartphones update quietly in the background. Online shops and streaming services change their interface without ever going offline for maintenance. When a service is down for hours, on the other hand, that’s often a failed release.

In job postings, the term appears as a job title, such as DevOps engineer. Commonly mentioned tools include Docker, Kubernetes, Jenkins, and GitHub Actions. A common misconception is that DevOps is simply the new name for system administration. What is actually meant, though, is primarily a way of working in which a team remains responsible for its product from code all the way to running operations.

In the AI field, there is a specific variant called MLOps. It applies the same ideas to machine learning models, i.e., to programs that learn from data instead of being explicitly programmed. Additional questions come into play there: what data was used for training, and does the model get worse over time? But the underlying attitude remains the same: automate, measure, deliver in small steps.