एक डेबियन रिपॉजिटरी के रूप में टीमसिटी

... या *.deb पैकेज और अधिक बनाने के लिए TeamCity का उपयोग करना।

मुझे tcDebRepository मॉड्यूल को जानने के लिए एक लेख लिखने के लिए प्रेरित किया गया था। मैं भोलेपन से मानता था कि "अब मैं इसमें प्लग लगाऊंगा और सब कुछ जादुई तरीके से काम करेगा।" हमेशा की तरह, यह काम नहीं किया, और अंत में एक निश्चित अनुभव जमा हुआ था, जिसे मैं व्यवस्थित करना चाहता था।

लेख किसी भी तरह से TeamCity की मूल बातें का परिचय नहीं है और यह मानता है कि पाठक पहले से ही TeamCity और Debian GNU / Linux बुनियादी ढांचे दोनों से परिचित है। यदि आप पहले से ही कल्पना करते हैं कि निरंतर एकीकरण क्या है, लेकिन आपने कभी टीमकिट को अपने हाथों में नहीं रखा है, तो आप शायद यहां हैं । आप डेबियन न्यू मेंटेनर्स गाइड में डेबियन में पैकेज बनाने के बारे में पढ़ सकते हैं।

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

योजनाओं

बल्कि मनमाने तरीके से, मैंने प्रयोगों के लिए 4 पैकेज चुने:

• ऑटोटूलस-देव ( Git )
• बैश ( गिट , बाज़ार )
• डीहेल्पर ( git )
• dpkg ( git )

बिल्ड कॉन्फ़िगरेशन की संख्या के लिए व्यावसायिक लाइसेंस की सीमाओं को देखते हुए, 20 पैकेज तक "डायल" करना संभव था।

ट्रेनिंग

TeamCity को आधिकारिक साइट से डाउनलोड किया जाता है। टीमकीटी के अलावा, हमें प्रत्येक एजेंट मशीनों पर बिल्ड-एसेंशियल- पैकेज को स्थापित करने की आवश्यकता होगी, साथ ही सभी चार पैकेजों के लिए असेंबली के लिए आवश्यक निर्भरता (श्रेणियों से) build-depends और build-depends-indep )। यह बिल्ड निर्भरता समस्याओं को कम (लेकिन जरूरी नहीं कि समाप्त करेगा)।

पैकेज प्रकार डेबियन GNU / लिनक्स पर

अन्य विशेषताओं के बीच, पैकेज "देशी" ( देशी ) और बाहरी ( गैर-देशी ) ( अधिक ) में विभाजित हैं। मूल पैकेज ( autotools-dev debhelper , debhelper , dpkg ) को आमतौर पर डेबियन प्रोजेक्ट के हिस्से के रूप में विकसित किया जाता है, और स्रोत कोड में विधानसभा के लिए आवश्यक मेटा-जानकारी (स्रोत पेड़ की जड़ में debian/ निर्देशिका) शामिल है।

बाहरी पैकेज ( bash ) के बीच का अंतर यह है कि स्रोत कोड किसी भी तरह से डेबियन से बंधा हुआ नहीं है, और रखरखाव इंजीनियरों (रूसी भाषा में प्रलेखन में इसे "डेबियन डेवलपर" कहा जाता है, अंग्रेजी भाषा में "अनुरक्षक") आपको मेटा-जानकारी और समानांतर स्रोत कोड ट्री बनाए रखना होगा पैच (यह debian/ निर्देशिका की बहुत सामग्री है)।

सामान्य सेटिंग्स

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

कलाकृतियाँ pkgname.orig.tar.{gz,bz2,xz} और pkgname.debian.tar.{gz,bz2,xz} देशी पैकेजों के लिए नहीं बनाई गई हैं।

TeamCity को सोर्स कोड कनेक्ट करना

सबसे अधिक बार, बस यह चरण जटिल नहीं है: बस निर्माण कॉन्फ़िगरेशन सेटिंग्स पर जाएं और संस्करण नियंत्रण प्रणाली (वीसीएस रूट) की एक नई जड़ जोड़ें। "देशी" पैकेजों के लिए, इस ऑपरेशन को एक बार, बाहरी लोगों के लिए, एक नियम के रूप में, दो बार (लेकिन डिबेक प्रोजेक्ट के बाहर दोनों डेवलपर्स और रखरखाव इंजीनियर एक ही DVCS ( Git , Bazaar ) का उपयोग करते हैं, और परिवर्तन होते हैं, एक बार किया जाना चाहिए) कोड लगातार एक रिपॉजिटरी से दूसरे में भटक रहा है, एक ही समय में मेटा-जानकारी और पैच के लिए मर्ज संघर्ष पैदा किए बिना)।

