🛑 🕍 🏎️ प्रोग्रामर, टीम, टीम की प्रभावशीलता के लिए संघर्ष में डेवलपर्स 📘 💀 👲🏻

सभी को नमस्कार।

आज हम प्रभावी काम के एक बहुत महत्वपूर्ण पहलू पर चर्चा करना चाहते हैं - पुन: उपयोग।

यह निश्चित रूप से, कोड के बारे में होगा।

एक दिनचर्या जिसे मैं दो बार लिखना नहीं चाहता, और इससे भी अधिक तीन बार। इंफ्रास्ट्रक्चर, जिसे प्रोजेक्ट से प्रोजेक्ट में लिखना होता है। शानदार, जो केवल एक महान विचार व्यक्त करता है और जो दूसरों को इसका उपयोग नहीं करने देना पाप है।

हाँ, और मान लेते हैं - हम सभी को "फ्रेमवर्क" लिखना पसंद है, जिसे हम बाद में उपयोग करते हैं और अन्य उपयोग करते हैं। इससे हमारी दैनिक गतिविधियों में थोड़ा साहस आता है।

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

और हमने इसके बारे में कुछ करने का फैसला किया।

हमने जो रास्ता तय किया वह इतना कठिन नहीं था, हम आपको दूसरों के लिए इसे दोहराने की सलाह दे सकते हैं, क्योंकि समय खुद के लिए भुगतान करता है। और कुछ समय के बाद यह रास्ता दिलचस्प और मज़ेदार हो गया, हमने अपना अनुभव साझा करने का फैसला किया।

खैर, पर्याप्त प्रस्तावना।

तो, आज हम आपको विस्तार से बताएंगे:

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

हम कॉर्पोरेट नगेट सर्वर को तैनात करते हैं।

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

अगर हम कॉर्पोरेट सर्वर को तैनात करने की बात कर रहे हैं, तो दो इंस्टॉलेशन विकल्प हैं:

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

दरअसल, यह सब - प्रक्रिया बेहद सरल है। हालाँकि, ऐसे कई बिंदु हैं जो हमारे साथ प्रकट हुए दस्तावेज में वर्णित नहीं हैं और जो दूसरों के लिए उपयोगी हो सकते हैं:

1. आईआईएस एक्सप्रेस । लोकलडब का उपयोग करके आईआईएस एक्सप्रेस पर काम करने का विकल्प कई कारणों से तैयार उत्पादन के रूप में विचार करना मुश्किल है। इसलिए, हमने अपने नवजात शिशु को पूरी तरह कार्यात्मक IIS सर्वर में स्थानांतरित कर दिया। सौभाग्य से, इसमें कोई कठिनाई नहीं है। बस "वेबसाइट" परियोजना के गुण टैब पर जाएं और "वेब" अनुभाग में "आईआईएस एक्सप्रेस का उपयोग करें" को अनचेक करें। विज़ुअल स्टूडियो तुरंत इस तरह के बदलावों का जवाब देगा - यह एक आभासी निर्देशिका बनाने और web.config में कनेक्शन स्ट्रिंग्स को स्थानीयडब से SQL एक्सप्रेस में बदलने की पेशकश करेगा।

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

3. सुरक्षा सेटिंग्स । मैनुअल सुरक्षा सेटिंग्स के बारे में बिंदुओं का वर्णन नहीं करता है (हालांकि वे पुराने मैनुअल में थे)। जाहिर है, यह माना जाता है कि सब कुछ बिना शर्त व्यवस्थापक द्वारा निर्धारित किया गया है और सब कुछ अपने स्वयं के खाते के तहत स्पिन होगा। यदि ऐसा नहीं है, तो हमें इसकी आवश्यकता है:

एक। एप्लिकेशन के "AppData" फ़ोल्डर को लिखित अनुमति दें। वहीं नगेट के पैकेट जोड़े जाएंगे। हम उस खाते को अधिकार देते हैं जिसके तहत AppPool एप्लिकेशन कताई कर रहे हैं। यदि ApplicationPoolIdentity IIS सेटिंग्स में है, और विशिष्ट खाता नहीं है, तो हम IIS_IUSRS समूह को अधिकार देते हैं।
ख। उसी सिद्धांतों के द्वारा, हम SQL में डेटाबेस तक पहुँचने के अधिकार देते हैं।
सी। पंजीकरण के बाद, आप एक व्यवस्थापक के रूप में खुद को वही भूमिका दे सकते हैं। ऐसा करने के लिए, UI के माध्यम से मानक पंजीकरण के बाद, dbo.UserRoles तालिका में रिकॉर्ड डालें, dbo.Roles तालिका में भूमिका की आईडी देखें। उसके बाद, पता "<सर्वर पथ> / व्यवस्थापक" आपको व्यवस्थापक पैनल को सभी प्रकार के उपहारों और झलक चिह्न के साथ एक्सेस करने की अनुमति देगा।

