ग्लिची अपडेट एक गहरी समस्या का संकेत देते हैं


टोक्यो प्रस्तुति जुलाई 2015 में विंडोज 10

जाहिर है, 10 अक्टूबर, 2018 का विंडोज अपडेट सबसे सफल नहीं रहा। कंप्यूटर पर फ़ाइलों के नुकसान के बारे में संदेश जल्दी से दिखाई दिए, और Microsoft ने अपडेट को वितरित करना बंद कर दिया। तब से, बग को ठीक कर दिया गया है , अब इसके फिर से रिलीज़ होने से पहले एक नए अपडेट का परीक्षण किया जा रहा है।

समस्याओं के लिए यह पहला विंडोज अपडेट नहीं है - पिछले अपडेट में हमने महत्वपूर्ण हार्डवेयर असंगति जैसी चीजों को देखा - लेकिन यह स्पष्ट रूप से बदतर हो गया है। हम में से अधिकांश लोग बैकअप के बारे में जानते हैं, लेकिन वास्तव में, कई डेटा, विशेष रूप से होम कंप्यूटर पर, बैकअप नहीं है, और उनका गायब होना बहुत अप्रिय है।

एक सेवा के रूप में विंडोज

विंडोज 10 में, विकास की प्रक्रिया को मौलिक रूप से बदलने की योजना बनाई गई थी। Microsoft ग्राहकों और बाजार की जरूरतों पर बेहतर प्रतिक्रिया देना चाहता था - और अधिक बार नई सुविधाएँ जारी करता है। विंडोज 10 को विंडोज के "नवीनतम" संस्करण के रूप में प्रस्तुत किया गया था। जैसे, सभी नए विकास विंडोज 10 के अपडेट बन जाएंगे, अपडेट सिस्टम के माध्यम से वर्ष में कई बार वितरित किए जाएंगे। इस नए विकास मॉडल को सेवा के रूप में विंडोज कहा जाता है। और कुछ प्रारंभिक गड़बड़ी के बाद, Microsoft प्रति वर्ष दो कार्यात्मक अपडेट पर बस गया : अप्रैल में और अक्टूबर में।

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


उन दिनों में जब हर तीन साल में विंडोज को केवल अपडेट किया जाता था, यह कल्पना करना कठिन था कि डब्ल्यूएसएल कभी एक उपयोगी उपकरण बन जाएगा।

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

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

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

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

यह आवृत्ति की बात नहीं है, लेकिन HOW के अपडेट कैसे तैयार किए जा रहे हैं

लेकिन जो लोग दो के बजाय प्रति वर्ष एक अद्यतन पर जोर देते हैं वे इस बिंदु को याद करते हैं। समस्या आउटपुट आवृत्ति नहीं है। समस्या Microsoft विकास प्रक्रिया में है।

समस्या शब्दों में क्यों नहीं है? हम अन्य OS के अपडेट शेड्यूल को देख सकते हैं।

एक ओर, macOS, iOS, और Android को कम बार अद्यतन किया जाता है, इसलिए आपको यह आभास हो सकता है कि Microsoft बहुत अधिक उत्साही है। दूसरी ओर, ऐसी आवृत्ति पर सफल अपडेट के लिए मिसालें हैं: उबंटू के लिए, प्रति वर्ष दो रिलीज़ होती हैं, और Google से ChromeOS, अपने क्रोम ब्राउज़र की तरह, हर छह सप्ताह में अपडेट प्राप्त करता है। यदि आप ओएस से परे जाते हैं, तो माइक्रोसॉफ्ट ऑफिस इनसाइडर प्रोग्राम एक मासिक चैनल चलाता है, जहां हर महीने कार्यालय उपयोगकर्ताओं के लिए नई सुविधाएँ जारी की जाती हैं - और डेवलपर्स बहुत अधिक शिकायतों के बिना काम करते हैं और एक ही समय में नई सुविधाओं और सुधारों की एक स्थिर धारा प्रदान करते हैं। विजुअल स्टूडियो टीम अक्सर अपने विकास के माहौल और इंटरैक्टिव सेवाओं के लिए अपडेट भी जारी करती है। जाहिर है, माइक्रोसॉफ्ट के पास ऐसी टीमें हैं जो वास्तविकता के लिए अच्छी तरह से अनुकूलित हैं, जहां उनके एप्लिकेशन नियमित रूप से अपडेट होते हैं।

