डेवलपमेंट में रोलबैक: यह क्या है, तरीके और यह कैसे काम करता है

डेवलपमेंट में रोलबैक क्या है

रोलबैक — सिस्टम को पिछली स्थिर स्थिति में लौटाने की प्रक्रिया। डेवलपमेंट के संदर्भ में, इसका अर्थ Git में कमिट को पूर्ववत करना, डेटाबेस में लेन-देन को रोलबैक करना या सर्वर पर एप्लिकेशन के पिछले संस्करण पर लौटना हो सकता है। यह शब्द अंग्रेजी के “rollback” से आया है और सभी प्लेटफॉर्म के डेवलपर्स की शब्दावली में मजबूती से स्थापित है।

रोलबैक की आवश्यकता तब उत्पन्न होती है जब कोई नया बदलाव कार्यक्षमता को तोड़ता है, त्रुटियाँ पैदा करता है या गुणवत्ता जांच में विफल रहता है। एक सुव्यवस्थित डेवलपमेंट प्रक्रिया में, रोलबैक विफलता का संकेत नहीं है, बल्कि कार्यप्रवाह में निर्मित एक मानक प्रक्रिया है। टीम जितनी तेज़ी से समस्याग्रस्त बदलाव को रोलबैक कर सकती है, उपयोगकर्ताओं पर बग का प्रभाव उतना ही कम होता है।

विभिन्न उपकरण अलग-अलग रोलबैक तंत्र प्रदान करते हैं: Git सुरक्षित revert और विनाशकारी reset के बीच विकल्प देता है, डेटाबेस लेन-देन संबंधी rollback का समर्थन करते हैं, और CI/CD सिस्टम संस्करणों के बीच ट्रैफ़िक स्विच कर सकते हैं। दृष्टिकोण का चुनाव संदर्भ और परिवर्तन इतिहास को संरक्षित करने की आवश्यकताओं पर निर्भर करता है।

Git revert vs git reset: क्या अंतर है

Git revert — रोलबैक का एक सुरक्षित तरीका जो पिछले बदलावों को पूर्ववत करने वाला नया कमिट बनाता है। इतिहास रैखिक रहता है और सभी पुराने कमिट संरक्षित रहते हैं। यह साझा ब्रांच पर रिवर्ट करने का एकमात्र सही विकल्प है जिस पर कई डेवलपर काम करते हैं। Git revert इतिहास को नहीं हटाता — यह रोलबैक के तथ्य को एक नए बदलाव के रूप में जोड़ता है।

Git reset वर्तमान ब्रांच पॉइंटर को निर्दिष्ट कमिट पर ले जाता है, बाद के सभी बदलावों को त्याग देता है। फ़्लैग — soft, mixed या hard — के आधार पर, reset वर्किंग डायरेक्टरी और इंडेक्स को अलग-अलग तरीके से संभालता है। hard मोड इतिहास से बदलावों को पूरी तरह हटा देता है, जो इसे साझा ब्रांचों के लिए खतरनाक और केवल स्थानीय कार्य के लिए उपयुक्त बनाता है।

revert का उपयोग कब करें

Revert का उपयोग साझा ब्रांचों में किया जाता है: main, develop, release। यह इतिहास को संरक्षित करता है और अन्य डेवलपर्स को समझने देता है कि बदलाव को पूर्ववत किया गया था। revert के बाद, आप सुरक्षित रूप से git pull कर सकते हैं — सिस्टम पुनर्लिखित इतिहास से संबंधित विरोध उत्पन्न नहीं करेगा। टीम वर्क में, revert डिफ़ॉल्ट मानक है।

# अंतिम कमिट को नया कमिट बनाकर पूर्ववत करें
git revert HEAD

# हैश द्वारा विशिष्ट कमिट को पूर्ववत करें
git revert a1b2c3d

reset का उपयोग कब करें

Reset स्थानीय ब्रांच में उपयुक्त है जहाँ आपने अभी तक बदलाव प्रकाशित नहीं किए हैं। यदि आप प्रयोग कर रहे थे और इतिहास को पूरी तरह साफ करना चाहते हैं — reset hard ऐसा करेगा। स्थानीय ब्रांच में, आप reset mixed का उपयोग करके कमिट को पूर्ववत कर सकते हैं लेकिन बदलावों को वर्किंग डायरेक्टरी में रख सकते हैं ताकि फिर से कमिट कर सकें।

# अंतिम कमिट पूर्ववत करें, वर्किंग डायरेक्टरी में बदलाव रखें
git reset HEAD~1

# पूर्ण पूर्ववत — बदलाव स्थायी रूप से हटा दिए जाते हैं
git reset --hard HEAD~2

डेटाबेस में रोलबैक: लेन-देन और ACID

लेन-देन रोलबैक — एक प्रक्रिया जो वर्तमान लेन-देन में किए गए सभी बदलावों को पूर्ववत करती है और डेटाबेस को लेन-देन की शुरुआत की स्थिति में लौटाती है। यह परमाणुता की गारंटी देता है — ACID के चार सिद्धांतों (Atomicity, Consistency, Isolation, Durability) में से एक। यदि लेन-देन के किसी भी चरण में त्रुटि होती है, तो rollback निष्पादित होता है और डेटा अपनी मूल स्थिति में वापस आ जाता है।

