आम जावा वेब विकास प्रथाओं क्या हैं?

Question

मैं विकास समूहों के सामान्य जावा वेब विकास प्रथाओं के बारे में अधिक/बेहतर समझना चाहता हूं जिनमें कम से कम दो टीम - वेब डिज़ाइनर और वेब घटक डेवलपर हैं। विशेष रूप से, मैं की तरह समझ चीजों में दिलचस्पी रहा हूँ:

1. मान लिया जाये कि एक कोड भंडार है, सभी टीमों सभी कोड की एक स्थानीय प्रति चेकआउट करते हैं? यदि हां, तो एक वेब डिज़ाइनर बैक-एंड कोड तक पहुंच/आवश्यकता क्यों लेगा, इसी तरह एक वेब घटक डेवलपर क्यों चाहते हैं/फ्रंट-एंड कोड तक पहुंच की आवश्यकता होगी?

2. टीम के बावजूद प्रत्येक टीम सदस्य, उनके कोड का परीक्षण कैसे करता है - क्या वे कोड को अपने स्थानीय वर्कस्टेशन, एक विकास बॉक्स पर एक व्यक्तिगत उदाहरण, या एक समेकित देव बॉक्स में कोड तैनात करते हैं?

3. एकीकरण और परीक्षण कैसे किया जाता है? उदाहरण के लिए, मान लीजिए कि एक वेब डिज़ाइनर 'साइन-अप' फॉर्म पेज बनाता है और वेब घटक डेवलपर डेटा को डीबी में संसाधित करने और डालने के लिए बैक-एंड कोड बनाता है - फ्रंट एंड एंड बैक एंड कोड कैसे एकीकृत किया जाएगा और परीक्षण किया?

कोई अतिरिक्त जानकारी है कि विकास समूहों के जावा वेब विकास प्रथाओं है कि मैं विशेष रूप से के बारे में पूछताछ नहीं की है से संबंधित है, लेकिन प्रासंगिक है, शेयर कृपया।

संपादित करें (फ़ॉलो-अप): मैं वे वैचारिक छेद मैं जावा वेब विकास के बारे में था के अधिकांश में भर दिया जवाब की सराहना करते हैं,। हालांकि, मेरे पास कुछ अनुवर्ती प्रश्न हैं -

1. परीक्षण, विशेष रूप से स्वचालित परीक्षण जावा वेब विकास के स्पष्ट रूप से महत्वपूर्ण भाग हैं; लेकिन क्या एक अच्छा "परीक्षण" का गठन करता है? उदाहरण के लिए, मान लें कि जावा बैक-एंड डेवलपर बस एक साथ कोड डालता है जो फॉर्म डेटा स्वीकार करता है, इसे मान्य करता है, और फिर डेटाबेस में/सम्मिलित करता है। इस परिदृश्य में एक अच्छा परीक्षण क्या होगा? इसके अलावा, यह "स्वचालित" कैसे हो सकता है?

2. क्या कोई निरंतरता एकीकरण पर विस्तार कर सकता है - यानी उनका उद्देश्य केवल सभी प्रोजेक्ट कोड को संकलित करना है? या यह स्वचालित परीक्षण में मदद करने के लिए है? जो मैं समझता हूं, निरंतरता एकीकृत सर्वर सर्वर के लिए रिपॉजिटरीज़ की निगरानी करता है, और नए संशोधित कोड चेकआउट करता है और संपूर्ण प्रोजेक्ट संकलित करता है; सफल/असफल संकलन पर उपयोगकर्ता को सूचित किया जाता है।

Answer 1

1. हम हमेशा सभी sourcecode हम पर हमारे हाथ प्राप्त कर सकते हैं की जाँच करें। बाहरी पुस्तकालयों, बैकएंड सिस्टम और कार्यों के लिए स्रोत कोड। बैकएंड सिस्टम के कोड को पढ़ना आगे बढ़ने वाले डेवलपर्स के लिए यह समझना आसान बनाता है कि क्या हो रहा है। बैकएंड डेवलपर्स कभी-कभी यह देखने के लिए फ्रंटएंड कोड पढ़ते हैं कि वास्तव में चीजों का उपयोग कैसे किया जा रहा है। अधिक कोड अच्छी बात है। मेवेन भी सोर्स कोड के ऑटो-डाउनलोडिंग का समर्थन करता है, जो कि बहुत अच्छा है।

