एसवीएन वेब डेवलपमेंट वर्कफ़्लो

Question

मैंने इस मुद्दे से संबंधित कुछ प्रश्नों के बारे में यहां पढ़ा है, लेकिन मुझे वास्तव में कोई अच्छी सलाह नहीं मिल सकती है जो हमारी स्थिति को फिट करे। मैंने इस काम प्रवाह को विरासत में मिला, और मैं इसे बेहतर बनाने की कोशिश कर रहा हूं।

हमारे स्थापना

• PHP कोड आधार (विशेष रूप से Kohana)
• कोड बेस शक्तियों ~ 60 साइटों, विशिष्ट टेम्प्लेट के साथ प्रत्येक (यानी 60 क्यूए [गुणवत्ता आश्वासन] भी डोमेन) को
• प्रत्येक साइट में विभिन्न संपत्तियों और संसाधनों के लिए ए-रिकॉर्ड होते हैं (यानी प्रत्येक डोमेन के लिए 8 ए-रिकॉर्ड)
• 3 डेवलपर्स
• 3 डिज़ाइनर
• डेवलपर्स स्थानीय विकास
• डिजाइनरों नहीं
• साझा शारीरिक विकास गुणवत्ता आश्वासन के लिए इस्तेमाल किया, एक के बाद प्रतिबद्ध अद्यतन सर्वर हर समय ट्रंक की वर्तमान सिर पर इस सर्वर रहता
• उत्पादन करना के लिए उत्पादन सर्वर VMware छवि है सर्वर, एक मिश्रण है और क्या सुविधाओं के आधार पर विभिन्न संशोधनों के मैच के लिए अद्यतन

हमारा काम प्रवाह कर दिया जाता

• डेवलपर्स स्थानीय रूप से काम करते हैं जब तक कि किसी दिए गए फीचर को पूरा नहीं किया जाता है और फिर आंतरिक क्यूए के लिए पूरी सुविधा को ट्रंक करने के लिए प्रतिबद्ध करते हैं।
• डिजाइनर केवल सीएसएस/छवियों/टेम्पलेट्स में छोटे बदलाव करते हैं। वे सीधे ट्रंक करने के लिए प्रतिबद्ध होते हैं, क्यूए अपने स्वयं के परिवर्तन करते हैं, और उत्पादन सर्वर पर संबंधित फाइलों को अपडेट करते हैं, आमतौर पर, उनके क्यूए के तुरंत बाद बोलते हैं।
• जब सुविधाएं लाइव जाने के लिए तैयार हों, तो उत्पादन सर्वर को सुविधा से संबंधित प्रत्येक फ़ाइल के लिए मैन्युअल रूप से उचित संशोधन संख्या में अपडेट किया जाता है। कभी-कभी यह आसान होता है, दूसरी बार यह काफी बालों वाली होती है (svn log कॉल अपस्ट्रीम निर्भरताओं की तलाश में)।

हमारी समस्याओं

• तीन अलग अलग विशेषताएं है कि गुणवत्ता आश्वासन के विभिन्न मात्रा की जरूरत पर काम कर डेवलपर्स के साथ, हम अपने आप को एक नियमित आधार पर नदी के ऊपर निर्भरता समस्याओं में घिर गए हैं।
• किसी भी समय, हमारे पास प्रोग्रामेटिक रूप से यह निर्धारित करने का कोई तरीका नहीं है कि उत्पादन सर्वर पर कौन सी सुविधाएं हैं और जो नहीं हैं। svn status -u हमें दिखाएगा कि कौन सी फाइलें अद्यतित नहीं हैं, लेकिन यह आम तौर पर सुविधाओं की स्पष्ट तस्वीर नहीं है।

मैं जानता हूँ कि क्या

• हमारे समस्याओं में से कुछ एक उत्पादन शाखा होने से कम किया जा सकता है। हम कम से कम निगरानी कर सकते हैं कि कौन सी विशेषताओं को उत्पादन में जोड़ा जा रहा था और जब, हालांकि यह अपस्ट्रीम निर्भरता के मुद्दों को हल नहीं करेगा।
• फ़ीचर शाखाएं एक विकल्प हैं, और हमने अतीत में कोशिश की है।इस तथ्य के कारण कि हमारे सॉफ़्टवेयर को प्रति शाखा 60 क्यूए डोमेन की आवश्यकता है, हम वहां प्रक्रिया प्रबंधन के मुद्दों में भाग लेते हैं। उदाहरण के लिए, 480 (60 डोमेन x 8 रिकॉर्ड प्रति डोमेन) का निर्माण प्रत्येक सुविधा शाखा के लिए ए-रिकॉर्ड।
• डेवलपर शाखाएं भी एक विकल्प हैं, लेकिन हमारी सुविधा क्यूए समय अलग-अलग होती है। मैं निश्चित रूप से यह नहीं कह सकता कि मुझे कुछ और करने की आवश्यकता होने से पहले पिछली सुविधा क्यूए से बाहर होगी।

