चिंता को कैसे रोकें और आरंभ करें?

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

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

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

परीक्षण, परीक्षण, परीक्षण

मैंने 3 बार "परीक्षण" शब्द लिखा, इसलिए नहीं कि तीन बार शब्दों को दोहराना मजेदार है, बल्कि इसलिए कि हम 3 प्रकार के परीक्षणों का उपयोग करते हैं:

1. व्यापार तर्क की इकाई परीक्षण। एल्बा कई सेवाओं का एक संयोजन है जो एक-दूसरे (वेब, डेटा स्टोरेज, डायरेक्ट्री सर्विस, प्रिंट सर्विस, आदि) के साथ परस्पर क्रिया करती हैं। हम इन सभी सेवाओं और वेब के सर्वर भाग को TDD शैली में लिखते हैं। टीडीडी के बारे में बहुत कुछ कहा और लिखा गया है। इस पद्धति का मुख्य लाभ, मेरा मानना ​​है, एक ऐसी स्थिति का निर्माण है जिसमें परीक्षण लिखना एक नियमित या उबाऊ काम नहीं है। धीरे-धीरे परीक्षणों का निर्माण करें और इकाई परीक्षणों के वर्तमान सेट को पास करने के लिए पर्याप्त रूप से पर्याप्त कोड लिखें, लेकिन एक भी पंक्ति अधिक मज़ेदार नहीं है, यह शतरंज की तरह एक मानसिक खेल है। इसके अलावा, ईमानदारी से इकाई परीक्षणों के साथ अपने कोड की हर पंक्ति को कवर करते हुए, आपको अधिक उन्नत कोड मिलता है। कट्टरता यहाँ उपयुक्त है: यदि कोई ऐसा कोड है जिसे मिटाया जा सकता है और कोई परीक्षण नहीं गिरा है, तो इस कोड को शैक्षिक उद्देश्यों के लिए तुरंत मिटा दिया जाना चाहिए। यह कहने योग्य है कि हर किसी के पास एक अच्छे कोड का अपना विचार है: छात्र एक ऐसे कोड पर विचार करते हैं जो संपूर्ण होने के लिए तैयार है, और कुछ डेवलपर्स किसी भी कोड पर विचार करते हैं जो काम करता है। सौभाग्य से, आप इस बारे में बहस नहीं कर सकते। सबसे सुंदर व्यक्ति अंकल बॉब ने लंबे समय तक सब कुछ संक्षेप में प्रस्तुत किया है जिसे अच्छे कोड की औपचारिक विशेषताओं के क्षेत्र में सामान्यीकृत किया जाना चाहिए और इसके बारे में लेखों की एक श्रृंखला लिखी। एल्बा में, हमें अच्छा कोड मिलता है जो एसओएलआईडी सिद्धांतों का अनुपालन करता है। यदि आप अभी भी नहीं जानते हैं कि यह क्या है और आप हास्केल डेवलपर नहीं हैं, तो यह संभावना है कि आप गलत या व्यर्थ रहते हैं :) इकाई परीक्षणों द्वारा कवर किया गया कोड बनाना और संशोधित करना आसान है: परीक्षण पुराने व्यापारिक तर्क की अपरिवर्तनीयता की गारंटी देते हैं और SOLID आपको स्थानीय रूप से महत्वपूर्ण परिवर्तन करने की अनुमति देता है (आपके पास कॉपी पेस्ट और 3 कक्षाएं जो समान कार्य करते हैं;) - आप घोषित लक्ष्य को प्राप्त करते हैं, विकास की गति कम नहीं होती है और सब कुछ निर्दिष्ट गुणवत्ता के साथ होता है।
   
   
2. क्लाइंट-साइड जावास्क्रिप्ट के लिए यूनिट परीक्षण। सर्वर-साइड व्यापार तर्क बहुत अच्छा है, लेकिन अंतिम उपयोगकर्ता एक वेब एप्लिकेशन देखते हैं। और वे केवल सुस्त पृष्ठों को नहीं देखना चाहते हैं, सब कुछ उड़ना और विस्फोट होना चाहिए। इसलिए, हम बहुत से ग्राहक तर्क लिखते हैं। सर्वर-साइड बिजनेस लॉजिक की तुलना में कुछ भी नया नहीं है: कोड को SOLID होना चाहिए और परीक्षणों के साथ कवर किया जाना चाहिए, बस एक अलग भाषा। इस तरह, हम सामान्य-उद्देश्य वर्गों और नियंत्रणों (उदाहरण के लिए, क्लाइंट सत्यापनकर्ता) का परीक्षण करते हैं।
   
   
3. वेब अनुप्रयोग के कार्यात्मक परीक्षण। सभी यूनिट परीक्षण पास कर सकते हैं, लेकिन यह गारंटी नहीं देता है कि उपयोगकर्ता को किसी विशेष पृष्ठ के साथ कोई समस्या नहीं है। हम प्रत्येक प्रपत्र के फ़ील्ड्स को भरने और सर्वर पर इन फ़ील्ड्स को संसाधित करने के लिए यूनिट परीक्षणों का परीक्षण नहीं करते हैं। पत्ती पृष्ठों के सही व्यवहार को पकड़ने के लिए, हम कार्यात्मक परीक्षणों का उपयोग करते हैं। वास्तव में, हम उपयोगकर्ता के व्यवहार को दोहराते हैं: लिंक पर क्लिक करें, पृष्ठ के लिए फ़ील्ड के एक निश्चित सेट के साथ लोड करने के लिए प्रतीक्षा करें, इन फ़ील्ड भरें, सत्यापन की वैधता की जांच करें, "सहेजें" बटन पर क्लिक करें और सुनिश्चित करें कि वास्तव में हमारे रिपॉजिटरी में फ़ील्ड में दर्ज किया गया है। भले ही पृष्ठ पर, कुछ शर्तों के आधार पर, कुछ छोटे शिलालेख बदलते हैं - इसके लिए एक परीक्षण है। अगर डेवलपर कहता है कि उसने उन सभी परिस्थितियों का परीक्षण करना असंभव है, जिसके तहत उसने कोड लिखा है, तो उसने इस कोड को नशे में या झूठ लिखा है (हम साधारण व्यापार तर्क के बारे में बात कर रहे हैं, और वैज्ञानिक अनुप्रयोगों के बारे में नहीं, उदाहरण के लिए)। इस प्रकार एक परीक्षा लग सकती है:
   
   

   [Test] public void ChangeEmailWithGoodPassword() { const string newEmail = "hello_habr@gmail.com"; Prepare(); emailSettingsPage.Email.TypeValueAndWait(newEmail); emailSettingsPage.Password.TypeValueAndWait("superpassword"); emailSettingsPage.SaveButton.Click(); emailSettingsPage.WaitSaveSucceded(); emailSettingsPage = emailSettingsPage.Refresh(); emailSettingsPage.Email.WaitValue(newEmail); } 

   
   जब आप परीक्षण चलाते हैं तो यह होता है:
   
   
   
   इस तरह के समझने योग्य परीक्षणों को लिखने के लिए, हम उनके लिए पृष्ठों और नियंत्रणों के लिए सार का निर्माण करते हैं, जो उनके समर्थन की जटिलता को कम करते हैं, पठनीयता को बढ़ाते हैं और यहां तक ​​कि टीडीडी पर कार्यात्मक परीक्षण लिखना संभव बनाते हैं!

