टीम अब दर्दनाक धीमी गति से

Question

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

• हम लगभग 40 वेब अनुप्रयोगों है कि प्रत्येक बहुत अलग हैं मिल गया है, लेकिन साझा विधानसभाओं के एक झुंड से चलेंगे
• इन वेब अनुप्रयोगों में से प्रत्येक अपने स्वयं के समाधान है;
• इन वेब अनुप्रयोगों में से प्रत्येक द्वारा संदर्भित लगभग 10 से 25 साझा असेंबली हैं;
• एक बिल्ड परिभाषा मौजूद है जिसमें ट्रंक में प्रत्येक चेक-इन पर निकाले गए सभी समाधान शामिल हैं;

और यहाँ बुनियादी समस्याओं हम

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

पिछले कई महीनों में हमने सुस्तता और इस समस्या को नजरअंदाज कर दिया है, लेकिन अब निर्माण का समय एक घंटे से डेढ़ घंटे से अधिक है।

मैं अपने नियंत्रण के लिए क्रूज़ कंट्रोल सीखने और स्विच करने के विचार से घूम रहा हूं। कोई भी उससे असहमत है?

किसी भी मदद की सबसे सराहना की जाती है। धन्यवाद!

Answer 1

सबसे पहले, ऐसा लगता है जैसे आपके सभी वेब ऐप्स एक ही टीम प्रोजेक्ट में निहित हैं। यदि यह सच है, तो उन्हें तार्किक समूहों में विभाजित करें। आम तौर पर एक एकल टीम परियोजना में एक एकल परिनियोजन मॉडल शामिल होना चाहिए।

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

समेकित करने के लिए, आपको अपनी निर्माण रणनीति को सरल बनाना होगा।

Answer 2

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

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

इसके अलावा, चीज़ को बनाए रखने के लिए कम से कम कुछ संसाधनों को समर्पित करने के लिए तैयार रहें। यह पूर्णकालिक नौकरी नहीं है (और मैं इसे एक प्यार के लिए कर रहा हूं, क्योंकि यह निरंतर प्रक्रिया में सुधार करता है)। हमारे अनुकूलन ने हमें 20 उत्पादों में 400 से अधिक घटकों के लिए हमारे पहले उत्पाद के 2 घंटे के मोनोलिथिक बिल्ड से लिया है जो लगभग 20 मिनट के भीतर कई मशीनों पर समानांतर बनाते हैं, इसलिए यह इसके लायक है।

Answer 3

क्या आपको वास्तव में हर वेब ऐप में सब कुछ बनाने की ज़रूरत है? यदि साझा असेंबली नहीं बदली हैं, तो उन्हें बार-बार क्यों बनाएं?

यहाँ एक विचार है:

1. चलो हर वेब एप्लिकेशन को अपने स्वयं के \ lib फ़ोल्डर है।
2. lib साझा फ़ोल्डर में प्रत्येक साझा असेंबली रखें।
3. वेब ऐप को केवल अपने स्थानीय lib फ़ोल्डर से साझा असेंबली का संदर्भ दें।
4. में सब कुछ की जाँच करें।

अब निर्माण शुरू नहीं करना चाहिए जब तक कि कुछ बदल दिया है, और निर्माण साझा विधानसभाओं में शामिल नहीं होंगे।

• सभी साझा असेंबली वाले केंद्रीय फ़ोल्डर होना चाहिए।
• यहां कोई भी परिवर्तन सभी स्थानीय \ lib फ़ोल्डर्स को प्रचारित करना चाहिए।
• अंत में, जब भी वे बदलते हैं तो किसी भी साझा असेंबली को केंद्रीय फ़ोल्डर में कॉपी किया जाना चाहिए।

यहां विचार केंद्रीय फ़ोल्डर के बारे में जानने के लिए एक साझा असेंबली प्रोजेक्ट होना है। यह निर्माण की प्रतिलिपि बनाने के लिए आवश्यक किसी भी पोस्ट-बिल्ड कार्रवाई को सरल बना देगा।

केंद्रीय फ़ोल्डर को इस तरह से प्रबंधित किया जाना चाहिए कि किसी भी बदलाव को सभी संदर्भ वेब ऐप में कॉपी किया जाएगा।

Answer 4

तो यहां मैंने जो किया है, और मुझे 9 मिनट तक का निर्माण मिल गया है। प्रोजेक्ट की मात्रा के लिए मैं संकलित कर रहा हूं, मैं इसके साथ ठीक हूं।

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

चाल करने के लिए, मैं बस TFSBuild के भीतर CoreDropBuild लक्ष्य को ओवरराइड करता हूं।proj फ़ाइल:

<Target Name="CoreDropBuild" 
     Condition=" '$(SkipDropBuild)'!='true' and '$(IsDesktopBuild)'!='true' " 
     DependsOnTargets="$(CoreDropBuildDependsOn)" > 
      <Exec Command="move $(BinariesRoot)\Release d:\BuildOutput\$(BuildNumber)\Release"/>  
</Target>