हम एक मानक LAMP कॉन्फ़िगरेशन पर, एक सामाजिक वेबसाइट चलाते थे। हमारे पास एक लाइव सर्वर, टेस्ट सर्वर और विकास सर्वर, साथ ही साथ स्थानीय डेवलपर्स मशीनें थीं। सभी को जीआईटी का उपयोग करके प्रबंधित किया गया।
प्रत्येक मशीन पर, हमारे पास PHP फाइलें थीं, लेकिन MySQL सेवा भी थी, और एक फ़ोल्डर जिसमें उपयोगकर्ता अपलोड करेंगे। लाइव सर्वर कुछ 100K (!) आवर्तक उपयोगकर्ताओं के लिए बढ़ गया, डंप लगभग 2GB (!) था, छवि फ़ोल्डर कुछ 50GB (!) था। जब तक मैंने छोड़ा, तब तक हमारा सर्वर अपने सीपीयू, राम की सीमा तक पहुंच रहा था, और सबसे बढ़कर, समवर्ती नेट कनेक्शन सीमाएं (हमने सर्वर कार्ड ड्राइवर के अपने संस्करण का संकलन किया था ताकि सर्वर 'लोल' को अधिकतम किया जा सके)। हम जीआईटी में 2GB डेटा और 50GB इमेज नहीं डाल सकते ( न ही आपको अपनी वेबसाइट के साथ मान लेना चाहिए )।
GIT के तहत यह सब आसानी से प्रबंधित करने के लिए, हम इन फ़ोल्डर रास्तों को .gitignore में डालकर बाइनरी फ़ोल्डर्स (चित्र युक्त फ़ोल्डर) को अनदेखा करेंगे। हमारे पास Apache documentroot पथ के बाहर SQL नामक एक फ़ोल्डर भी था। उस एसक्यूएल फ़ोल्डर में, हम अपनी एसक्यूएल फाइलों को डेवलपर्स से वृद्धिशील संख्याओं (001.florianm.sql, 001.johns.sql, 002.florianm.sql, आदि) में डालेंगे। इन SQL फ़ाइलों को GIT द्वारा प्रबंधित किया गया था। पहली sql फ़ाइल में वास्तव में DB स्कीमा का एक बड़ा सेट होगा। हम GIT में उपयोगकर्ता-डेटा नहीं जोड़ते हैं (उदाहरण के लिए उपयोगकर्ता तालिका, या टिप्पणियाँ तालिका के रिकॉर्ड), लेकिन कॉन्फ़िगर या टोपोलॉजी या अन्य साइट विशिष्ट डेटा जैसे डेटा, sql फ़ाइलों (और इसलिए GIT) में बनाए रखा गया था। ज्यादातर इसके डेवलपर्स (जो कोड को सबसे अच्छा जानते हैं) जो यह निर्धारित करते हैं कि SQL स्कीमा और डेटा के संबंध में GIT द्वारा क्या और क्या बनाए रखा गया है।
जब यह एक रिलीज़ के लिए मिला, तो व्यवस्थापक देव सर्वर पर लॉग इन करता है, सभी डेवलपर्स के साथ लाइव शाखा को मर्ज करता है और देव मशीन पर एक अद्यतन शाखा के लिए आवश्यक शाखाओं, और इसे परीक्षण सर्वर पर धकेल दिया। परीक्षण सर्वर पर, वह जाँचता है कि लाइव सर्वर के लिए अद्यतन प्रक्रिया अभी भी मान्य है, और त्वरित उत्तराधिकार में, अपाचे में सभी ट्रैफ़िक को एक प्लेसहोल्डर साइट पर इंगित करता है, एक डीबी डंप बनाता है, कार्यशील निर्देशिका को 'लाइव' से 'अपडेट' तक इंगित करता है। ', mysql में सभी नई sql फ़ाइलों को निष्पादित करता है, और ट्रैफ़िक को सही साइट पर वापस भेजता है। जब सभी हितधारकों ने परीक्षण सर्वर की समीक्षा के बाद सहमति व्यक्त की, तो व्यवस्थापक ने परीक्षण सर्वर से लाइव सर्वर तक एक ही काम किया। बाद में, वह उत्पादन सर्वर पर लाइव शाखा को मर्ज करता है, सभी सर्वरों के पार मास्टर शाखा में, और सभी लाइव शाखाओं को रीबूट करता है।
यदि परीक्षण सर्वर पर समस्याएं थीं, उदाहरण के लिए। मर्ज में बहुत अधिक संघर्ष थे, फिर कोड को वापस कर दिया गया था (कार्य शाखा को 'लाइव' की ओर इशारा करते हुए) और sql फ़ाइलों को कभी भी निष्पादित नहीं किया गया था। जिस क्षण SQL फ़ाइलों को निष्पादित किया गया था, उस समय यह एक गैर-प्रतिवर्ती कार्रवाई के रूप में माना जाता था। यदि SQL फाइलें ठीक से काम नहीं कर रही थीं, तो DB को डंप का उपयोग करके बहाल किया गया था (और डेवलपर्स ने बताया कि, गैर-परीक्षण SQL फ़ाइलों को प्रदान करने के लिए)।
आज, हम समान फ़ाइल नाम के साथ, एक sql-up और sql-down फ़ोल्डर दोनों को बनाए रखते हैं, जहाँ डेवलपर्स को यह परीक्षण करना होता है कि दोनों उन्नयन sql फाइलें समान रूप से डाउनग्रेड की जा सकती हैं। यह अंततः बैश स्क्रिप्ट के साथ निष्पादित किया जा सकता है, लेकिन इसका एक अच्छा विचार है अगर मानव आंखें अपग्रेड प्रक्रिया की निगरानी करती रहीं।
यह महान नहीं है, लेकिन इसके प्रबंधन योग्य है। आशा है कि यह वास्तविक, व्यावहारिक, अपेक्षाकृत उच्च उपलब्धता वाली साइट में एक अंतर्दृष्टि देता है। थोड़ा पुराना हो, लेकिन अभी भी पीछा किया।