हमारे पास एक ईकॉमर्स ऐप है जिसे हम अपनी कंपनी में विकसित करते हैं। इसका एक यथोचित मानक LAMP अनुप्रयोग है जिसे हम लगभग 3 वर्षों से विकसित और बंद कर रहे हैं। हम एक परीक्षण डोमेन पर एप्लिकेशन विकसित करते हैं, यहां हम नई सुविधाओं को जोड़ते हैं और बग आदि को ठीक करते हैं। हमारी बग ट्रैकिंग और सुविधा विकास सभी एक होस्ट किए गए तोड़फोड़ समाधान (unfuddle.com) के भीतर प्रबंधित किए जाते हैं। जैसा कि बग्स में बताया गया है कि हम इन सुधारों को परीक्षण डोमेन पर बनाते हैं और फिर svn में परिवर्तन करते हैं जब हम खुश होते हैं कि बग को ठीक कर दिया गया है। हम नई सुविधाओं को जोड़ने के साथ इसी प्रक्रिया का पालन करते हैं।
यह हमारे सर्वर पर हमारे सिस्टम और एप्लिकेशन की सामान्य वास्तुकला को इंगित करने के लायक है। जब भी कोई नई सुविधा विकसित की जाती है तो हम अपने एप्लिकेशन (हमेशा एक सर्वर जिसे हम नियंत्रित करते हैं) का उपयोग करके इस अपडेट को सभी साइटों पर रोल आउट कर देते हैं। हमारे सिस्टम का उपयोग करने वाली प्रत्येक साइट अनिवार्य रूप से 95% कोडबेस के लिए समान फ़ाइलों का उपयोग करती है। हमारे पास प्रत्येक साइट के भीतर कुछ फ़ोल्डर्स होते हैं जिनमें उस साइट पर bespoke फाइलें होती हैं - css फाइलें / चित्र आदि। इसके अलावा प्रत्येक साइट के बीच के अंतर को प्रत्येक साइट डेटाबेस के भीतर विभिन्न कॉन्फ़िगरेशन सेटिंग्स द्वारा परिभाषित किया जाता है।
यह वास्तविक परिनियोजन पर ही मिलता है। जब हम किसी प्रकार का अपडेट रोल करने के लिए तैयार होते हैं, तब हम सर्वर पर एक कमांड चलाते हैं जो परीक्षण स्थल पर होती है। यह एक कॉपी कमांड (cp -fru / testite / / othersite /) करता है और संशोधित तिथि के आधार पर फाइलों को अपडेट करने वाले प्रत्येक vhost बल से गुजरता है। प्रत्येक अतिरिक्त सर्वर जिसे हम होस्ट करते हैं, में एक vhost है जिसे हम उत्पादन कोडबेस पर rsync करते हैं और हम उस सर्वर पर सभी साइटों पर प्रतिलिपि प्रक्रिया को दोहराते हैं। इस प्रक्रिया के दौरान हम उन फ़ाइलों को बाहर निकाल देते हैं जिन्हें हम अधिलेखित नहीं करना चाहते हैं, जब प्रतिलिपि पूरी हो गई है तो उन्हें वापस ले जाना। हमारी रोलआउट स्क्रिप्ट कई अन्य फ़ंक्शन करती है जैसे कि SQL कमांड को लागू करना प्रत्येक डेटाबेस को बदलने के लिए, फ़ील्ड / नई टेबल आदि को जोड़ना।
हम इस बात से चिंतित हो गए हैं कि हमारी प्रक्रिया पर्याप्त रूप से स्थिर नहीं है, दोष-सहिष्णु नहीं है और यह एक क्रूर-बल विधि भी है। हम यह भी जानते हैं कि हम तोड़फोड़ का सबसे अच्छा उपयोग नहीं कर रहे हैं क्योंकि हमारे पास एक ऐसी स्थिति है जहां एक नई सुविधा पर काम करने से हमें एक महत्वपूर्ण बग फिक्स को रोकने में मदद मिलेगी क्योंकि हम शाखाओं या टैग का उपयोग नहीं कर रहे हैं। यह भी गलत लगता है कि हमारे पास हमारे सर्वर पर फ़ाइलों की इतनी अधिक प्रतिकृति है। हम आसानी से एक रोलबैक करने में सक्षम नहीं हैं जो हमने अभी-अभी रोल आउट किया है। हम प्रत्येक रोलआउट से पहले एक प्रदर्शन करते हैं ताकि हम उन फ़ाइलों की एक सूची प्राप्त कर सकें जिन्हें बदल दिया जाएगा ताकि हम जान सकें कि बाद में क्या बदला गया है लेकिन रोलबैक करने की प्रक्रिया अभी भी समस्याग्रस्त होगी। डेटाबेस के संदर्भ में मैंने dbdeploy को एक संभावित समाधान के रूप में देखना शुरू कर दिया है। हम वास्तव में क्या चाहते हैं, हालांकि हम इस बारे में कुछ सामान्य मार्गदर्शन कर रहे हैं कि हम अपने फ़ाइल प्रबंधन और परिनियोजन में कैसे सुधार कर सकते हैं। आदर्श रूप से हम चाहते हैं कि फ़ाइल प्रबंधन हमारी रिपॉजिटरी से अधिक निकटता से जुड़ा हो ताकि रोलआउट / रोलबैक svn से अधिक जुड़ा हो। एक्सपोर्ट कमांड का उपयोग करने के लिए कुछ इस तरह से सुनिश्चित करें कि साइट फाइलें रेपो फाइलों जैसी ही हों। यह भी अच्छा होगा हालांकि अगर समाधान शायद हमारे सर्वर के आसपास फ़ाइल प्रतिकृति को भी रोक देगा।
हमारे वर्तमान तरीकों को अनदेखा करना वास्तव में यह सुनना अच्छा होगा कि अन्य लोग उसी समस्या को कैसे देखते हैं।
संक्षेपित करते हुए ...
- कई सर्वरों पर फाइलें बनाने का सबसे अच्छा तरीका svn के साथ सिंक में रहना है?
- हमें फ़ाइल प्रतिकृति को कैसे रोकना चाहिए? सहानुभूति / कुछ और?
- हमें अपने रेपो की संरचना कैसे करनी चाहिए ताकि हम नई सुविधाओं को समर्पित कर सकें और पुराने को ठीक कर सकें?
- हमें रोलआउट / रोलबैक कैसे ट्रिगर करना चाहिए?
अग्रिम में धन्यवाद
संपादित करें:
मैं हाल ही में उपयोग के बारे में अच्छी बातें की एक बहुत कुछ पढ़ा है Phing और Capistrano कार्यों के इन प्रकार के लिए। क्या कोई उनके बारे में और अधिक जानकारी दे सकता है और इस तरह के कार्य के लिए वे कितने अच्छे होंगे?