एकमात्र विशेषता यह है कि हमारे मामले में कलाकृतियों को स्रोत कोड ट्री (ऊपर एक निर्देशिका) के बाहर एकत्र किया जाएगा, इसलिए हमें चेकआउट नियमों को कॉन्फ़िगर करने की आवश्यकता है, ताकि, कह सकें कि dpkg पैकेज के स्रोत कोड को वर्तमान कार्य निर्देशिका में लोड नहीं किया गया है, लेकिन एक ही नाम के पैकेज में उपनिर्देशिका, अर्थात् dpkg/ । यह चेकआउट नियमों में एक पंक्ति जोड़कर प्राप्त किया जाता है :

 +:.=>dpkg 

और अंततः इस तरह दिखता है:

अब आप VCS ट्रिगर जोड़ सकते हैं और संस्करण नियंत्रण सेटिंग्स पर नहीं लौट सकते हैं:

बाजार के साथ एकीकरण

"लेकिन bash बनाने के लिए बाज़ार के साथ एकीकरण आवश्यक है, और मानक टीमसिटी डिलीवरी इस प्रणाली का समर्थन नहीं करता है!" - चौकस पाठक कहेगा, और वह सही होगा। इसके अतिरिक्त, TeamCity , alas, हमें bzr::http://bazaar.launchpad.net/~doko/+junk/pkg-bash-debian URL जैसे bzr::http://bazaar.launchpad.net/~doko/+junk/pkg-bash-debian - JGit जैसे कई प्रतिबंधों को जोड़ने की अनुमति नहीं देगा।

बाजार का समर्थन करने के लिए एक बाहरी मॉड्यूल है, लेकिन इसमें कम से कम दो गंभीर खामियां हैं:

• एजेंट-साइड चेकआउट समर्थित नहीं है, और
• बाज़ार की मानक डिलीवरी पर्याप्त नहीं है, क्योंकि मॉड्यूल bzr xmlls और bzr xmllog की कार्यक्षमता पर निर्भर करता है, जो केवल निर्माण प्रक्रिया के दौरान पाया जाता है:

चूंकि टीमसिटी सर्वर ने विंडोज पर मेरे लिए काम किया, इसलिए मैंने सर्वर साइड पर बाज़ार को स्थापित करने के मज़ेदार साहसिक कार्य को छोड़ दिया, और bash बजाय bash कमांड लाइन रनर और निम्न स्क्रिप्ट का उपयोग करके एक और बिल्ड स्टेप (गरीबों के लिए बाज़ार एकीकरण) को जोड़ा। खोल:

 #!/bin/bash # # vim:ft=sh: # export LANG=C export LC_ALL=C set -e rm -rf bash/debian bzr branch http://bazaar.launchpad.net/~doko/+junk/pkg-bash-debian bash/debian major_minor=$(head -n1 bash/debian/changelog | awk '{print $2}' | tr -d '[()]' | cut -d- -f1) echo "Package version from debian/changelog: ${major_minor}" tar_archive=bash_${major_minor}.orig.tar rm -f ${tar_archive} ${tar_archive}.bz2 # +:.=>bash checkout rule should be set for the main VCS root in TeamCity tar cf ${tar_archive} bash tar --delete -f ${tar_archive} bash/debian # Required by dpkg-buildpackage bzip2 -9 ${tar_archive} 

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

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

विधानसभा: सेटअप

इसे बनाने के लिए, हमारे लिए पहले से परिचित कमांड लाइन रनर का उपयोग करना पर्याप्त है, जिसे dpkg-buildpackage । -uc और -uc मतलब है कि हम अपने पैकेज के लिए डिजिटल हस्ताक्षर नहीं बनाना चाहते हैं। यदि आप अभी भी चाहते हैं, तो आपको प्रत्येक एजेंट को GnuPG कुंजी की संबंधित जोड़ी को डाउनलोड करना होगा।

यह भी ध्यान दें कि वर्तमान कार्य निर्देशिका में dpkg-buildpackage को निष्पादित नहीं किया जाना चाहिए, लेकिन उपनिर्देशिका (जहां स्रोत कोड पेड़ अपलोड किया जाएगा) में उसी नाम के पैकेज में। यदि संस्करण नियंत्रण को कॉन्फ़िगर किया गया है, तो "वर्किंग डायरेक्टरी" फ़ील्ड को माउस के एक क्लिक के साथ मैन्युअल रूप से निर्देशिका नाम दर्ज किए बिना भरा जा सकता है:

विधानसभा: समस्या का समाधान

कोड की गुणवत्ता

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

पर निर्भर करता है

जब आप पहली बिल्ड शुरू करते हैं, तो हम देखेंगे कि dpkg-buildpackage रिटर्न कोड 3 के साथ काम करना समाप्त कर दिया है।

असेंबली प्रोटोकॉल देखने के परिणामस्वरूप, यह पता चलता है कि कुछ निर्भरताएं अभी भी गायब हैं:

लेकिन यहां हमने वह सब कुछ स्थापित किया जो आवश्यक था (सभी एजेंटों पर), और dpkg-buildpackage एक ही कोड के साथ समाप्त होता है। मामला क्या है? यहां कई बारीकियां हैं।