4. गैलरीऑनर । यह असली सेटिंग्स के लिए web.config में "Gallery.GalleryOwner" आइटम को बदलने के लिए समझ में आता है। पंजीकरण के दौरान उनसे पत्र भेजे जाएंगे। और आप इस समाचार पत्र को पूरी तरह से निष्क्रिय कर सकते हैं। और वर्तमान SiteRoot को अवश्य लिखें।

<appSettings> <add key="Gallery.LuceneIndexLocation" value="AppData" /> <add key="Gallery.Environment" value="Development" /> <add key="Gallery.SiteRoot" value="http://your-server-name/" /> <add key="Gallery.GalleryOwner" value="%username% <%usermail%>" /> <add key="Gallery.ConfirmEmailAddresses" value="true" /> <add key="Gallery.HasWorker" value="false" /> </appSettings>

5. एक । आँकड़े फ़ाइल में फ़ंक्शन है । इस लेखन के समय, इसके आह्वान के कारण मुख्य पृष्ठ पर एक त्रुटि हुई।

कारण यह है कि नगेट के स्थानीय संस्करण में, आंकड़े अक्षम हैं । फिलहाल, यह केवल क्लाउड संस्करण के लिए है।

आप IStatisticsService का अपना कार्यान्वयन बना सकते हैं या इस कॉल को अक्षम कर सकते हैं। हमने दूसरा रास्ता चुना है।

वह, वास्तव में, सब है। अब हमारे पास गैलरी और पैकेज के साथ एक नगेट सर्वर है ।

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

और हम अपने स्वयं के प्रतीक सर्वर का निर्माण करने का तरीका जानने जा रहे हैं

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

यहां हम एक छोटी सी विषयांतर करेंगे और आपको बताएंगे कि यह कैसे काम करता है।

नगेट पैक कमांड के माध्यम से एक नगेट पैकेज बनाते समय, हम “–सिमबोल” ध्वज को निर्दिष्ट कर सकते हैं। नतीजतन, नगेट पुस्तकालय के साथ मानक पैकेज के अलावा, पैकेज <package_name> .symbols.nupkg, बनाता है, जिसमें एक pdb फ़ाइल और स्रोत कोड होता है। फिर इस पैकेज को SymbolSource सर्वर पर रखा जा सकता है, जो pdb फ़ाइल को इंडेक्स करेगा और प्रोजेक्ट स्रोतों को आंतरिक निर्देशिका में रखेगा। अगला, विज़ुअल स्टूडियो में, प्रतीक सर्वर तक पहुंच कॉन्फ़िगर की गई है , और यदि आवश्यक हो, तो यह सर्वर से पीडीबी फ़ाइल और स्रोतों को डाउनलोड करेगा। इस तरह डिबगिंग संभव हो जाती है।

लेकिन चूंकि हमने पुस्तकालयों को सार्वजनिक फीड में डालने की हिम्मत नहीं की है, इसलिए सूत्रों के बारे में कुछ नहीं कहना है। सिद्धांत रूप में, SymbolSource एक निजी फ़ीड बनाना संभव बनाता है। लेकिन वह सामुदायिक संस्करण का भी समर्थन करता है, जो आपको अपने आंतरिक सर्वर को तैनात करने की अनुमति देता है। कई कारणों से, हमने आखिरी रास्ता तय किया।

और फिर शुरू हुआ रोमांच ...

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

अरे हाँ, एक अतिरिक्त आवश्यकता है - आपको विंडोज के लिए डिबगिंग टूल्स को स्थापित करना होगा और उन्हें web.config में पथ लिखना होगा:

 <appSettings> <add key="SrcSrvPath" value="C:\Program Files\Debugging Tools for Windows (x64)\srcsrv" /> </appSettings>

वास्तव में, यह वही है जो हमने किया था - हमने SymbolServer के संस्करण 1.3.2 को डाउनलोड किया, स्थापित किया, कॉन्फ़िगर किया, एक जादुई स्क्रीन देखी।

डायग्नोस्टिक्स का शुभारंभ - सब ठीक है। हमने निर्देशों के अनुसार विज़ुअल स्टूडियो की स्थापना की है।

लेकिन डिबग काम नहीं करता है ...

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

वास्तव में। एक SymbolSource सर्वर का उपयोग करके एक SymbolSource सर्वर को डीबग करना।

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

ठीक है, आप क्या कर सकते हैं ... उन्होंने हंसते हुए, स्रोत कोड को माफ़ किया, इसे ठीक किया और एक पुल अनुरोध करने के लिए इकट्ठा हुए। और यहां हम पाते हैं कि एक समान अनुरोध पहले से मौजूद है , और यह लंबे समय से बनाया गया है। हां, और पैकेज संस्करण 1.3.2 को दो महीने पहले ही जारी किया जा चुका है, लेकिन फिक्स के साथ पैकेज का संस्करण अब तक जारी नहीं किया गया है। अब ये इतना मज़ेदार नहीं था। अधिक सटीक, बिल्कुल मजाकिया नहीं।