परीक्षण चल रहा है

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



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

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

जोड़ी प्रोग्रामिंग

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

पूर्व-प्रतिबद्ध कोड समीक्षा

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

आयोजन

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



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

कीड़े

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

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

रिफैक्टरिंग

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

ड्यूटी पर मौजूद इंजीनियर

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

रिलीज इंजीनियर

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

वास्तव में, एक नियम के रूप में, ड्यूटी पर इंजीनियर और रिलीज इंजीनियर एक व्यक्ति हैं।

परिणाम

इस तरह से अभिनय करते हुए, लगभग 2 वर्षों से अब हम प्रति माह 1 महत्वपूर्ण रिलीज करने में सक्षम हैं। प्रणाली बहुत गतिशील रूप से विकसित हो रही है, लेकिन हम एक सप्ताह में कई अपडेट करने से डरते नहीं हैं (हर चीज की योजना नहीं बनाई जा सकती है: कानून बहुत तेजी से बदल रहा है और पिछले छह महीनों में उपयोगकर्ताओं की वृद्धि बहुत महत्वपूर्ण है), हमारे इंजीनियरिंग अभ्यास विकास को बहुत प्रबंधनीय और पूर्वानुमान योग्य बनाते हैं।
तकनीकी विवरण
IDE: Microsoft VisualStudio + JetBrains ReSharper
सतत एकीकरण सर्वर: JetBrains टीमसिटी
बग ट्रैकर: JetBrains YouTrack
कार्यात्मक परीक्षण: सेलेनियम
वीसीएस: मर्क्यूरियल
वेब सर्वर: Microsoft IIS + nginx
DB: MS SQL सर्वर

PS शायद यह पाठ से स्पष्ट नहीं है, लेकिन हमारे पास एक परीक्षक है। वह हर समय व्यस्त रहता है और बहुत अच्छा काम करता है :)
PPS महान उपकरण के लिए हमारी प्यारी JetBrain कंपनी को बहुत बहुत धन्यवाद :)