2. हम मेवेन का उपयोग करते हैं, और मैं वास्तव में इसे एक टीम के माहौल में अनुशंसा करता हूं। हम टीम केंद्रीकृत परीक्षण सर्वर और आम स्वीकृति वातावरण पर स्थानीय रूप से तैनात हैं। "घर" के नजदीक आप चीजों का परीक्षण कर सकते हैं, सस्ता और अधिक कुशल।

3. हम कई परीक्षणों के लिए सेलेनियम का उपयोग करते हैं जो उचित रूप से तैनात वेबपैप के "सामने के माध्यम से" परीक्षण करने के लिए उपयोग की अनुमति देता है।इसके अलावा, अधिकांश एकीकरण परीक्षण जो स्टैक के कुछ हिस्सों को चलाते हैं, वे एक मैवेन प्रोफाइल के भीतर नियमित जूनिट परीक्षण के रूप में चलते हैं।

Answer 2

हम अपनी टीम पर कर कैसे:

1. हां। प्रत्येक सदस्य सभी कोडों की जांच करता है भले ही आप सभी भागों में काम नहीं कर रहे हों। जब आप अपने द्वारा किए गए परिवर्तनों को तुरंत देखने के लिए काम करते हैं तो आपको अपनी स्थानीय मशीन पर एप्लिकेशन चलाने की आवश्यकता होती है। फ्रंट एंड प्रभावों को देखने के लिए सामने वाले लोगों को बैकएंड कोड चलाने की आवश्यकता है।

2. कोडिंग के दौरान प्रत्येक सदस्य कोड को अपनी मशीन पर चलाता है। जब इसे चेक किया जाता है तो इसे विशेष रूप से निर्दिष्ट सर्वर पर पूरी तरह से परीक्षण किया जाता है।

3. परीक्षण जितना संभव हो स्वचालित स्वचालित होना चाहिए। प्रत्येक टीम सदस्य कोड के अपने हिस्से के लिए टेस्ट कोड लिखता है और इसमें भी चेक किया जाता है। आप स्वचालित रूप से उन परीक्षणों को चलाने के लिए निरंतर एकीकरण सर्वर का उपयोग कर सकते हैं। लेकिन प्रारंभिक परीक्षण वास्तव में स्थानीय मशीन पर किया जाता है। अगर मैं कोड देखता हूं, तो बैकएंड क्लास में बदलाव करें, मैं कोड चलाउंगा और यह सुनिश्चित करूँगा कि यह मेरी मशीन पर काम करता है, अपडेट करें जो भी परीक्षणों को अद्यतन करने और मेरे परिवर्तन करने की आवश्यकता है अपडेट करें। यह सुनिश्चित करने के लिए स्वचालित परीक्षण सर्वर पर चलते हैं कि विभिन्न काम एक साथ अच्छी तरह से काम करते हैं।

मैं यह नहीं कह सकता कि यह सबसे अच्छा अभ्यास है, लेकिन यह केवल 4 देवताओं की हमारी छोटी टीम के लिए व्यावहारिक अभ्यास है।

Answer 3

हमारी टीम में ...

1. यह नया developpments के लिए भंडार में एक नया branche बनाने आमतौर पर, और फिर उन्हें ट्रंक में मर्ज करने के लिए हमारे व्यवहार टैग किए जाने, जब तैयार तैनात किया जाना उत्पादन में। इसलिए हम उन सभी शाखाओं की जांच करते हैं जिन पर हम काम कर रहे हैं। साथ ही, एसवीएन का उपयोग करके, एकाधिक कोडर एक ही फाइल पर काम कर सकते हैं क्योंकि एसवीएन फ़ाइल को लॉक नहीं करता है और आपको बाद में मर्ज करने देता है, लेकिन यह एक दुर्लभ मामला है। ऑटो-मर्ज हमेशा काम नहीं करेगा और आपको कुछ "मैन्युअल विलय" करना होगा।