हम स्थानीय सॉफ्टवेयर के दायरे से परे जाकर नेटवर्क और क्लाउड सेवाओं को देखेंगे। वहां, Microsoft और अन्य कंपनियां लगातार वितरण शुरू कर रही हैं। सिस्टम में प्रत्येक अपडेट स्वचालित रूप से पर्याप्त परीक्षणों को पारित करने के बाद उत्पादन सर्वर पर स्वचालित रूप से तैनात किया जाता है।

बेशक, इन परियोजनाओं में से किसी की भी विंडोज के साथ जटिलता में तुलना नहीं की जा सकती है। उबंटू में अधिक विविध प्रकार के पैकेज हो सकते हैं, लेकिन किसी भी मामले में, उनमें से कई स्वतंत्र रूप से विकसित होते हैं। तथ्य यह है: विंडोज का पैमाना असामान्य रूप से बड़ा है - और घटक अभूतपूर्व रूप से एक ही कोड बेस में एकीकृत होते हैं। कुछ स्थानों पर, विंडोज कोड असाधारण रूप से पुराना है।

बेशक, ये कारक विंडोज के विकास को जटिल करते हैं, लेकिन क्या एक वर्ष में दो अपडेट को रोकना वास्तव में असंभव है? यह बिल्कुल भी बात नहीं है। आपको सिर्फ सही विकास प्रक्रिया की जरूरत है।


2015 में रिलीज के समय के आसपास विंडोज 10 (मेरे सभी आइकन और स्टार्ट मेनू कहां हैं?)

एक प्रक्रिया इतिहास में निहित है

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



पुराने दिनों में, जब दो और तीन साल बड़ी रिलीज के बीच बीत गए, तो Microsoft कई चरणों में विभाजित प्रक्रिया में आया:

1. डिजाइन और योजना;
2. घटक विकास;
3. एकीकरण;
4. स्थिरीकरण।

लगभग 4-6 महीने की योजना और डिजाइन, 6-8 सप्ताह का गहन कोडिंग, और फिर 4 महीने का एकीकरण (प्रत्येक फ़ंक्शन आमतौर पर अपनी शाखा में विकसित होता है, इसलिए उन्हें सभी को एक साथ इकट्ठा करने और संयोजित करने की आवश्यकता होती है) और स्थिरीकरण (त्रुटियों का परीक्षण और सुधार)। उत्पाद विकास के दौरान, यह चक्र दो या तीन बार दोहराया जाता है; विंडोज में तीन पुनरावृत्तियों होंगे, जिनमें से पहला एक प्रोटोटाइप है, और अगले दो वास्तविक हैं। चरणों की अवधि भिन्न हो सकती है, लेकिन कंपनी में मूल संरचना का व्यापक रूप से उपयोग किया जाता है।

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

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


नडेला ने 2015 में दुनिया को विंडोज 10 से परिचित कराया

नई दुनिया इतनी नई नहीं है

नई दुनिया में, हम देखते हैं कि एक पूर्ण कंपनी चक्र के लिए सात या आठ महीने लगते हैं। हालाँकि रिलीज़ के बीच केवल छह महीने हैं, अगले चक्र की शुरुआत पिछले एक के पूरा होने से पहले होती है - अंदरूनी सूत्रों के लिए यह स्किप अहेड समूह के उद्घाटन से स्पष्ट है।

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

जैसा कि स्वयं Microsoft कर्मचारी वर्णन करते हैं, पिछले कुछ महीनों के विकास में "बताओ" चरण शामिल है, तो "अनुमति प्राप्त करें" चरण के एक महीने। "सूचना" चरण में, विंडोज प्रबंधन को डिफ़ॉल्ट रूप से इन परिवर्तनों को स्वीकार करने की नीति के साथ किए गए परिवर्तनों से अवगत कराया जाता है। "अनुमति के लिए पूछें" चरण में, केवल वास्तव में महत्वपूर्ण परिवर्तन की अनुमति है, एक नियम के रूप में, प्रति दिन केवल कुछ परिवर्तन।

