jQuery को अद्यतित रखने के लिए व्यावहारिक दृष्टिकोण?

Question

जिन परियोजनाओं पर हम काम कर रहे हैं उनमें jQuery की 1.4.2 या इससे पहले की मजबूत जड़ें हैं, और नवीनतम रिलीज के प्रदर्शन किनारे (या वाक्य रचनात्मक चीनी) की कमी के बीच कहीं, अब-बहिष्कृत विधियों का उपयोग करने का अपमान, और सक्रिय रूप से बनाए रखा लाइब्रेरी के 3+ वर्ष पुराने संस्करण को तैनात करने की असुविधा, अब अपग्रेड जल्द ही है।

समुदाय में कुछ प्रथाएं लोकप्रिय हैं कि हम एक चिकनी रोलआउट सुनिश्चित करने के लिए अपनाने/फिर से यात्रा कर सकते हैं (यानी अस्पष्ट संगतता मुद्दों पर ध्यान केंद्रित करना, वैश्विक प्रतिगमन चुनना, पुराने कोड को फिर से फैक्टर करना ...) ? भविष्य के उन्नयन के लिए उन्हें सर्वश्रेष्ठ एसडीएलसी में कैसे एकीकृत किया जाएगा? JQuery जैसी लाइब्रेरी के लिए उचित अपग्रेड शेड्यूल क्या है (मुझे हर बिंदु रिलीज के साथ ऐसा करने के लिए महत्वपूर्ण लाभ या औचित्य लागत की उम्मीद नहीं है, लेकिन एक बार हर 6-12 महीने उचित हो सकता है)?

Answer 1

वास्तव में अपने तीन सवालों के जवाब देने के लिए,

सर्वश्रेष्ठ अभ्यास सहज अपग्रेड रोलआउट

के लिए: यहाँ कुछ चीजें मेरे द्वारा की गई या कम से कम की सिफारिश कर रहे हैं
• परीक्षण है। ये आपके जेएस और/या ब्राउज़र परीक्षणों के लिए यूनिट परीक्षण हो सकते हैं। इन्हें कम से कम सबसे आम और सबसे जटिल कार्यक्षमता को कवर करना चाहिए जो आपकी परियोजनाओं में उपयोग किए जाते हैं। यदि आपके पास परीक्षण नहीं हैं, तो उन्हें लिखें। यदि आप परीक्षण लिखना नहीं चाहते हैं, तो पुनर्विचार करें। यदि आप reeeeally परीक्षण लिखना नहीं चाहते हैं, कम से कम उपयोग मामलों की एक सूची है जो कोई मैन्युअल रूप से निष्पादित करने में सक्षम होगा।
• सुनिश्चित करें कि आपके सभी परीक्षण अपग्रेड से पहले पास हो जाएं।
• के लिए रिलीज नोट्स पढ़ें जो आपके द्वारा अब उपयोग किए जाने वाले संस्करण और सबसे वर्तमान रिलीज़ के बीच प्रत्येक (प्रमुख) संस्करण है। API दस्तावेज़ों में Removed और Deprecated श्रेणियां भी देखें। यदि आपका कोई भी कोड jQuery UI का उपयोग करता है, तो इंटरस्टिशियल संस्करणों के लिए उन रिलीज नोट्स और upgrade guides पर भी देखें। जैसा कि आप करते हैं, उन चीज़ों पर ध्यान दें जिन्हें आपको अपने कोडबेस में बदलना होगा (संभवतः grep का भारी उपयोग करना)।
• यदि आपके प्रोजेक्ट का वर्तमान jQuery संस्करण> = 1.6.4 है, तो आवश्यक कार्य का आकलन करने के लिए jQuery Migrate plugin का उपयोग करने पर भी विचार करें।
• तय करें कि आप कौन से संस्करण को अपग्रेड करना चाहते हैं, वहां पहुंचने के लिए आवश्यक कार्य के आधार पर, क्या आपकी परियोजना किसी तीसरे पक्ष के पुस्तकालयों का उपयोग कर रही है, जिसके लिए jQuery के एक निश्चित संस्करण की आवश्यकता होती है, अन्य कारक केवल आप ही विचार कर सकते हैं आदि।
• अपने कोडबेस में किए गए परिवर्तनों की सूची में जाने के लिए अपनी टीम से मिलें, और उसके अनुसार कार्य को विभाजित/असाइन करें। शायद मदद करने के लिए कुछ स्क्रिप्ट या अन्य टूल्स लिखें। यदि आपके पास कोई है, तो आपकी टीम की कोडिंग शैली मार्गदर्शिका/सर्वोत्तम प्रथाओं के दस्तावेज़ को भी अपडेट करने की आवश्यकता हो सकती है। यदि संभव हो तो वांछित + एक-शॉट (अनुशंसित) या रोलिंग अपडेट रिलीज़ पर निर्णय लें। एक उपयुक्त रिलीज रणनीति के साथ आओ। (मैं आपके कोडबेस में किसी अन्य असंबंधित बड़े परिवर्तन के हिस्से के रूप में अपग्रेड जारी करने के खिलाफ अनुशंसा करता हूं, इसलिए यदि आपको आवश्यकता हो तो वापस रोल करना आसान है।)
• अपग्रेड प्रक्रिया के दौरान, लगातार अपने परीक्षण चलाएं। मैन्युअल रूप से परीक्षण करते समय, हमेशा नई त्रुटियों के लिए ब्राउज़र कंसोल की निगरानी करें। अप्रत्याशित त्रुटियों को कवर करने वाले नए परीक्षण लिखें।
• जब सभी परीक्षण पास होते हैं, तो यह तय करें कि आप कैसे रोल करना चाहते हैं - यदि यह साइट है, तो सभी उपयोगकर्ता एक समय में या एक समय में प्रतिशत आदि। लाइब्रेरी या अन्य प्रोजेक्ट के लिए, शायद आप बीटा जारी करेंगे/खून बहने वाला संस्करण जो आप अपने महत्वाकांक्षी उपयोगकर्ताओं को जंगली में आपके लिए परीक्षण कर सकते हैं।
• दस्तावेज़ जो कुछ भी आपने अभी किया है, अगली बार यह आसान होगा।
• [लाभ।]

