Diary.ru में निरंतर एकीकरण

इस लेख में, हमने निरंतर एकीकरण (CI) टूल के बारे में थोड़ी बात करने का फैसला किया, जो हम Diary.ru पर उपयोग करते हैं और इस दिशा में कुछ छोटे विकास साझा करते हैं। अधिकांश सामग्री चयनित CI इंजन के एक भोजनीय विज्ञापन या पवित्र युद्ध (और एक नहीं) का कारण बनने की कोशिश की तरह लग सकती है, लेकिन यह इस उद्देश्य के लिए नहीं थी। लेख भी किसी फिच का मार्गदर्शक या विवरण नहीं है और इसे टोपी से एक लेख के रूप में माना जा सकता है - मुख्य बात यह है कि यह दिलचस्प और कारण चर्चा हो।

जेनकींस

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

हडसन और जेनकिन्स दोनों में मुख्य विचार सीआई के लिए सबसे सामान्यीकृत इंजन है। उनकी मुख्य ताकत उनकी व्यापकता होनी चाहिए:

• इंजन ले लो
• हमने सभी अवसरों के लिए एक हजार प्लग-इन लगाए
• इसे पूरा करने की कोशिश की जा रही है।
• लाभ टाइप करें

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

सिद्ध स्रोतों और अतिसूक्ष्मवाद के सिद्धांत का उपयोग करना मुझे हमेशा ऐसी परेशानियों से बचाता है। दुर्भाग्य से, जेनकिंस के मामले में, यह इतना सरल नहीं था। शुरू में एक अधिकतम सामान्य समाधान के विचार पर आधारित था, लेकिन फिर भी, .net दुनिया से संबंधित, .Net दुनिया के लिए, वह, बॉक्स से बाहर, कुछ भी नहीं कर सकता था।

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

नतीजतन, स्थिरता के मुद्दे, .Net दुनिया के लिए बुनियादी ढांचे की गरीबी, साथ ही बनाए रखने और प्रशासित करने की बहुत महत्वपूर्ण लागत जेनकींस के सभी लाभों को एक नि: शुल्क सीआई प्रणाली के रूप में शून्य कर देती है।

टीम शहर

तुरंत आरक्षण करें, मुझे इंजन की पसंद के साथ लंबे समय तक नुकसान नहीं हुआ। मुझे तुरंत पता था कि मैं JetBrains टीम सिटी का उपयोग करूंगा। कारण काफी सरल हैं:

• मैं उसे अच्छी तरह से जानता हूं और इसे कई बार लागू कर चुका हूं;
• प्रशासन करना आसान है;
• बॉक्स से बाहर वह सब कुछ है जो आपको .Net परियोजनाओं के लिए चाहिए;
• आईडीई और डेवलपर पर्यावरण के साथ उत्कृष्ट एकीकरण;
• प्रोजेक्ट टेम्प्लेट इंजन (यह जेनकींस में बहुत कमी थी);
• जेट दिमाग की पर्याप्त सुविधाजनक लाइसेंसिंग नीति: टीम सिटी के मुक्त व्यावसायिक संस्करण में केवल दो प्रतिबंध हैं: 20 बिल्ड प्रोजेक्ट और 3 बिल्ड मशीन;
• खैर, और अन्य उपहार।

सबसे महत्वपूर्ण कारण मुझे हमेशा याद रहता है: खुला स्रोत गरीबों के लिए है। तब मैं तुरंत सभी प्रशंसकों से एक विशेष ओलंपिक में भाग लेने का आग्रह करता हूं ताकि इस वाक्यांश को शाब्दिक रूप से न लिया जा सके। मैं इसे गहरा अर्थ देता हूं। ओपन सोर्स अच्छा है, और कई कंपनियों के लिए मुक्ति है, लेकिन सार हमेशा एक ही है: 90% मामलों में एक खुला स्रोत समाधान एक समान वाणिज्यिक विकास के लिए खो देगा। यही कारण है कि मैंने CC.Net और अन्य की ओर भी नहीं देखा।

एक तार्किक सवाल उठ सकता है: एटलसियन बांस या टीएफएस क्यों नहीं? सब कुछ बहुत सरल है। टीएफएस चुनने का मतलब होगा अन्य तकनीकों के लिए जलते हुए पुल, और मैं इस तरह के उपायों का समर्थक नहीं हूं और मुझे विश्वास है कि हमारी परियोजना बहुत जल्द 100% .नेट समाधान से आगे बढ़ जाएगी। हां, इसका उपयोग अन्य तकनीकों के लिए किया जा सकता है, लेकिन केवल बैसाखी का उपयोग करके, और फिर से समय खोना।

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

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

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

