DevOps is the way a software team moves a change from an idea to the live system that customers use, with most of the steps done by software rather than by hand. The name joins two jobs that were once done by separate teams: development, which writes the code, and operations, which runs the servers. A server is a computer in a data centre that runs software for many users at once.
Take one small bug. At a payments start-up in Bengaluru, the app shows the old balance for a few seconds after a payment. Customers write in, worried that their money has gone missing. The app asks the start-up's server for the balance through an API, a fixed set of requests that one program can send to another. The server was answering before the payment had been recorded. A developer is asked to fix it.
First, the work is written down. A product manager opens a ticket in the issue tracker: "Balance not updated after payment", with the developer's name on it and the status "To do".
Second, the code. The developer changes about 30 lines and sends them to the code repository, where the team's code is kept with its full history. The change arrives as a pull request, a proposed change that a colleague reviews before it joins the main code. Because the balance code is old, the reviewer first checks an application dependency map, which shows every other part of the app that reads the balance.
Third, the checks. A CI/CD pipeline starts by itself. It builds the change, which means it turns the code into a program that can run. It runs the team's automated tests, small programs that use the app and check the result. Security scanners read the new code, and check every open-source library it uses against public lists of known flaws. Running these checks early, before release, is called shifting left.
Fourth, the package. The built version is stored in an artifact registry, with a version number such as 4.12.1. It is usually packed as a container: the program plus everything it needs to run, in one file that runs the same way on any server.
Fifth, the release. The pipeline deploys the new version, which means it installs it on the servers and starts it. The servers were set up by configuration management, so every server is identical. The fix is now in production. Every system on the way writes a log, a line of text for each event, so anyone can later see who changed what, and when. The whole path, from ticket to production, can take less than a day. Later, the company's leaders may read developer productivity metrics, which estimate the work inside each change.
Some companies buy all these systems from one vendor; others combine tools from several. One vendor is simpler to run, but it makes switching harder later. This is called vendor lock-in.