उदाहरण के लिए, अक्टूबर अपडेट का पहला बिल्ड (कोडनेम RS5) 14 फरवरी को अंदरूनी सूत्रों के लिए जारी किया गया था, और अप्रैल अपडेट (RS4) का स्थिर निर्माण दो महीने बाद 16 अप्रैल को हुआ था। RS5 को 7 मार्च तक कोई महत्वपूर्ण नई सुविधाएँ नहीं मिलीं। मई, जून और जुलाई के दौरान कई सुविधाएँ जोड़ी गईं, और फिर अगस्त और सितंबर में केवल छोटे बदलाव किए गए। अगस्त में कई छोटी विशेषताओं को भी हटा दिया गया था, क्योंकि अक्टूबर में उनकी रिलीज़ के लिए तैयार करना मुश्किल था।

बेशक, प्रक्रिया थोड़ी बदल गई है। उदाहरण के लिए, कई महीनों के दौरान पूर्व-बिल्ड में नई सुविधाएँ दिखाई देती हैं। यह इंगित करता है कि नए कार्यों का एकीकरण बहुत पहले होने लगता है - क्योंकि फ़ंक्शन विकसित होते हैं, और अंत में एक बड़े मर्ज पैकेज में नहीं।

गुणवत्ता में गिरावट

लेकिन प्रमुख समानताएं हैं। सबसे महत्वपूर्ण बात, एक जानबूझकर छोटी गाड़ी का कोड एक आम डेटाबेस में एकीकृत है, और किसी भी समस्या को हल करने के लिए परीक्षण और स्थिरीकरण चरण का उपयोग किया जाता है। इस क्षण को भी स्पष्ट रूप से मान्यता प्राप्त है: एक नई प्रारंभिक विधानसभा की घोषणा करते हुए, Microsoft चेतावनी देता है: "विकास चक्र की शुरुआत में हमेशा की तरह, विधानसभाओं में ऐसे कीड़े हो सकते हैं जो दर्दनाक हो सकते हैं। यदि इससे आपको कोई असुविधा होती है, तो आप धीमे अपडेट साइकिल (स्लो रिंग) पर स्विच करने पर विचार कर सकते हैं। वहां, विधानसभाएं अभी भी उच्च गुणवत्ता की होंगी। ”

हम इसे आरएस 5 में अभ्यास में देखते हैं। पिछले साल अक्टूबर में, अपडेट के साथ, उन्होंने वनड्राइव: प्लेसहोल्डर्स के लिए एक नई सुविधा शुरू की, जो स्थानीय रूप से डाउनलोड नहीं होने वाले क्लाउड में फाइलें प्रदर्शित करते हैं। जब भी कोई एप्लिकेशन फ़ाइल खोलने का प्रयास करता है, OneDrive पारदर्शी रूप से क्लाउड स्टोरेज से फ़ाइल को निकालता है और इसे स्थानीय रूप से बचाता है, और एप्लिकेशन को यह भी नहीं पता है कि फ़ाइल शुरू में स्थानीय रूप से सुलभ नहीं थी। RS5 बिल्ड डिस्क स्थान से बाहर निकलता है, तो स्थानीय संग्रहण से प्रतिकृति क्लाउड फ़ाइलों की सफाई के कार्य को कार्यान्वित करता है।

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


विंडोज प्री-बिल्ड ब्लू के बजाय ग्रीन "डेथ स्क्रीन" का उपयोग करते हैं, इसलिए उन्हें भेद करना आसान है