सामान्य कार्य-प्रवाह में उन्नयन एकीकृत करने के लिए कैसे

• फिर, परीक्षण। सुनिश्चित करें कि आपके पास है। सुनिश्चित करें कि वे आपके कोडबेस के बड़े हिस्से को अच्छे, बनाए रखे और कवर कर रहे हैं और मामलों का उपयोग करें। इन परीक्षणों को चलाने के स्वचालित करने के लिए निरंतर एकीकरण सेटअप की अत्यधिक अनुशंसा की जाती है।
• अपनी टीम को कोडिंग शैली मार्गदर्शिका या मानक का पालन करने के लिए तैयार करने और सहमत होने पर विचार करें। यह भविष्य में बहिष्कृत फ़ंक्शन कॉल या संरचनाओं की खोज करने में आसान बना देगा, क्योंकि हर कोई समान कोडिंग पैटर्न का पालन करेगा। बुरी कोडिंग शैली को अच्छी या स्नीफ करने के लिए स्क्रिप्ट्स, प्रतिबद्ध हुक, स्थिर विश्लेषण यूटिल इत्यादि जैसे उपकरण उपयोगी हो सकते हैं (टीम के आधार पर)।
• जांचें और हो सकता है कि jQuery संस्करणों और अन्य तृतीय पक्ष पुस्तकालयों का प्रबंधन करने के लिए NPM या bower जैसे पैकेज प्रबंधक का उपयोग करने का निर्णय लें जो आप इसका उपयोग कर सकते हैं। (आपको अभी भी अपने स्वयं के जेएस कोड को बनाए रखने की आवश्यकता होगी और ऊपर की तरह एक ही प्रक्रिया के माध्यम से जाना होगा।)
• फिर, एक बार जब आप पिछले संस्करण 1.6.4 हो, तो सुनिश्चित करें कि माइग्रेट प्लगइन आपके अपग्रेड वर्कफ़्लो का हिस्सा है ।
• आकलन करें कि प्रारंभिक बड़ी अपग्रेड प्रक्रिया से क्या काम किया गया, क्या काम नहीं किया, और इस से एक सामान्य प्रक्रिया निकालें जो आपके वर्तमान वर्कफ़्लो के साथ सबसे अच्छा काम करता है। चाहे आप एक नए संस्करण के हर बार अपग्रेड करने की योजना बना रहे हों या नहीं, वहां रखरखाव कार्य और आदतें चल रही हैं जिन्हें आप शायद सामान्य विकास सर्वोत्तम प्रथाओं के रूप में रखना चाहते हैं।

उचित उन्नयन अनुसूची

अनिवार्य रूप से एक CBA/जोखिम प्रबंधन सवाल है कि।