अपस्ट्रीम निर्भरता उदाहरण

• डेवलपर एक दोनों व्यवस्थापक और सामने के अंत में एक नई स्लाइड शो सुविधा जोड़ता है।
• डेवलपर बी व्यवस्थापक और फ्रंट एंड दोनों में एक नई प्रतिक्रिया सुविधा जोड़ता है।
• इन दोनों सुविधाओं में स्थान मॉडल/नियंत्रक तर्क के साथ अंतर्निहित हैं, इसलिए उन नई फ़ाइलों के लिए उन संबंधित फ़ाइलों में परिवर्तन किए जाते हैं।
• स्लाइड शो सुविधा क्यूए में प्रवेश करती है, लेकिन कुछ विकास संबंधी निरीक्षण या स्कोप रेंगने द्वारा आयोजित की जाती है।
• फीडबैक फीचर QA में प्रवेश करती है और बिना किसी समस्या के गुजरती है।
• हम समयरेखा का पालन करना चाहते हैं और फीडबैक फीचर को उत्पादन में धक्का देना चाहते हैं, लेकिन हम इसे सीधे नहीं कर सकते क्योंकि दोनों सुविधाओं को स्थान मॉडल/नियंत्रक में परिवर्तन की आवश्यकता होती है। यही है, हम सिर्फ svn update file1 file2 file3 नहीं कर सकते हैं।
• नोट:यह एक साधारण उदाहरण है, और इसे कुछ रिवर्स विलय करके चारों ओर काम किया जा सकता है। अक्सर हमारी समस्याएं इससे जटिल होती हैं।

मल्टी साइट संरचना सूचना

• हम आदि पूर्व निर्धारित संरचनात्मक विषयों के एक नंबर, विचार, छवियों, सीएसएस फ़ाइलें, जे एस फ़ाइलें से मिलकर, है
• प्रत्येक साइट एक विषय सौंपा गया है।
• ब्रांडिंग और विस्तारशीलता कारणों के लिए, प्रत्येक साइट कस्टम दृश्य के साथ थीम व्यू को ओवरराइड कर सकती है या अतिरिक्त साइट-विशिष्ट सीएसएस/जेएस फाइलें शामिल कर सकती है।

मुझे यकीन है कि वहां कुछ अन्य लोग हैं जो समान मुद्दों से जूझ रहे हैं, और मैं इंटरनेट पर स्मार्ट लोगों से कुछ अंतर्दृष्टि प्राप्त करने की उम्मीद कर रहा हूं। कृपया कुछ पूछने के लिए स्वतंत्र महसूस करें अगर मैंने जो कुछ कहा वह मिट्टी के रूप में स्पष्ट लगता है!

Answer 1

आपका कार्यप्रवाह सुधार किया जा सकता है, यहाँ मेरी सलाह की एक सूची है:

• प्रारंभ हुए नियमित चक्र में SVN शाखाओं और रिहाई बनाता है/तैनाती का उपयोग कर।
• यह पता लगाएं कि आपका तैनाती चक्र कब तक होना चाहिए, क्यूए के लिए समय छोड़ना। तो उदाहरण के लिए यदि आप हर महीने एक बिल्ड जारी करने जा रहे हैं तो विकास के 3 सप्ताह और क्यूए के 1 सप्ताह हैं। बग फिक्स को छोड़कर 3 सप्ताह के बाद उस निर्माण के लिए विकास को फ्रीज करें।
• आपके निर्माण के लिए एक नंबरिंग योजना पर निर्णय लें जो
• टिकटिंग सिस्टम (एक्टिव कोलाब, जेरा, मंटिस ... आदि) का उपयोग करें और इस नियम को लागू करें कि किसी भी प्रतिबद्धता को टिकट से जोड़ा जाना है। वह जगह चुनें जहां आप अपने काम टिकट में स्वचालित रूप से दिखा सकते हैं।
• आप विकास शुरू करने से पहले अपनी आवश्यकताओं के दस्तावेज़ के लिए, अपने (देवताओं खातिर) टिकट प्रणाली में आवश्यकताओं
• ऐसा करने में मदद मिलेगी आप यह निर्धारित क्या सुविधाओं किसी दिए गए निर्माण में हैं इकट्ठा नहीं है शुरू करने के लिए जा रहे हैं। तो टिकट संख्याओं की सूची या प्रत्येक निर्माण के लिए टिकटों का सामान्य वर्णन के साथ कुछ प्रकार के रिलीज नोट्स बनाएं।
• अपने आवेदन में अपनी बिल्ड संख्याएं एम्बेड करें ताकि आप किसी भी दिए गए सिस्टम पर तैनाती ट्रैक कर सकें।
• क्यूए की गति बढ़ाने के लिए स्वचालित परीक्षण उपकरणों के लिए PHPUnit और कार्यात्मक परीक्षणों के लिए सेलेनियम के साथ काम करना शुरू करें और वेब एप्लिकेशन की गुणवत्ता/स्थिरता में वृद्धि करें जिससे दिन की दैनिक परिवर्तन नई बग पेश हो सके।
• हडसन और फ़िंग आपके निर्माण को स्वचालित करने और आपके परीक्षण को स्वचालित करने के लिए जीवनभर हो सकते हैं।

Answer 2

ठीक है, विचारों के एक जोड़े:

कार्यप्रवाह इस तरह का के लिए, तुम बहुत बेहतर एक धारा मॉडल, Accurev या ClearCase तरह के साथ एक एससीएम के साथ करना होगा। एक स्ट्रीम मॉडल में, काम प्रत्येक डेवलपर की धाराओं से एकीकरण धाराओं तक, फिर क्यूए धाराओं तक बहता है, फिर धाराएं जारी करने के लिए (या जो भी सबसे अच्छा काम करता है)। केवल अगले चरण में अग्रिम करने के लिए तैयार काम बढ़ जाता है, और अकेले काम के उन बंडलों के साथ एकीकरण किया जा सकता है।

जैसा कि धोखाधड़ी के रूप में कहा जाता है, आपको चीजों को अधिक मॉड्यूलर रूप से तोड़ने की आवश्यकता होती है, लेकिन आपको इसे स्थानीयकरण प्रणाली के साथ संयोजित करने की भी आवश्यकता होती है जहां क्लाइंट-विशिष्ट कार्यक्षमता कोड के विशिष्ट हिस्सों को ओवरराइड कर सकती है। एक तरीका मैंने PHP में किया है कि एक PHP फ़ाइल आयात रैपर लागू करना है जो पहले PHP फ़ाइल के क्लाइंट-विशिष्ट संस्करण की तलाश करता है, और यदि यह अस्तित्व में नहीं है, तो इसके बजाय जेनेरिक लोड करें।

function importModule($module, $clientId){ 
    if(is_file("${clientRootDir}/${clientId}/${module}.php")) { 
     import("${clientRootDir}/${clientId}/${module}.php"); 
    } else { 
     import("${defaultRootDir}/${module}.php"); 
    } 
} 

है कि तकनीक का उपयोग करके, आप शान से जिस तरह से वेबसाइट सिर्फ इतना है कि ग्राहक के लिए काम करता है के कुछ हिस्सों के ऊपर लिख सकते हैं, और है कि ग्राहक के लिए है कि कार्यक्षमता पर काम कर व्यक्ति को एक पूरी तरह से अलग फ़ाइल में काम कर रहा है ताकि वे टक्कर नहीं है एक - दूसरे में। मुझे यकीन नहीं है कि आप पहले से ही ऐसा कर रहे हैं और यही वह है जिसे आप अपना "स्थान मॉडल" कहते हैं

अंततः, परीक्षण के लिए कई अलग-अलग "वर्चुअल वेबसाइट" के साथ, आपको स्वचालित इकाई परीक्षण जोड़ने के साथ अत्यधिक लाभ होगा (एक ला PHPUnit) सॉफ़्टवेयर एकीकरण चरण तक अपना रास्ता काम करते समय स्वचालित रूप से परीक्षण बंद करने के लिए निरंतर एकीकरण के साथ संयुक्त।