2. पहले परीक्षण स्थानीय होते हैं, फिर विकास केंद्र में तैनात किए जाते हैं, फिर स्वीकृति पर्यावरण। DEV और स्वीकृति वातावरण में परीक्षण किया गया कोड लंटबिल्ड/एएनटी द्वारा बनाया गया है और हमारे अनुप्रयोग सर्वर में ज्योथन स्क्रिप्ट के माध्यम से डील किया गया है। हम स्थानीय पर्यावरण के बाहर मैन्युअल रूप से तैनात या निर्माण नहीं करते हैं। जब संभव हो, हम उन तैनाती का परीक्षण करने के लिए टीम के अन्य लोगों से पूछते हैं।

3. कैक्टस एपीआई आपको servlets/struts/web app के लिए junit परीक्षण "वार अप" करने देता है। हम कुछ अन्य परीक्षणों के लिए जेएमटर और सेलेनियम (अच्छी फ़ायरफ़ॉक्स प्लगइन) के साथ कुछ तनाव परीक्षण करते हैं। आप कवरेज टूल्स (जैसे ईएमएमए) भी चला सकते हैं जो आपको बताएगा कि आपके जुइनिट/कैक्टस परीक्षणों द्वारा कोड का प्रतिशत किस प्रकार कवर किया गया है।

Answer 4

पहला सवाल के लिए, आप आम तौर पर के रूप में ग्रहण स्वचालित रूप से src.zip फ़ाइल देता है (यह भी मतलब है कि आप का उपयोग JDK के विकास के लिए प्रत्येक के लिए स्रोत कोड और एक स्टैक ट्रेस में हर पंक्ति को देखने के लिए सक्षम होना चाहिए रनटाइम पुस्तकालयों के लिए) भले ही यह आपके विशेषज्ञता के क्षेत्र से बाहर हो।

तो, आप जो भी कर सकते हैं उसे देखें। यह आपको कुछ दिन मदद करेगा - कोडर भी बेहतर कोड लिखते हैं और इसे बेहतर तरीके से दस्तावेज करते हैं यदि उन्हें पता है कि पूरी टीम हमेशा इसे देखेगी।

विकास और तैनाती के लिए।आप जो भी करना चाहते हैं वह कर सकते हैं जो आप अपने कोड को विकसित और परीक्षण करने में सक्षम होना चाहते हैं, लेकिन उत्पादन में या टीम के बाहर जाने वाले किसी भी कोड को मशीन द्वारा बनाया गया है (यह पुनरुत्पादन सुनिश्चित करता है)। हम इसके लिए हडसन का उपयोग करते हैं, लेकिन यह सिर्फ एक दुर्घटना है। एटलसियन बांस के लिए नवीनतम स्टार्टर टीम लाइसेंस का मतलब यह हो सकता है कि हम इसका भी उपयोग करते हैं।

Answer 5

1. यह आपकी परियोजना संरचना पर निर्भर करता है। आम तौर पर जावा वेबपैप परियोजनाएं मेवेन प्रोजेक्ट सम्मेलन का पालन करती हैं। यदि आपके पास वेब और बैकएंड कार्यक्षमताओं के लिए एक प्रोजेक्ट है, तो सभी टीम मेम्बरर्स को चेकआउट स्रोतों की आवश्यकता होती है, अगर संरचना वेब और बैकएंड प्रोजेक्ट में विभाजित होती है तो प्रत्येक टीम केवल उनकी परियोजनाओं को चेकआउट कर सकती है।
   • Simple webapp maven project structure
   • Multi module maven project structure
2. आप Maven का उपयोग करते हैं यह आवेदन को तैनात करने के लिए स्वाभाविक रूप से आता है। अत्यधिक अनुशंसित सीआई (निरंतर एकीकरण) सर्वर का उपयोग करना है जैसे Hudson। एंटोहर बहुत महत्वपूर्ण पहलू है प्लगइन (मेवेन या हडसन एक) के उचित सेट का उपयोग करना, जैसे सेलेनियम परीक्षण या अन्य वेब टेस्ट फ्रेमवर्क।
3. प्लगइन की थोड़ी मदद के साथ मैवेन/हडसन द्वारा एकीकरण परीक्षण किया जाता है :)। मैंने Selenium का उल्लेख किया है, जो Canoo WebTest हो सकता है या कभी-कभी फ्रेमवर्क या तकनीक के लिए उपयुक्त अन्य परीक्षण फ्रेमवर्क जो आप विकास के लिए चुनते हैं।