• वहाँ ही मुख्य संस्करण के भीतर कोई तोड़ने एपीआई परिवर्तन होना चाहिए, ताकि आप आम तौर पर कम से कम प्रयास के साथ हाल ही में मामूली संस्करण में नवीनीकृत करने में सक्षम होना चाहिए, कोई रिफैक्टरिंग: आप कुछ चीजों का वजन करना होगा की आवश्यकता है।यह मानता है कि आपके पास अच्छे परीक्षण हैं, जिन्हें आप अपनी परियोजनाओं पर चला सकते हैं, इससे पहले कि आप यह तय करें कि रोलआउट के लिए पर्याप्त है।
• मेजर संस्करण उन्नयन और अधिक शोध, और अधिक रिफैक्टरिंग, और अधिक परीक्षण की आवश्यकता। शोध चरण के बाद, आपको उन्नयन के लागत-लाभ विश्लेषण करना चाहिए।
• यह हो सकता है नहीं ज्यादा बात है, लेकिन अगर अपनी परियोजनाओं में से किसी एक वेबसाइट कई उपयोगकर्ताओं, क्या होगा आपके सभी उपयोगकर्ताओं के बनाने की लागत अनिवार्य रूप से बदल जे एस फ़ाइलों के सभी अपनी साइट पर अगली बार डाउनलोड करने के लिए किया है वे इसे देखते हैं (पुराने संस्करणों के साथ चिपके रहने की बजाय जो शायद उनके ब्राउज़र में अभी भी कैश किए गए हैं)?
• अपग्रेड करने का निर्णय हमेशा एक व्यक्तिपरक होना चाहिए। मामूली या प्रमुख, आपको अभी भी हर बार औचित्य देना होगा कि क्या कोई अपग्रेड इसके लायक होगा। हमेशा रिलीज नोट्स पढ़ें। क्या यह security vulnerability या उन समस्याओं से संबंधित एक बग को ठीक करता है, जिन्हें आप वर्तमान में अनुभव कर रहे हैं? क्या यह आपके प्रोजेक्ट के प्रदर्शन में काफी सुधार करेगा (बेंचमार्क को बाद में सत्यापित करने के लिए सुनिश्चित करें)? क्या यह आपके द्वारा उपयोग किए जा रहे कोडिंग पैटर्न को बहुत सरल बनाता है, जिससे आपके कोड को अधिक स्वच्छ और आसानी से लिखा जा सकता है? क्या कोई तीसरी पार्टी लाइब्रेरी है जिसका आप उपयोग करना चाहते हैं जो इस नए संस्करण पर निर्भर है? क्या आपके पास पहले से उपयोग किए जाने वाले तीसरे पक्ष के पुस्तकालय हैं जो पुराने संस्करण पर निर्भर हैं? (यदि हां, तो क्या इन पुस्तकालयों को नए संस्करण के साथ काम करने के लिए जल्द ही अपग्रेड किया जा सकता है?) क्या आप अपने परीक्षणों और क्यूए प्रक्रिया में विश्वास रखते हैं कि एक अपग्रेड विकास संसाधनों की उचित मात्रा लेगा और कोई बड़ी प्रतिक्रिया नहीं देगी? क्या आप आखिरकार कुछ और के साथ jQuery को स्विच करने के बारे में सोच रहे थे? आदि

बेशक

यह सिर्फ मेरी सलाह है। इसमें कुछ पुनरावर्ती थीम हैं, और मुझे उम्मीद है कि वे स्पष्ट हैं। किसी भी मामले में, मुझे आशा है कि किसी को यह सहायक लगेगा!

Answer 2

इस में देख लायक है: https://github.com/jquery/jquery-migrate/#readme

इस प्लगइन का पता लगाने और एपीआई बहाल करने के लिए इस्तेमाल किया जा सकता या सुविधाओं कि jQuery में पदावनत किया गया है और संस्करण 1.9 के रूप में हटा दिया। प्लगइन जेनरेट करता है संदेशों के बारे में अधिक जानकारी के लिए warnings page देखें। JQuery 1.9, में किए गए परिवर्तनों के बारे में अधिक जानकारी के लिए upgrade guide और blog post देखें।

Answer 3

आप हमेशा पुराने हो जाएंगे। एक बार जब आप नवीनतम संस्करण में अपडेट कर लेंगे, तो कुछ महीने बाद एक नया आ जाएगा।

जब तक आप उपयोगकर्ता के सामने आने वाली कार्यक्षमता को तोड़ने की संभावना के साथ विकास, परीक्षण और बगफिक्सिंग के घंटे/दिन/सप्ताह नहीं डालना चाहते हैं, तो आपको ईवेंट हैंडलर घोषित करने का नवीनतम तरीका उपयोग करने के लिए अपडेट नहीं किया जाना चाहिए। यह आपको चोट नहीं पहुंचाएगा। और आमतौर पर यह करने के लिए एक जोखिम भरा बात है। यह देव टीम लागत में अनुवाद करता है। आप पहले से ही यह जानते हैं। रिफैक्टरिंग, विशेष रूप से जब परियोजना के लिए कोई स्पष्ट जोखिम नहीं है, तो प्रबंधकों को उचित ठहराना मुश्किल है। और आपको यह सुनिश्चित करने के लिए अपने विचारों को दोबारा जांचना चाहिए कि कोड में नया jQuery जो पहले से काम कर रहा है, कोई फर्क नहीं पड़ता है।

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