यह मानना ​​उचित है कि Microsoft इस नए कोड के लिए कई परीक्षण करेगा: एक फ़ाइल बनाना, सिंक्रोनाइज़ेशन की जाँच करना, आइकन को बचाने के साथ एक स्थानीय प्रतिलिपि को हटाना, वास्तविक फ़ाइल के डाउनलोड के साथ आइकन को खोलना, फ़ाइल को पूरी तरह से हटाना, और इसी तरह आगे। फ़ाइलों और निर्देशिकाओं में हेरफेर के लिए कई बुनियादी संचालन हैं, और किसी भी लचीली विकास प्रक्रिया में, यह सत्यापित करने के लिए परीक्षण हैं कि सभी ऑपरेशन अपेक्षित रूप से काम करते हैं, और एपीआई वह करता है जो उसे करना चाहिए।

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

फिर भी, कई प्रारंभिक बिल्ड में एक बग था: OneDrive के साथ सिंक्रनाइज़ की गई निर्देशिका को हटाने पर सिस्टम लटका हुआ था। यह बग न केवल विंडोज कोड में एकीकृत किया गया था, बल्कि अंतिम उपयोगकर्ताओं के लिए भी जारी किया गया था।

रिलीज से पहले टेस्ट सॉफ्टवेयर, उसके बाद नहीं

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

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

नतीजतन, विंडोज 10 का विकास अभी भी पुराने सिद्धांतों का पालन कर रहा है। स्थिरता और विश्वसनीयता में गिरावट के साथ नई सुविधाओं को डेटाबेस में डाला जाता है। यह माना जाता है कि परीक्षण और स्थिरीकरण चरण में कोड आधार को स्वीकार्य स्तर पर लाया जाएगा।

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

लेकिन दूसरे मामलों में, Microsoft ऐसा कार्य करता है जैसे कि उसकी निश्चितता हो। कंपनी के कई परीक्षण हैं; मुझे बताया गया था कि विंडोज के लिए एक पूर्ण परीक्षण चक्र में कई सप्ताह लगते हैं। यह पूरा चक्र वास्तव में चलाया जाता है, केवल उन विधानसभाओं पर नहीं जो वास्तव में उत्पादन में जाती हैं। एक उदाहरण अक्टूबर 2018 का अपडेट है: कोड 15 सितंबर को इकट्ठा किया गया था, और 2 अक्टूबर को विधानसभा सार्वजनिक हो गई थी। इसके बावजूद कि RS5 बिल्ड पूर्ण परीक्षण चक्र से गुजरा है, यह वह नहीं है जिसे हमने वास्तव में प्राप्त किया है, क्योंकि एक पूर्ण परीक्षण चक्र में बहुत अधिक समय लगता है।

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


विंडोज 10 वास्तव में एक विश्वसनीय मशीन की तरह काम कर सकता है

इसे सही कैसे किया जाए

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

बेशक, विंडोज के साथ इसकी तुलना करना थोड़ा अनुचित है: आखिरकार, क्लाउड सेवाओं के लिए किसी त्रुटि का पता चलने पर परिवर्तन को वापस करना बहुत आसान है। सिस्टम स्टार्टअप पर नीली स्क्रीन के साथ विंडोज को संशोधित करना पूर्ववत और पुनर्स्थापित करने के लिए बहुत अधिक कठिन है। — Google, , , . , .

. , . Microsoft — « , », , .


Chrome , , —

, Agile . , Google Chrome. - Chrome , . , Chrome , . dev- Chrome — , , . : Chrome , , Windows.

Google . , Chrome , . , . Google , . , Google Chrome , .

Windows

Microsoft — . , , . Windows 10 , Microsoft , .

. , Windows . Windows 7 , . Windows, Service Pack 1. ? — , Service Pack 1 .

, Windows , , . बिलकुल नहीं। , , « Service Pack 1» . , Microsoft , — - . «» Service Pack 1.

, : Windows , . — , . , Service Pack .

— . . , Windows , , .

— . Microsoft , . 2014 . , , . Windows Insider — (). , - Windows.

, . , , . , Microsoft . . , , , , . , , .

Microsoft , . , , : .

. Insider — . , . . , Microsoft .

, , . . , : . .

Chrome Windows — . Windows , . , OneDrive, . .

, Windows — « », « , ». . Microsoft , . , — . . , . , .