Guides

DevOps क्या है? शुरुआती guide

By Ravindra Bagale, DevOps trainer · LinkedIn · Published: 30 September 2026 · Last updated: 30 September 2026

Read this guide in: English · मराठी · हिंदी

Why DevOps चाहिए? क्योंकि developers और operations के बीच असली problem है। Developers application लिखते हैं। Operations मतलब server side पर काम करने वाला employee — वह app को server पर रखता है, चलाता रहता है, logs जाँचता है, और site गिरे तो phone उठाता है। जब ये दोनों पक्ष दीवार के ऊपर से काम फेंकते हैं, shipping धीमी और डरावनी हो जाती है। DevOps वह आदत है जो उन्हें एक तेज़ loop में जोड़ती है: plan, code, build, test, release, deploy, operate, feedback — Git, Docker और CI/CD जैसी shared tools के साथ।

दोस्तों, tool logos से शुरू मत करो। पहले developer और server-side person की लड़ाई समझो। फिर loop आसान लगेगा।

Language: English · मराठी · हिंदी

DevOps क्यों चाहिए?

Product की चिंता करने वाले दो तरह के लोगों में problem है:

1. Developers — features बनाते हैं, bugs सुधारते हैं, code लिखते हैं।
2. Operations — server side वाले लोग। वे packages install करते हैं, builds copy करते हैं, ports सावधानी से खोलते हैं, services restart करते हैं, logs पढ़ते हैं, और production ज़िंदा रखते हैं।

Developers सिर्फ़ “code खत्म” और operations सिर्फ़ “server पर कुछ रख दिया” — shared system न हो तो हर release बहस बन जाती है। इसलिए DevOps चाहिए।

“Operations” का मतलब क्या? (सीधी भाषा)

Class भाषा:

1. Operations सिर्फ़ LinkedIn का buzzword नहीं है।
2. Operations मतलब server side पर काम करने वाला employee (या team)।
3. उनका दिन: server पर SSH, disk जाँचना, service restart, error logs पढ़ना, backup, खराब deploy rollback।

Developers code में रहते हैं। Operations चलते server के साथ रहता है। DevOps दोनों से change → live users की यात्रा own करने को कहता है।

Problem क्या है? Suppose we are…

Suppose we are building Instagram (like updates)

Suppose आप Instagram-style features — feed, stories, likes — ship करने वाली team पर हैं।

1. Monday — developer “profile पर नया badge” खत्म करता है। Laptop पर चलता है।
2. Chat में “done” और किसी को zip / build folder देते हैं।
3. Wednesday — operations person (server-side) दूसरी outage में व्यस्त। समय मिलने पर files production server पर copy करता है।
4. Laptop पर एक library version; server पर दूसरी। असली users को टूटा profile page दिखता है।
5. Friday night — support आता है। Developer: “मेरी machine पर चला।” Operations: “मैंने सिर्फ़ जो दिया वही रखा।” कौन‑सा build live है पक्का नहीं। Blame शुरू।

वही लड़ाई — app developer vs server-side operations — इसलिए कंपनियाँ DevOps आदतें बनाती हैं।

Suppose we are working at Netflix and we are giving updates

Suppose आप Netflix पर काम करते हैं और team को बार‑बार updates देने हैं — home screen पर नई rows, bug fixes, छोटे UI बदलाव।

1. हर update के लिए एक operations person servers पर manual copy करे तो Netflix हफ़्ते में कई बार सुरक्षित ship नहीं कर सकता।
2. एक खराब manual step और लाखों viewers को break महसूस होता है।
3. इसलिए चाहिए: shared Git history, हर बदलाव पर automatic tests, हर server पर वही package, और repeatable deploy path — “उस एक व्यक्ति से रात को files copy करवाओ” नहीं।

बड़े streaming apps छोटे, बार‑बार, automated updates पर जीते हैं — यही DevOps thinking at scale।

Suppose you are working in Infosys (or a similar company) on a client project

Suppose आप Infosys (या किसी बड़ी services company) में client banking / retail app पर काम करते हैं।

1. Developer team एक शहर में; client का operations / infra team servers own करता है।
2. आप build email करते हैं। वे अपने calendar पर deploy करते हैं। Environments अलग (dev laptop ≠ client UAT ≠ production)।
3. Release day war room: गलत config, missing file, “किसने approve किया?”
4. Client को आपके laptop demo की परवाह नहीं — उन्हें production चलना चाहिए।

ऐसी jobs में DevOps skills ज़रूरी क्योंकि आपको दोनों भाषाएँ बोलनी हैं: code change और वह server पर सुरक्षित कैसे आता है।

DevOps उसी लड़ाई का जवाब कैसे देता है

वही Instagram-style badge feature, नई आदत:

1. Plan — इस हफ़्ते एक छोटा लक्ष्य (badge), पूरी app का rewrite नहीं।
2. Code — बदलाव पहली line से Git में (author, message, history — mystery zip नहीं)।
3. Build और test (CI) — हर push पर computer वही checks चलाता है (GitHub Actions या Jenkins)। Failures Friday night से पहले दिखते हैं।
4. Package — Docker (या एक साफ़ build) ताकि laptop और server वही bits चलाएँ।
5. Deploy — developers और operations वही script या pipeline इस्तेमाल करते हैं — one-off copy-paste नहीं।
6. Operate + feedback — logs और health साथ; incident अगला plan बनता है, सिर्फ़ blame call नहीं।

अब developer और server-side operations person दो दुश्मन teams नहीं। वे एक loop साझा करते हैं।

DevOps loop (अभी भी real-world “suppose” के साथ)

Plan

Suppose we are Netflix: इस sprint का plan एक home-row fix — “पूरी app rebuild” नहीं।

Code with Git

Suppose दो Infosys developers वही file edit करते हैं। Git न हो तो email attachments एक‑दूसरे पर लिखते हैं। Git हो तो हर save एक commit; काम branch पर; main releasable रहता है।

Build and test (CI)

Suppose Instagram-style push से पहले किसी ने tests याद नहीं रखे। CI हर push पर आपके लिए याद रखता है — वही command, वही result।

Package

Suppose laptop पर Python/Node version A और client server पर version B। वही code, अलग result। Docker मतलब “हर जगह वही runtime” जवाब।

Deploy and operate

Suppose Friday deploy सिर्फ़ operations के हाथ से copy होता था। अब वही deploy path Tuesday या Friday चलता है। Operations अभी भी server देखता है — पर known version और rollback कहानी के साथ।

शुरुआती पहले कौन‑से tools सीखें — हर tool असली problem से जुड़ता है

पहले दिन Kubernetes नहीं चाहिए। पहले Git और Docker से developer vs operations दीवार घटाओ।

आम beginner mistakes

आगे क्या सीखें?

1. Git basics for DevOps beginners — mystery zip / build रोकें
2. Git branching and pull requests — server देखने से पहले review
3. Install Docker on EC2 — असली server पर वही app

Samajla ka? Why DevOps = developer vs operations problem; operations = server-side person; “suppose we are building Instagram / working at Netflix / working at Infosys” लड़ाई दिखाता है; loop मतलब दोनों पक्ष एक साथ कैसे काम करते हैं। आज रात अगली guide।