क्लाउड / सिस्टम
प्रॉम्प्ट से यह वेबसाइट कैसे बनी में मैंने बताया था कि एआई की मदद से पुरानी WordPress वेबसाइट को AWS S3 और CloudFront पर चलने वाली स्थिर वेबसाइट में कैसे बदला। मुझे अंदाज़ा नहीं था कि एक छोटी निजी वेबसाइट इतनी जल्दी जटिल सॉफ़्टवेयर परियोजना बन जाएगी।
जटिलता धीरे-धीरे कैसे बढ़ी
शुरुआत कुछ पन्नों से हुई। फिर मौसम पूर्वानुमान, प्रशिक्षण का डेटा, गेम, सुरक्षा जाँच, स्वचालित रिलीज़ और नौ भाषाएँ जुड़ गईं। अंग्रेज़ी के साथ जर्मन, स्पैनिश, चीनी, फ़्रेंच, ब्राज़ीलियाई पुर्तगाली, जापानी, हिंदी और डच शामिल किए। पाठकों तक पहुँच बढ़ी, लेकिन हर भाषा के साथ HTML, नेविगेशन, फ़ीड, मेटाडेटा और विफलता की संभावनाएँ भी बढ़ीं।
हमारी भोली धारणा थी कि स्थिर वेबसाइट है, इसलिए हर बदलाव पर नौ संस्करण फिर से बनाना सस्ता ही होगा। लेकिन अंग्रेज़ी में छोटे सुधार को भी फ़ॉन्ट डाउनलोड, चित्र निर्माण, दूसरी भाषाओं की नेविगेशन, साइटमैप और सुरक्षा जाँच का इंतज़ार करना पड़ता था। हमने सभी नौ भाषाओं को एक ही अनिवार्य रिलीज़ प्रक्रिया में बाँध दिया था।
प्रकाशन से पहले सभी भाषाएँ पूरी करनी पड़ती थीं
समस्या अनुवाद नहीं, बल्कि निर्भरताओं का ग़लत डिज़ाइन था।
सुरक्षा के उपाय कब रुकावट बन गए
GitHub के इतिहास में सीक्रेट स्कैनर की समस्याएँ, पुनरुत्पादित बिल्ड में अंतर, फ़ॉन्ट इंस्टॉलेशन का अटकना, वर्कफ़्लो कॉन्फ़िगरेशन त्रुटियाँ और AWS IAM अनुमतियों की कमी दिखाई देती है। एक रिकवरी के दौरान 534 सार्वजनिक ऑब्जेक्ट जाँचे गए: 501 अपेक्षा के अनुरूप थे, 24 में अंतर था और नौ नए पन्ने पढ़े नहीं जा सके।
हर सुरक्षा उपाय का कारण था। पर सभी मिलकर छोटे बदलाव भी मुश्किल बना रहे थे। ज़्यादा ऑटोमेशन हमेशा बेहतर ऑटोमेशन नहीं होता। लाल जाँच को नज़रअंदाज़ नहीं करना चाहिए; उसका कारण खोजना चाहिए।
नया डिज़ाइन: पहले अंग्रेज़ी, फिर आठ भाषाएँ
हम मुख्य भाषा के प्रकाशन और बाद के जाँचे हुए अनुवादों को अलग कर रहे हैं।
कम बेहतर है
यह चित्र प्रस्तावित प्रकाशन क्रम दर्शाता है, न कि इस बात का प्रमाण कि उत्पादन में यह क्रम पहले ही चल चुका है। अनुवाद की मंज़ूरी अंग्रेज़ी स्रोत के सटीक SHA-256 हैश से जुड़ी रहती है। अंग्रेज़ी स्रोत बदले तो पुरानी मंज़ूरी अमान्य हो जाती है। अनुवाद न होने पर अंग्रेज़ी सामग्री को दूसरी भाषा बताकर कभी प्रकाशित नहीं करना चाहिए।
पुनरुत्पादित बिल्ड, OIDC, AWS की न्यूनतम अनुमतियाँ, लागत सीमा और CloudFront की कोई इनवैलिडेशन नहीं करने का नियम बना रहेगा।
वास्तव में क्या सत्यापित हुआ
PR #119–#122 ने अंग्रेज़ी लेख कंपाइलर, आठ समीक्षा किए हुए अनुवादों का कंपाइलर और अंग्रेज़ी → भाषाएँ → संपूर्ण सत्यापन का क्रम तैयार किया। मैनुअल परीक्षण वर्कफ़्लो के पास AWS पर लिखने की अनुमति नहीं है। चरणबद्ध प्रकाशन के लिए अभी भी स्पष्ट स्वीकृति चर चाहिए; मौजूदा OIDC वर्कफ़्लो S3 अपलोड से पहले पूरे साइट की जाँच करता है।
इसलिए CI का हरा होना यह साबित नहीं करता कि अंग्रेज़ी प्रकाशित हो गई थी और आठ अनुवाद अभी संसाधित हो रहे थे। पुराने शैडो लॉग में sourceToHtmlBuildComplete=false, productionDeploymentApproved=false और शून्य S3 लिखने की क्रियाएँ दर्ज थीं।
समय में दर्ज वास्तविक सुधार
हमने 7 नवंबर 2026 को नौ भाषाओं के चेंजलॉग में किए गए दो समान बदलावों की तुलना की। ये पुराने पूरे बिल्ड के आँकड़े हैं, अलग-अलग चरणों में हुए दो वास्तविक उत्पादन डिप्लॉयमेंट की तुलना नहीं।
| माप | पहले | बाद में | अंतर |
|---|---|---|---|
| ऑफ़लाइन CI | 3 मिनट 38 सेकंड (218 s) | 3 मिनट 18 सेकंड (198 s) | 9.2% तेज़ |
| पूरी साइट की गुणवत्ता जाँच | 2 मिनट 55 सेकंड (175 s) | 2 मिनट 27 सेकंड (147 s) | 16.0% तेज़ |
| Gitleaks | 56 s | 67 s | 11 s धीमा |
| Semgrep | 10 s | 11 s | लगभग समान |
| pip-audit | 13 s | 12 s | लगभग समान |
| PR खोलने से merge तक | 41:50 मिनट | 34:29 मिनट | 7:21 मिनट कम |
कम बेहतर है
गुणवत्ता जाँच ऑफ़लाइन CI के समय के भीतर आती है; दोनों को जोड़ना ग़लत होगा। सुरक्षा जॉब समानांतर चलती हैं। इन दस्तावेज़ संबंधी बदलावों में Semgrep और pip-audit के महँगे स्कैन चरण छोड़ दिए गए थे। केवल दो परीक्षण किसी स्थायी सुधार का प्रमाण नहीं हैं।
हमने एक जैसे assets की दोबारा जाँच कम की, नेविगेशन के SHA-256 हैश दोबारा इस्तेमाल किए, Python और Sharp डाउनलोड का कैश बनाया, जनरेटर के समय को मापा और केवल दस्तावेज़ बदलने के लिए तेज़ रास्ता जोड़ा।
अंग्रेज़ी की तेज़ जाँच
एक स्वतंत्र शैडो बेंचमार्क में अंग्रेज़ी HTML जाँच 0.562 सेकंड में पूरी हुई: 60 अंग्रेज़ी पन्ने, 96 assets और 514 स्थानीय HTML लिंक। अंग्रेज़ी merge की नक़ली जाँच का क्रम 15 सेकंड चला। अन्य भाषाओं की 501 फ़ाइलें नहीं बदलीं।
ये अलग-अलग घटकों और अभ्यास के समय हैं, merge से वास्तविक S3 प्रकाशन तक का समय नहीं। 15 सेकंड की सीधी तुलना पूरे CI के 198 सेकंड से करना भ्रामक होगा।
Pull Request से लाइव पन्ने तक
PR स्वयं डिप्लॉयमेंट नहीं होता। समीक्षा, जाँच और merge के बाद रिलीज़ प्रक्रिया सटीक फ़ाइलें, SHA-256 मैनिफ़ेस्ट, AWS अनुमतियाँ और बजट जाँचती है। फिर ही S3 पर अपलोड होता है। CloudFront भुगतान वाली इनवैलिडेशन के बजाय सामान्य TTL से अपडेट होता है।
वास्तविक चरणबद्ध प्रकाशन साबित करने के लिए हम T0 अंग्रेज़ी merge, T1 जाँच पूरी, T2 अंग्रेज़ी S3 अपलोड की पुष्टि, T3 अनुवाद प्रक्रिया की शुरुआत और समाप्ति तथा T4 आठ भाषाओं के अपलोड की पुष्टि दर्ज करेंगे। तभी पाठकों को अंग्रेज़ी कितनी जल्दी मिली, यह मापा जा सकेगा।
AI के साथ डिबगिंग
ChatGPT विफल PR के लॉग पढ़ सकता है, छोटा सुधार सुझा सकता है और अगली CI जाँच देख सकता है। शाम को यह विशेष रूप से उपयोगी है। लेकिन इसका मतलब यह नहीं कि चैट बिना सक्रिय सत्र या उपकरणों के हमेशा अपने-आप काम करती रहेगी। अंतिम समीक्षा आवश्यक है।
मुख्य सबक
उद्देश्य केवल कुछ सेकंड बचाना नहीं है। पहला उपयोगी परिणाम हर बाद के वैकल्पिक परिणाम पर निर्भर नहीं होना चाहिए। अंग्रेज़ी को जल्दी और विश्वसनीय रूप से प्रकाशित करना चाहिए; आठ अनुवाद समान गुणवत्ता के साथ बाद में आएँ। असली लाभ को उत्पादन के वास्तविक समय से साबित करना होगा।