• सबसे अधिक संभावना है, आप डेबियन अस्थिर या डेबियन प्रयोगात्मक से सॉफ्टवेयर का निर्माण करेंगे। इस मामले में, विधानसभा के लिए आवश्यक निर्भरता को संतुष्ट करने के लिए, टीमसिटी एजेंटों को डेबियन अस्थिर या डेबियन प्रयोगात्मक (अन्यथा dpkg-buildpackage "शपथ" dpkg-buildpackage होगा कि निर्भरता का आपका स्थिर संस्करण "पुराना" है)। त्रुटि को दबाने के लिए, कभी-कभी केवल -d स्विच जोड़ना पर्याप्त होता है:
  

   dpkg-buildpackage -uc -us -d 

• अप्रचलित निर्भरता का एक विशेष मामला जीएनयू ऑटोटूलस के एक नए संस्करण द्वारा बनाई गई configure स्क्रिप्ट है जो वर्तमान में सिस्टम पर स्थापित है। dpkg-buildpackage इस स्थिति का निदान करने dpkg-buildpackage असमर्थ है - इसके बजाय, बिल्ड प्रोटोकॉल में, हम m4 मैक्रोज़ गुम होने के बारे में गुप्त संदेश देखते हैं। इसका समाधान GNU ऑटोटूल के वर्तमान संस्करण का उपयोग करके configure स्क्रिप्ट को फिर से बनाना है। बस निर्माण के पहले चरण के रूप में निम्नलिखित कमांड जोड़ें:
  

   autoreconf -i 

टूटी हुई यूनिट टेस्ट

अगर हम अभी भी खुद को धोखा देना चाहते हैं और अभी भी अपना पैकेज जमा करना चाहते हैं, तो संशोधित dpkg-buildpackage में dpkg-buildpackage चलाने के लिए यह पर्याप्त होगा:

 DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -uc -us 

आप यहां आत्म-धोखे के अन्य तरीकों के बारे में पढ़ सकते हैं।

फिनिश लाइन

नरक के सभी क्षेत्रों को पारित करने के बाद, हम देखेंगे कि अगली विधानसभा कलाकृतियों के निर्माण के साथ समाप्त हुई:

यदि आप नहीं चाहते हैं कि पैकेज असेंबली के प्रत्येक इंक्रीमेंट के साथ यूनिट असेंबली कलाकृतियों की संख्या बढ़े (अंततः dpkg_1.18.16_i386.deb , dpkg_1.18.17_i386.deb और dpkg_1.18.18_i386.deb की विस्तृत श्रृंखला), वर्किंग डायरेक्टरी की सामग्री प्रत्येक विधानसभा से पहले चुनिंदा रूप से साफ करें। यह मैन्युअल रूप से dpkg-buildpackage पहले rm -rf dpkg-buildpackage को कुख्यात विरूपण साक्ष्य पथों के साथ तर्कों के रूप में कॉल dpkg-buildpackage किया जा सकता है, लेकिन एक बेहतर तरीका है - स्नेही नाम "Mop" के साथ मानक TeamCity मॉड्यूल। इस तरह इसकी सेटिंग्स दिखती हैं (यहाँ कुंजी "अगले निर्माण शुरू होने से पहले" है):

लेकिन असेंबली प्रोटोकॉल का संगत अंश इस तरह दिखेगा यदि स्वरा मॉड्यूल सही ढंग से कॉन्फ़िगर किया गया है:

अब हमारे डेबियन भंडार को स्थापित करने का समय है। यह tcDebRepository मॉड्यूल सेटिंग्स में विरूपण साक्ष्य फिल्टर जोड़कर प्राप्त किया जाता है। कुछ असुविधा यह है कि प्रत्येक कॉन्फ़िगरेशन के लिए (पढ़ें: सॉफ्टवेयर पैकेज) आपको एक नया फ़िल्टर जोड़ना होगा जो पिछले एक के समान है:

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

वास्तुकला पैकेज निर्देशिकाएँ

और उपलब्ध पैकेजों की एक सूची

जब /etc/apt/sources.list एक रिपॉजिटरी जोड़ते हैं /etc/apt/sources.list तो आप ग्राहक की ओर से सभी समान पैकेज देख सकते हैं:

यह ध्यान देने योग्य है कि पैकेज में डिजिटल हस्ताक्षर नहीं हैं

नायब! यदि आप कई आर्किटेक्चर ( i386 , x32 , amd64 , arm ) के लिए निर्माण करते हैं, तो आपके पास एक पैकेज के अनुरूप कई अलग-अलग बिल्ड कॉन्फ़िगरेशन होने चाहिए और एजेंटों के लिए आवश्यकताओं में भिन्नता होनी चाहिए, या, VCS ट्रिगर के अलावा, ध्वज के साथ शेड्यूल ट्रिगर जोड़ें "ट्रिगर बिल्ड पर। सभी सक्षम और संगत एजेंट ":

कुछ समय बाद, आप देखेंगे कि dpkg परियोजना सक्रिय रूप से विकसित हो रही है, लेकिन बाकी प्रतिभागी बाँस का धुआँ लेते हैं।