की शुरूआत

मैं टीमसिटी को स्थापित करने और कॉन्फ़िगर करने की प्रक्रिया को नहीं लिखूंगा, यह इस लेख का उद्देश्य नहीं है और बहुत दिलचस्प नहीं है।

मैं केवल यह कह सकता हूं कि मैंने सिस्टम को विंडोज सर्वर 2008 आर 2 पर स्थापित किया, और डेटाबेस के रूप में एमएस एसक्यूएल सर्वर 2008 आर 2 का उपयोग किया। एक सुविधा जल्दी से स्पष्ट हो गई। Ms Sql सर्वर के लिए डेटाबेस स्कीमा में, वे हमेशा यूनिकोड का समर्थन नहीं करते हैं। यह विशेष रूप से ध्यान देने योग्य था जब डेवलपर्स ने रूसी में इस पर टिप्पणी लिखी थी। यह समस्या काफी सरलता से हल हो गई थी। डेटाबेस में, vcs_history तालिका में, विवरण स्तंभ प्रकार को varchar (max) से nvarchar (अधिकतम) में बदल दिया गया है। हां, इससे भविष्य के संस्करणों के उन्नयन के साथ समस्याएं हो सकती हैं, लेकिन यह आवश्यक था।

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

हमारे द्वारा स्थापित पहला निर्माण .Net समाधान का सामान्य एकीकरण निर्माण है। अधिक सही ढंग से समझने के लिए कि वास्तव में बिल्ड में विफल रहा है और क्या, नीति निर्धारित की गई थी - svn में प्रत्येक कमिट के लिए बिल्ड को इकट्ठा करने के लिए।

यह पर्याप्त नहीं निकला, क्योंकि एक साधारण एकीकरण बिल्ड ने Asp.Net संकलन त्रुटियों की जांच नहीं की।
इस विषय पर थोड़ी चर्चा के बाद, हमने सभी वेब अनुप्रयोग परियोजनाओं में एक नया CI बिल्ड कॉन्फ़िगरेशन जोड़ने और प्रोजेक्ट फ़ाइलों में अगला लक्ष्य लिखने का निर्णय लिया

<Target Name="AfterBuild" Condition="'$(Configuration)' == 'CI Build'"> <AspNetCompiler VirtualPath="temp" Clean="true" PhysicalPath="$(ProjectDir)" /> </Target> 

इस प्रकार, प्रत्येक डेवलपर कमिट करने से पहले प्रोजेक्ट पर Asp.Net संकलन चला सकता है।

एकीकरण बिल्ड के साथ एक समस्या थी। जब Asp.Net संकलन को इसमें जोड़ा गया, पूर्ण निर्माण का समय 3 मिनट से 20 तक बढ़ गया, जिसने प्रत्येक प्रतिबद्ध के लिए बिल्ड के सभी लाभों को नकार दिया। हमें जल्द से जल्द और कुशलता से संकलन त्रुटि संदेश प्राप्त करने की आवश्यकता थी। इसलिए, एकीकरण निर्माण को 2 भागों में विभाजित करने का निर्णय लिया गया:

• संकलन का अनुकरण करें
• Asp.Net संकलन

TeamCity तथाकथित स्नैपशॉट निर्भरता का समर्थन करता है। संक्षेप में, यह निम्नानुसार काम करता है:

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

इस प्रकार, अगर एकीकरण निर्माण विफल रहा तो हमने अनावश्यक Asp.Net संकलन के साथ मशीनों को लोड नहीं किया। और उन्हें बहुत तेजी से msbuild त्रुटियाँ मिलीं।

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



या REST API के माध्यम से प्राप्त करें।