थोड़ी देर के लिए, हमने इस बारे में भी सोचा कि क्या इस सर्वर का उपयोग करना है या किसी दूसरे की तलाश करना है। लेकिन उपयोग के सकारात्मक पिछले अनुभव ... और नगेट डेवलपर्स ने इसे डिफ़ॉल्ट सर्वर बनाया, जिसका अर्थ है कि वे भरोसा करते हैं। और पैकेज संस्करण 1.3.1 ठीक काम करता है। नतीजतन, हमने सब कुछ सही स्रोत पर चलाने का फैसला किया। ऐसा करने के लिए, हमने अतिरिक्त रूप से "Web.config.transform" से सेटिंग को "Web.config" में कॉपी किया, क्योंकि स्थानीय असेंबली के दौरान ट्रांसफ़ॉर्म नहीं किया जाता है:

 <location path="WinDbg/pdbsrc"> <system.webServer> <handlers> <clear /> <add name="Deny" verb="*" path="*.config" type="System.Web.HttpForbiddenHandler" /> <add name="Allow" verb="GET,HEAD" path="*" type="System.Web.StaticFileHandler" /> </handlers> <security> <requestFiltering> <fileExtensions allowUnlisted="true"> <clear /> </fileExtensions> </requestFiltering> </security> </system.webServer> </location>

अब यह तैयार है और यह भी काम करना चाहिए और फिर यह सोचने का समय है

एक प्रभावी प्रक्रिया (बीटा) बनाने के लिए एक नगेट-सर्वर पर्याप्त क्यों नहीं है।

और यह एक बहुत ही सरल कारण के लिए पर्याप्त नहीं है: नगेट, जैसा कि यह है, पूरी कंपनी के लिए उपलब्ध एक सर्वर है।

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

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

निम्नलिखित प्रक्रिया का एक बीटा संस्करण है जिसे हम केवल परीक्षण और समझ रहे हैं। इसलिए, टिप्पणियों में पाठकों की राय सुनना बहुत अच्छा होगा।

इसलिए, हमने फैसला किया कि हमारे पास तीन नगेट टेप होंगे।

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

यह पता चला है, एक तरफ, कि मशीनों का निर्माण अंत उत्पादों के रिलीज संस्करणों का निर्माण अगर यह पैकेज के एक परीक्षण संस्करण को संदर्भित करता है तो एक परियोजना को कभी इकट्ठा नहीं करेगा ।

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

विजुअल स्टूडियो में, यह कुछ इस तरह दिखता है:

वैसे, यह वह जगह है जहां स्थानीय सर्वर परिनियोजन के पक्ष में तर्क काफी महत्वपूर्ण हो जाता है - इंटरनेट से स्वतंत्रता और स्थानीय नेटवर्क पर काम करते समय अधिक गति।

"क्या होगा अगर सर्वर में से एक क्रैश हो जाए?" आप पूछते हैं। खैर, इससे कोई फर्क नहीं पड़ता। आखिरकार, सभी टेपों के लिए "फ्रेमवर्क" की निर्माण प्रक्रिया एक है। यही है, अगर एक पैकेज संस्करण 1.2.3.4 को रिलीज घोषित किया जाता है, तो यह तीनों टेपों में निहित है। और इसके लिए उपयोग, उदाहरण के लिए, डेवलपर के पास हमेशा रहेगा।

एक ओर, ऐसी प्रक्रिया बहुत सरल नहीं है, लेकिन दूसरी ओर यह बहुत स्वाभाविक है, इसलिए आपको इसकी जटिलता के बारे में अक्सर सोचना नहीं पड़ता है - यह सिर्फ एक मानक वर्कफ़्लो पर पड़ता है।

अच्छा, अच्छा सोचा। अब आप प्रौद्योगिकी पर लौट सकते हैं और कंटीन्यूअस इंटीग्रेशन के बारे में सोच सकते हैं, जो पूरी प्रक्रिया को स्वचालित करता है।

लेकिन लेख पहले ही खींच लिया है।

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

आपका ध्यान देने के लिए धन्यवाद।

UPD: जैसा कि आमतौर पर होता है, लेख जोड़ने के ठीक एक दिन बाद, SymbolSource.Server.Basic पैकेज अपडेट (संस्करण 1.3.3) जारी किया गया था, जिसमें प्रतीक सर्वर को तैनात करने पर अनुभाग में उल्लिखित बग को ठीक किया गया था।

प्रोग्रामर, टीम, टीम की प्रभावशीलता के लिए संघर्ष में डेवलपर्स