मेवेन मार्ग का पालन करने के लिए समेकित करें।

Answer 6

मान लीजिए कि एक कोड भंडार है, क्या सभी टीमें सभी कोड की स्थानीय प्रतिलिपि जांचती हैं? यदि हां, तो एक वेब डिज़ाइनर बैक-एंड कोड तक पहुंच/आवश्यकता क्यों लेगा, इसी तरह एक वेब घटक डेवलपर क्यों चाहते हैं/फ्रंट-एंड कोड तक पहुंच की आवश्यकता होगी?

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

टीम के बावजूद प्रत्येक टीम सदस्य, उनके कोड का परीक्षण कैसे करता है - क्या वे कोड को अपने स्थानीय वर्कस्टेशन, एक विकास बॉक्स पर एक व्यक्तिगत उदाहरण, या एक समेकित देव बॉक्स में कोड तैनात करते हैं?

वेब सेवर्स, एप्लिकेशन सर्वर, डेटाबेस उदाहरण के लिए प्रति डेवलपर समर्पित वातावरण का उपयोग करें (Use one database instance per developer देखें)। जब भी वे दूसरों को परेशान किए बिना चाहते हैं, तब भी टीम के सदस्यों को फिर से शुरू करने, पुनर्निर्माण करने में सक्षम होना चाहिए (भले ही मैं विकास के दौरान "कंटेनर में बिताए गए समय को कम करने का समर्थन करता हूं, यानी अलगाव में इकाई परीक्षणों को प्राथमिकता देना)। इस प्रकार, उन सभी चीज़ों के लिए स्थानीय वर्कस्टेशन को प्राथमिकता दें जिन्हें पुनरारंभ करने की आवश्यकता हो सकती है: वेब सर्वर, एप्लिकेशन सर्वर, आदि। स्थानीय परिनियोजन भी अक्सर आसान होता है। डेटाबेस के लिए, एक दूरस्थ डेटाबेस उदाहरण सामान्य रूप से ठीक है (और बेहतर हो सकता है जैसे कि आपके पास एक बड़ा ऑरैकल सर्वर है)। निरंतर एकीकरण प्रक्रिया के लिए एक समेकित देव बॉक्स का उपयोग करें।

एकीकरण और परीक्षण कैसे किया जाता है? उदाहरण के लिए, मान लीजिए कि एक वेब डिज़ाइनर 'साइन-अप' फॉर्म पेज बनाता है और वेब घटक डेवलपर डेटा को डीबी में संसाधित करने और डालने के लिए बैक-एंड कोड बनाता है - फ्रंट एंड एंड बैक एंड कोड कैसे एकीकृत किया जाएगा और परीक्षण किया?

पहले उन्हें अलग से परीक्षण करें। यदि आवश्यक हो तो बैक-एंड मॉक करें। फिर पूरे परीक्षण करें। डेटाबेस के साथ बातचीत करने वाले एकीकरण या कार्यात्मक परीक्षण करते समय, एक अच्छी प्रैक्टिस हमेशा परीक्षण चलाने के लिए डेटाबेस को किसी ज्ञात स्थिति में रखना है (Good setup don't need cleanup! देखें)। DBUnit ऐसा करने में मदद कर सकते हैं। Cactus सर्वर साइड परीक्षण के लिए एक और अच्छा उपकरण है, उदा। एकीकरण जांच। कार्यात्मक परीक्षण चलाने के लिए उर्फ ​​एंड-टू-एंड परीक्षण, Selenium या WebDriver अच्छे उम्मीदवार हैं। स्वीकृति परीक्षण (या बीबीडी) के लिए, मैं वर्तमान में Cucumber की जांच कर रहा हूं और मुझे यह पसंद है।