रोलबैक तंत्र राइट-अहेड लॉग (WAL) के माध्यम से कार्यान्वित किया जाता है। डेटा पृष्ठ को संशोधित करने से पहले, DBMS पुराने और नए मान लॉग में लिखता है। रोलबैक के दौरान, सिस्टम लॉग पढ़ता है और सभी संशोधित पृष्ठों के लिए मूल मानों को पुनर्स्थापित करता है। यह सुनिश्चित करता है कि बिजली की विफलता की स्थिति में भी, लेन-देन को सही ढंग से पूर्ववत किया जा सके।

BEGIN TRANSACTION;

UPDATE accounts
SET balance = balance - 100
WHERE id = 1;

-- Rollback on error
ROLLBACK;

Savepoint: आंशिक रोलबैक

लंबे लेन-देन में, savepoint का उपयोग करना सुविधाजनक है — मध्यवर्ती सेव बिंदु जिन पर पूरे लेन-देन को पूरा किए बिना वापस लौटा जा सकता है। यह जटिल प्रक्रिया के अंदर त्रुटियों को संभालने की अनुमति देता है, बिना इसके अन्य भागों की प्रगति खोए। Savepoint अधिकांश रिलेशनल DBMS द्वारा समर्थित है: PostgreSQL, MySQL, Oracle।

SAVEPOINT sp1;

UPDATE orders SET status = 'cancelled'
WHERE id = 42;

ROLLBACK TO sp1;

डिप्लॉयमेंट में रोलबैक: रणनीतियाँ और उपकरण

डिप्लॉयमेंट रोलबैक — असफल डिप्लॉयमेंट के बाद चल रहे एप्लिकेशन को पिछले संस्करण पर लौटाना। यह प्रोडक्शन वातावरण के लिए एक महत्वपूर्ण क्षमता है: पुनर्प्राप्ति समय (MTTR) सीधे SLA और उपयोगकर्ता अनुभव को प्रभावित करता है। आधुनिक प्लेटफ़ॉर्म आर्किटेक्चर और उपलब्धता आवश्यकताओं के आधार पर कई रोलबैक रणनीतियाँ प्रदान करते हैं।

Blue-green deployment

Blue-green — एक रणनीति जिसमें दो समान वातावरण एक साथ चलते हैं: blue (वर्तमान संस्करण) और green (नया संस्करण)। सफल डिप्लॉयमेंट के बाद ट्रैफ़िक green पर स्विच हो जाता है। यदि नया संस्करण गलत काम करता है, तो ट्रैफ़िक स्विच blue पर वापस आ जाता है। रोलबैक तुरंत किया जाता है, बिना पुनः डिप्लॉयमेंट के — बस रूटिंग बदलें।

Canary release स्वचालित रोलबैक के साथ

Canary deployment ट्रैफ़िक का एक छोटा हिस्सा नए संस्करण पर भेजता है और मीट्रिक्स पर नज़र रखता है: त्रुटि दर, प्रतिक्रिया समय, सफल अनुरोधों का प्रतिशत। यदि मीट्रिक्स बिगड़ते हैं, तो सिस्टम स्वचालित रूप से canary को रोलबैक करता है और सभी ट्रैफ़िक को स्थिर संस्करण पर भेजता है। Kubernetes और सर्विस मेश (Istio, Linkerd) इस रणनीति को बिल्ट-इन समर्थन देते हैं।

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 10
  strategy:
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

डेवलपमेंट में रोलबैक के व्यावहारिक उदाहरण

आइए तीन सामान्य परिदृश्यों पर विचार करें जिनमें डेवलपर को बदलावों को रोलबैक करने की आवश्यकता होती है। प्रत्येक परिदृश्य में अपने दृष्टिकोण की आवश्यकता होती है — टर्मिनल में एक सरल कमांड से लेकर CI/CD से जुड़ी बहु-चरणीय प्रक्रिया तक।

परिदृश्य 1: main में आकस्मिक कमिट

आपने गलती से main में एक बग वाला कमिट पुश कर दिया। आपका काम टीम के लिए इतिहास खोए बिना बदलावों को रोलबैक करना है। रोलबैक कमिट बनाने के लिए git revert का उपयोग करें और फिर git push करें। टीम के सभी सदस्य रोलबैक देखेंगे और बिना विरोध के काम जारी रख सकेंगे। यह सबसे सुरक्षित और पारदर्शी तरीका है।

git checkout main
git pull origin main
git revert HEAD
git push origin main

परिदृश्य 2: असफल डेटाबेस माइग्रेशन

डेटाबेस माइग्रेशन विफल रहा और कुछ डेटा दूषित हो गया। माइग्रेशन स्क्रिप्ट में लेन-देन संबंधी rollback का उपयोग करें और पहले से लागू बदलावों के लिए बैकअप से पुनर्स्थापित करें। एक अच्छी तरह से डिज़ाइन किए गए सिस्टम में, प्रत्येक माइग्रेशन एक लेन-देन में लपेटा जाता है — त्रुटि पर, DBMS स्वचालित रूप से rollback करता है।

परिदृश्य 3: गंभीर बग के साथ डिप्लॉयमेंट

नए संस्करण को डिप्लॉय करने के बाद, आप पाते हैं कि प्रमाणीकरण काम नहीं कर रहा है। यदि आप blue-green का उपयोग करते हैं, तो रोलबैक राउटर को वापस स्विच करना है। यदि रोलिंग अपडेट — kubectl rollout undo कमांड पिछले संस्करण को लौटा देगा। आदर्श रूप में, रोलबैक प्रक्रिया स्वचालित होनी चाहिए और एक मिनट से अधिक नहीं लेनी चाहिए।