What Is DevOps? A Beginner Guide
Read this guide in: English · मराठी · हिंदी
Why do we need DevOps? Because there is a real problem between developers and operations. Developers write the application. Operations means the employee who works on the server side — they put the app on the server, keep it running, check logs, and get the call when the site is down. When these two sides throw work over a wall, shipping becomes slow and scary. DevOps is the habit that joins them into one fast loop: plan, code, build, test, release, deploy, operate, feedback — with shared tools like Git, Docker and CI/CD.
Friends, do not start with tool logos. First understand the fight between developer and server-side person. Then the loop will feel simple.
Quick answer
Hold this vertical picture:
- Developer — writes and changes the code.
- Operations — server-side employee who deploys, restarts, watches health.
- The problem — “works on my laptop” vs “broke on the server”; blame; mystery zip / wrong build.
- DevOps — both sides share one loop and the same automated path.
- Pocket line: DevOps = developers + operations working as one team with one process.
Language: English · मराठी · हिंदी
Why do we need DevOps?
There is a problem between two kinds of people who both care about the product:
- Developers — build features, fix bugs, write code.
- Operations — the people on the server side. They install packages, copy builds, open ports carefully, restart services, read logs, and keep production alive.
If developers only “finish code” and operations only “put something on the server” with no shared system, every release becomes an argument. That is why we need DevOps.
What does “operations” mean? (say it simply)
In class language:
- Operations is not only a buzzword on LinkedIn.
- Operations means the employee (or team) who works on the server side.
- Their day looks like: SSH to the server, check disk, restart a service, read error logs, take a backup, roll back a bad deploy.
Developers live in the code. Operations lives with the running server. DevOps asks both to own the journey from change → live users.
What is the problem? Suppose we are…
Suppose we are building Instagram (like updates)
Suppose you are on a team that ships Instagram-style features — feed, stories, likes.
- Monday — a developer finishes “show a new badge on the profile.” It works on their laptop.
- They say “done” in chat and hand a zip / build folder to someone else.
- Wednesday — the operations person (server-side) is busy with another outage. They copy the files to the production server when they get time.
- Laptop had one library version; the server has another. Real users see a broken profile page.
- Friday night — support floods in. Developer: “It worked on my machine.” Operations: “I only put what you sent.” Nobody is sure which build is live. Blame starts.
That fight — app developer vs server-side operations — is why companies invent DevOps habits.
Suppose we are working at Netflix and we are giving updates
Suppose you work at Netflix and your team must push updates often — new rows on the home screen, bug fixes, small UI changes.
- If every update needs a manual copy to servers by one operations person, Netflix cannot ship safely many times a week.
- One bad manual step and millions of viewers feel the break.
- So they need: shared Git history, automatic tests on every change, the same package on every server, and a repeatable deploy path — not “ask that one person to copy files tonight.”
Big streaming apps survive on small, frequent, automated updates — that is DevOps thinking at scale.
Suppose you are working in Infosys (or a similar company) on a client project
Suppose you are working in Infosys (or any big services company) on a client banking / retail app.
- Your developer team is in one city; the client’s operations / infra team owns the servers.
- You email a build. They deploy on their calendar. Environments differ (dev laptop ≠ client UAT ≠ production).
- Release day becomes a war room: wrong config, missing file, “who approved this?”
- The client does not care about your laptop demo — they care that production works.
DevOps skills matter in jobs like this because you must speak both languages: code change and how it lands on the server safely.
Developers write code; operations (server-side) runs servers. DevOps joins them in one loop: plan → code → build → deploy → operate, then feedback.
Before: developer and operations throw work over a wall. After DevOps: one shared path with Git, CI, Docker and a known deploy.
How DevOps answers that same fight
Same Instagram-style badge feature, new habit:
- Plan — one small goal this week (badge), not a giant rewrite of the whole app.
- Code — change lives in Git from the first line (author, message, history — no mystery zip).
- Build and test (CI) — every push, a computer runs the same checks (GitHub Actions or Jenkins). Failures show up before Friday night.
- Package — Docker (or one clear build) so laptop and server run the same bits.
- Deploy — developers and operations use the same script or pipeline — not a one-off copy-paste.
- Operate + feedback — logs and health watched together; an incident becomes the next plan, not only a blame call.
Now the developer and the server-side operations person are not two enemy teams. They share one loop.
The DevOps loop (still with real-world “suppose”)
Plan
Suppose we are Netflix: this sprint’s plan is one home-row fix — not “rebuild the whole app.”
Code with Git
Suppose two Infosys developers edit the same file. Without Git, email attachments overwrite each other. With Git, every save is a commit; work stays on a branch; main stays releasable.
Build and test (CI)
Suppose nobody remembered to run tests before the Instagram-style push. CI remembers for you on every push — same command, same result.
Package
Suppose your laptop has Python/Node version A and the client server has version B. Same code, different result. Docker is the “same runtime everywhere” answer.
Deploy and operate
Suppose Friday deploy used to be hand copy by operations alone. Now the same deploy path runs Tuesday or Friday. Operations still watches the server — but with a known version and a rollback story.
Tools beginners learn first — each one maps to the real problem
| Pain from the stories above | Starter tool | Role |
|---|---|---|
| Which build is live? | Git + GitHub | History and review |
| Works on laptop only | Docker | Same app on server |
| App + database together | Docker Compose | Multi-service stack |
| Nobody ran checks | GitHub Actions or Jenkins | Automated build/test/deploy |
| Server config drifts | Ansible | Desired state on servers |
| Who clicked what in the cloud console? | Terraform | Infrastructure as code |
You do not need Kubernetes on day one. First fix the developer vs operations wall with Git and Docker.
Ravindra Bagale's Tip
Khup students jump to tool names — Docker, Jenkins, Kubernetes — and still cannot answer: “What is operations?” and “What was the problem between developer and server-side person?” Interview madhe pahile real example sanga: Instagram-style update, Netflix frequent release, Infosys client server. Mag DevOps loop. Mag ek tool tumhi practice kele. Lakshat theva.
Common beginner mistakes
| Mistake | Better habit |
|---|---|
| Thinking DevOps = only Jenkins | First tell developer vs operations problem |
| Ignoring what “operations” means | Say it: server-side employee / team |
| Manual copy-paste deploys | Same path every time (script/pipeline) |
| Huge rare releases | Small frequent updates (Netflix-style thinking) |
| Skipping Git | The “which build?” problem returns |
What should I learn next?
- Git basics for DevOps beginners — stop the mystery zip / build
- Git branching and pull requests — review before the server sees it
- Install Docker on EC2 — same app on a real server
Learn it properly
Related AWS ops skills beside this story:
Samajla ka? Why DevOps = developer vs operations problem; operations = server-side person; “suppose we are building Instagram / working at Netflix / working at Infosys” shows the fight; the loop is how both sides work as one. Next guide tonight.
Frequently asked questions
What does DevOps mean?
DevOps joins developers and operations (the server-side employee/team) so shipping uses one loop: plan, code, build, test, deploy and feedback — like Instagram-style updates, Netflix frequent releases, or an Infosys client project.
Is DevOps only tools?
No. Tools help, but culture and process matter: small changes, automation, and shared ownership of failures.
Do I need Kubernetes on day one?
No. Beginners start with Git, Linux basics, Docker and one CI tool. Kubernetes comes later.
How is DevOps different from Agile?
Agile improves how you plan and deliver work in iterations. DevOps extends that into build, release and operations with automation.
What should I learn first?
Git and the terminal, then Docker, then a simple GitHub Actions or Jenkins pipeline.
Where does AWS fit?
AWS (or any cloud) is where many apps run. DevOps skills deploy and operate those apps reliably.
Practice Tasks
Suppose we are on the DevOps team at Atlassian, the developer software company, working from Sydney. Liam O'Connor leads the team, and we look after the issue tracker webhook service. Costs are counted in AUD. In the tasks below we do real DevOps jobs on this project using what this lesson teaches. Atlassian is a real company, but this project, the people, servers, IP addresses and numbers are made up for practice.
0 / 12
Easy Name the practice
Why: Knowing the names helps you in interviews and design talks.
What to do: At Atlassian every developer merges small changes into main several times a day, and each merge is built and tested automatically. What is this practice called (two-letter short form)?
- Write down the facts or numbers the task gives you.
- Work it out step by step.
- Type only the final answer (one word or number) in the box.
- Click Check answer.
Easy List all files with details
Why: Hidden files (like .env) and file sizes or owners only show with the right options.
What to do: Show a long listing of every file, including hidden ones, in /var/www/atlassian.
- Find the Linux command that does this job.
- Add the options (like -r or -h) the task needs.
- Add the file names, folders or users in the right order.
- Click Check answer.
Easy Which port does the user hit?
Why: Mixing host and container ports is the most common docker mistake.
What to do: A container was started with -p 8443:3000. Which port do you open in the browser on the host?
- Write down the facts or numbers the task gives you.
- Work it out step by step.
- Type only the final answer (one word or number) in the box.
- Click Check answer.
Easy Stage every change
Why: Before the first commit you usually want every new file included.
What to do: Stage every new and changed file in the current folder and below.
- Read the task and pick the tool it needs (git, docker, kubectl, terraform, ansible...).
- Write the tool name, then the sub-command (the action word).
- Add the flags the task needs, each followed by its value.
- Add names, files or paths at the end, then click Check answer.
Easy Stage one file
Why: Only staged changes go into the next commit.
What to do: Stage only the file Dockerfile for the next commit.
- Read the task and pick the tool it needs (git, docker, kubectl, terraform, ansible...).
- Write the tool name, then the sub-command (the action word).
- Add the flags the task needs, each followed by its value.
- Add names, files or paths at the end, then click Check answer.
Easy Clone a repository
Why: Cloning gives you the full project and its history on your machine.
What to do: Download the repository https://github.com/atlassian/atlassian-issue-tracker-webhook.git to this machine.
- Read the task and pick the tool it needs (git, docker, kubectl, terraform, ansible...).
- Write the tool name, then the sub-command (the action word).
- Add the flags the task needs, each followed by its value.
- Add names, files or paths at the end, then click Check answer.
Easy Commit with a message
Why: A clear message tells the team why the change was made.
What to do: Commit the staged changes with the message "Add health check to issue-tracker-webhook".
- Read the task and pick the tool it needs (git, docker, kubectl, terraform, ansible...).
- Write the tool name, then the sub-command (the action word).
- Add the flags the task needs, each followed by its value.
- Add names, files or paths at the end, then click Check answer.
Medium Delivery or deployment?
Why: The two words mean different levels of automation.
What to do: At Atlassian every change that passes tests goes to production automatically, with no human approval. Is this continuous delivery or continuous deployment? Type one word.
- Write down the facts or numbers the task gives you.
- Work it out step by step.
- Type only the final answer (one word or number) in the box.
- Click Check answer.
Medium Run the build inside a Docker agent
Why: A Docker agent gives a clean, versioned toolchain for every build.
What to do: Declarative pipeline with agent docker { image 'maven:3.9-eclipse-temurin-21' } and stage Build running sh 'mvn -B verify'.
- Start with pipeline { and close it with } at the end.
- Add agent, then stages { } with one stage('Name') { steps { } } per step.
- Put the commands inside steps using sh '...'.
- Count your { and } so every block is closed, then click Check answer.
Hard Name the approach
Why: GitOps tools like Argo CD are now common in K8s teams.
What to do: At Atlassian a tool inside the cluster keeps pulling manifests from a Git repo and makes the cluster match it. What is this approach called (one word)?
- Write down the facts or numbers the task gives you.
- Work it out step by step.
- Type only the final answer (one word or number) in the box.
- Click Check answer.
Hard Build and push an image from CI
Why: Every merge to main gives a fresh image in the registry.
What to do: Workflow on push to main. Job image on ubuntu-latest. Steps: actions/checkout@v4; docker/login-action@v3 with registry ghcr.io, username ${{ github.actor }}, password ${{ secrets.GITHUB_TOKEN }}; docker/build-push-action@v6 with push true and tags ghcr.io/atlassian-issue-tracker-webhook:${{ github.sha }}.
- Start from the top-level keys the task names.
- Indent child keys with 2 spaces (no tabs).
- Use "- " for list items and fill each value from the task.
- Check the colons and spacing, then click Check answer.
Hard Use Jenkins credentials safely
Why: withCredentials masks the password and removes it after the block.
What to do: Inside stage Push steps, use withCredentials with usernamePassword(credentialsId: 'reg-cred', usernameVariable: 'U', passwordVariable: 'P') and run sh 'echo $P | docker login -u $U --password-stdin registry.atlassian.example.com'. Wrap it in a full declarative pipeline with agent any.
- Start with pipeline { and close it with } at the end.
- Add agent, then stages { } with one stage('Name') { steps { } } per step.
- Put the commands inside steps using sh '...'.
- Count your { and } so every block is closed, then click Check answer.