TeamCity से पहले, PowerShell स्क्रिप्ट को कॉल करके पैकेज को इकट्ठा किया गया था, जिसने केवल 7Zip का उपयोग किया था और कमांड लाइन के माध्यम से संग्रहकर्ता को निर्देश दिया था कि किस प्रकार की फ़ाइलों को संग्रह में आवश्यक नहीं था (चूंकि संग्रह में शामिल होने वाली फ़ाइल प्रकारों की संख्या बहुत बड़ी थी)। इसलिए, विरूपण साक्ष्य प्रणाली ने थोड़ी निराशा की। सबसे पहले, निर्मित इन आर्कवर्स में से किसी ने 7Zip की तुलना में एक अच्छा संपीड़न / गति अनुपात नहीं दिखाया। निकटतम था tar.gz, लेकिन अभी। दूसरे, कलाकृतियों की स्क्रिप्ट में कुछ प्रकार की फ़ाइलों को संग्रह से बाहर करने के लिए निर्माण को पंजीकृत करना असंभव था, जो बेहद असुविधाजनक था और इसमें शामिल होने के लिए आवश्यक सभी चीजों को पूरी तरह से निर्धारित करने के लिए मजबूर किया गया था (वैसे, आप इस सुविधा के लिए वोट कर सकते हैं )। इसके अलावा, संग्रह का आकार लगभग 500 एमबी था, जिसने यूआई को शाश्वत के बारे में सोचा।

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

NuGet

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

TeamCity दो NuGet Feed'a प्रदान करता है: एक अतिथि, प्रमाणीकरण के बिना, दूसरा, TeamCity पर स्थापित प्राधिकरण प्रकार के साथ।



फ़ीड को Visual Studio और NuGet Restore पैकेज (NuGet.targets file) दोनों में सक्षम किया जा सकता है ताकि धूर्त पर एक नई निर्भरता जोड़ने की संभावना को समाप्त किया जा सके।

 <ItemGroup Condition=" '$(PackageSources)' == '' "> <!-- Package sources used to restore packages. By default, registered sources under %APPDATA%\NuGet\NuGet.Config will be used --> <!-- The official NuGet package source (https://nuget.org/api/v2/) will be excluded if package sources are specified and it does not appear in the list --> <PackageSource Include="http://teamcity/guestAuth/app/nuget/v1/FeedService.svc/" /> <!--<PackageSource Include="https://nuget.org/api/v2/" /> --> </ItemGroup> 

दुर्भाग्य से, मरहम में एक मक्खी अभी भी मौजूद है। एम्बेडेड NuGet सर्वर में पैकेज प्रबंधन के लिए कोई UI नहीं है। इसके अलावा, JetBrains में मुख्य विचार यह है कि इसका उपयोग केवल NuGet पैकेज के लिए किया जाना चाहिए जो आपकी कंपनी के लिए अद्वितीय हैं। उनके अनुसार, वे आधिकारिक नुगेट सर्वर के साथ प्रतिस्पर्धा करने वाले नहीं हैं।

आप फ़ीड करने के लिए एक NuGet पैकेज जोड़ सकते हैं, लेकिन इसके लिए आपको इसे कलाकृतियों की सूची में प्रदर्शित करने की आवश्यकता है। जो, वास्तव में, मैंने किया।

सभी आवश्यक पैकेजों को एसवीएन में एक अलग भंडार में जोड़ा गया था, और नए बिल्ड कॉन्फ़िगरेशन ने सभी सामग्रियों को कलाकृतियों में जोड़ा।



और परिणामस्वरूप।



यह काम किया, और सभी पैकेज फ़ीड में उपलब्ध हो गए।



केवल समस्या फ़ीड से पैकेज निकाल रही थी। हमने इसका निर्माण अंतर्निहित TeamCity सफाई उपकरण का उपयोग करके किया।



इस प्रकार, जब svn से हटा दिया जाता है, तो पैकेज पिछले बिल्ड के लिए कलाकृतियों की सूची में कभी भी करघा नहीं होगा - इसलिए, यह हमेशा के लिए फ़ीड से गायब हो जाएगा।

अपनी लाइब्रेरी को NuGet पैकेज में बदलने के लिए, यह विशेष NuGet Pack रनर का उपयोग करने के लिए पर्याप्त है, जिसे कॉन्फ़िगर करना बहुत आसान है।

अंतभाषण

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

PS जैसा कि लेख की शुरुआत में वर्णित है, यह एक विज्ञापन नहीं है, और कंपनी Diary.ru को JetBrains से कोई लाइसेंस रियायतें नहीं मिलती हैं।

अनुच्छेद लेखक: अलेक्जेंडर लुकाशोव, विकास विभाग के प्रमुख, डायरीरी ।13।