तो, बंद करने के लिए, मैं ऐसा कुछ कहूंगा। जब तक कि पुराने jQuery संस्करण की वजह से परियोजना में देरी हो या तकनीकी रूप से अवरुद्ध होने के लिए वास्तविक न्यायसंगत जोखिम न हो, तब तक आप जो कुछ भी पहले से काम कर रहे हैं उसे तोड़ने में परेशानी हो रही है और उसे सबकुछ बनाने के लिए अतिरिक्त घंटे लगाने की आवश्यकता होगी काम के साथ-साथ यह पहले काम कर रहा था।

वैसे भी, इस दृष्टिकोण का यह अर्थ यह नहीं है कि आप पुराने लोगों से 'नए वर्ग' को अलग करना शुरू कर सकते हैं और नए क्षेत्रों में नवीनतम पुस्तकालयों का उपयोग कर सकते हैं।

Answer 4

के लिए अपने विकास के पेड़ में अप टू डेट रखने के लिए, मैं src="http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.js" (जो आसान डिबगिंग के लिए अनुमति देता है पूर्ण गैर न्यूनतम किया संस्करण)

का उपयोग करना चाहिये फिर जब आप प्रकाशित करने के लिए जाना है, बस इसे विशिष्ट के साथ बदलें हेडर टिप्पणी में मौजूद न्यूनतम संस्करण (वर्तमान में http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js) इसमें बेहतर क्लाइंट साइड कैशिंग और किसी और की बैंडविड्थ का उपयोग करने का बोनस है।

यदि कैशिंग को यह सुनिश्चित करने से कोई चिंता नहीं है कि यह स्वचालित रूप से उस मामूली संस्करण रिलीज के लिए बगफिक्स प्राप्त करेगा, तो आप केवल http://ajax.googleapis.com/ajax/libs/jquery/1.9/jquery.min.js (नोट: Google के पास अभी तक 1.9 श्रृंखला नहीं है) अप; हालांकि 1.8 श्रृंखला 1.8.3 तक है) चूंकि ये समय-समय पर बग फिक्स रिलीज़ के लिए अपडेट हो जाते हैं, इसलिए उन्हें संस्करण विशिष्ट रिलीज जैसे कैश नहीं मिलते हैं

Answer 5

इस युग में हम किसी की स्थिरता के बारे में अनुमानित नहीं हो सकते सॉफ्टवेयर संस्करण। कुछ साल या दो साल बाद सॉफ्टवेयर और सेवाओं के संस्करण जारी होने से पहले कुछ साल पहले। लेकिन इस समय सेवाओं के संस्करण तेजी से और अक्सर अद्यतन कर रहे हैं।

तो यदि आप अपनी सेवा के साथ किसी भी सेवा का उपयोग कर रहे हैं तो आपको Agile Development का उपयोग करना होगा। इस विकास विधि से आप आसानी से नई आवश्यकताओं में बदलाव कर सकते हैं और आपके अनुसार आवश्यक विधियों को बदल सकते हैं।

और कृपया अवमूल्यन विधियों का उपयोग न करें क्योंकि वे लंबे समय तक सेवा संस्करणों के लिए उपयुक्त नहीं हैं। और अपने स्वयं के सेवा फ़ंक्शन की लाइब्रेरी की उपयोग की जाने वाली सेवाओं के पुस्तकालय बनाएं जो अन्य सेवाओं का उपयोग कर रहे हैं ताकि आप उन्हें अपने नए संस्करण के अनुसार आसानी से बदल सकें।

उदाहरण के लिए: है जैसे आप एक विधि नाम update_var(); है, जैसे कोई $a = newlib::check_update(); जैसे अन्य सेवा का एक और तरीका बुला। फिर पुस्तकालयों को बनाकर आपको अपनी सेवा की मुख्य लाइब्रेरी और शामिल सेवा की कोर लाइब्रेरी को बदलना होगा

Answer 6

ट्विटर लोगों ने इस समस्या को काफी अच्छी तरह से हल किया है।

http://github.com/twitter/bower

यह क्या यह टिन पर कहते है - यह वेब के लिए एक पैकेज प्रबंधक है (और है कि तारीख तक JQuery की तरह रखने जे एस फ़ाइलें शामिल)