रिलीज प्रक्रिया सुधार

Question

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

मुझे उम्मीद है कि लोग अपने संगठन में इस प्रक्रिया में किए गए सुधारों को साझा करेंगे ताकि हम सभी 'दर्द को कम करने' के लिए कदम उठा सकें।

तो सवाल यह है कि, अपनी रिलीज प्रक्रिया के एक दर्दनाक/समय लेने वाले हिस्से को निर्दिष्ट करें और आपने इसे सुधारने के लिए क्या किया?

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

1. देव डेटाबेस में सभी परिवर्तनों को शामिल किए गए हैं, जिनमें से कुछ अभी भी हो सकता है 'प्रगति पर काम करता है' -:

   यह काफी अच्छा काम करता है लेकिन इस दृष्टिकोण के साथ समस्याएं हैं।

2. कभी-कभी डेवलपर्स ने विरोधाभासी परिवर्तन किए (जो कि उत्पादन में रिलीज़ होने तक ध्यान नहीं दिया गया था)
3. यह स्क्रिप्ट बनाने और मान्य करने के लिए एक समय लेने वाली और मैन्युअल प्रक्रिया थी (मेरा मतलब है, समस्या का समाधान करने की कोशिश करें 1 और 2)।
4. जब स्क्रिप्ट के साथ समस्याएं थीं (उदाहरण के लिए जिस क्रम में चीजें चल रही थीं जैसे एक रिकॉर्ड बनाने के लिए जो स्क्रिप्ट में एक विदेशी कुंजी रिकॉर्ड पर निर्भर करता है लेकिन अभी तक नहीं चलता है) इसमें समय 'tweak' करने में समय लगता है यह आसानी से भाग गया।
5. यह निरंतर एकीकरण के लिए आदर्श परिदृश्य नहीं है।

तो समाधान था: -

1. डेटाबेस में सभी परिवर्तन करने की नीति लागू की पटकथा लिखी जानी चाहिए।
2. स्क्रिप्ट के सही चल रहे क्रम को सुनिश्चित करने के लिए एक नामकरण सम्मेलन महत्वपूर्ण था।
3. रिलीज समय पर स्क्रिप्ट चलाने के लिए टूल बनाएं/उपयोग करें।
4. डेवलपर्स डेटाबेस की अपनी कॉपी को था के खिलाफ विकसित करना (ताकि वहाँ कोई और अधिक 'एक दूसरे के पैर की उंगलियों पर कदम' था)

अगली फिल्म के बाद हम शुरू कर दिया इस प्रक्रिया को वास्तव में कम समस्याओं के साथ बहुत तेजी से किया गया था, पाए गए एकमात्र समस्याएं लोगों के नियमों को तोड़ने के कारण थीं, उदाहरण के लिए एक स्क्रिप्ट नहीं बनाना।

एक बार क्यूए को जारी करने के साथ मुद्दों को ठीक कर दिया गया, जब उत्पादन में रिलीज करने का समय आया तो यह बहुत ही आसान था।

हमने कुछ अन्य परिवर्तनों को लागू किया (जैसे सीआई शुरू करना) लेकिन यह सबसे महत्वपूर्ण था, कुल मिलाकर हमने लगभग 3 घंटे से अधिकतम 10-15 मिनट तक रिहाई का समय घटा दिया।

Answer 1

अपने जारी प्रक्रिया को स्वचालित जहाँ संभव।

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

यह

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

और इतने पर। इंस्टॉलर बिल्ड यह सब एक इंस्टॉल करने योग्य पैकेज (इंस्टालशील्ड, ज़िप, आरपीएम या जो कुछ भी) में रख सकता है और यहां तक ​​कि भौतिक वितरण के लिए सीडी आईएसओ भी बना सकता है।

इंस्टॉलर बिल्ड का उत्पादन आम तौर पर परीक्षण विभाग को सौंप दिया जाता है। जो कुछ भी स्थापना पैकेज में शामिल नहीं है (स्थापना के शीर्ष पर पैच ...) एक बग है। एक दोष मुक्त स्थापना प्रक्रिया देने के लिए अपने देवताओं को चुनौती दें।

Answer 2

स्वचालित एकल चरण निर्माण। चींटी बिल्ड स्क्रिप्ट सभी इंस्टॉलर कॉन्फ़िगरेशन फ़ाइलों को संपादित करता है, प्रोग्राम फ़ाइलों को बदलने की आवश्यकता होती है (संस्करण) और फिर बनाता है। कोई हस्तक्षेप की आवश्यकता नहीं है।

इंस्टॉल होने पर इंस्टॉलर उत्पन्न करने के लिए अभी भी एक स्क्रिप्ट चल रही है, लेकिन हम इसे खत्म कर देंगे।

सीडी आर्टवर्क मैन्युअल रूप से संस्करणित है; कि भी तय की जरूरत है।

Answer 3

हमने पिछले साल या तो हमारी निर्माण प्रक्रिया में सुधार करने के लिए कुछ चीजें की हैं।

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

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

3. शाखा मालिक। एक बार जब हमने रिलीज शाखा बनाने के लिए हमारे कोड को ब्रांच किया है और फिर निम्नलिखित रिलीज के लिए ट्रंक पर काम करना जारी रखा है, तो हम शाखा में लागू सभी फिक्सेस को सत्यापित करने के लिए जिम्मेदार एक एकल घूर्णन रिलीज शाखा मालिक असाइन करते हैं। आकार के बावजूद प्रत्येक एकल चेक-इन की समीक्षा दो देवताओं द्वारा की जानी चाहिए।

Answer 4

हम पहले से ही TeamCity (एक उत्कृष्ट सतत एकीकरण उपकरण) का उपयोग कर रहे थे करने के लिए हमारी बनाता है, जो इकाई परीक्षण शामिल थे। तीन बड़े सुधार का उल्लेख कर रहे थे थे:

1) स्थापित किट और एक क्लिक UAT तैनाती

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

यह हमारे परीक्षकों को यूएटी तैनाती करने की इजाजत देता है, जब तक कि उनमें डेटाबेस परिवर्तन नहीं होते - लेकिन वे कोड परिवर्तनों से बहुत दुर्लभ थे।

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

2) डेटाबेस की तैनाती

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

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

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

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

3) एक रिलीज

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

Answer 5

पिछली टिप्पणियों के साथ सहमत हैं।

यहां विकसित किया गया है जहां मैं काम करता हूं। इस वर्तमान प्रक्रिया ने आपके प्रश्न में वर्णित 'गॉथचास' को समाप्त कर दिया है।

हम एसएनएन (टैग संस्करण द्वारा) से कोड खींचने के लिए चींटी का उपयोग करते हैं और निर्भरताओं में खींचते हैं और परियोजना (और कभी-कभी तैनात करने के लिए) भी बनाते हैं।

प्रत्येक एंटी (देव, एकीकरण, परीक्षण, प्रोड) के लिए समान चींटी स्क्रिप्ट (पासिंग पैरा) का उपयोग किया जाता है।

परियोजना प्रक्रिया

• उपयोगकर्ता की कहानियों 'के रूप में आवश्यकताओं कैप्चरिंग (एक आवश्यकता की एक व्याख्या से अधिक quibbling से बचने में मदद करता है, जब उत्पाद के साथ एक सार्थक उपयोगकर्ता संपर्क के रूप में phrased)
• एक चंचल सिद्धांतों का अनुसरण ताकि प्रोजेक्ट के प्रत्येक पुनरावृत्ति (2 विकें) के परिणामस्वरूप वर्तमान कार्यक्षमता के डेमो और एक रिलीज करने योग्य, उत्पाद
• पूरे प्रोजेक्ट में रिलीज कहानियां प्रबंधित करें ताकि यह समझ सके कि स्कोप में और बाहर क्या है (और भ्रम को रोकने के लिए अंतिम मील Nute फिक्स)
• (पिछले प्रतिक्रिया के दोहराने) कोड फ्रीज, तो केवल परीक्षण (कोई अतिरिक्त सुविधाएँ)

देव प्रक्रिया

• इकाई
• कोड चेकइन
• अनुसूचित परीक्षण स्वचालित निर्माण (उदाहरण के लिए क्रूज नियंत्रण)
• एकीकरण वातावरण में एक बिल्ड/तैनाती को पूरा करें, और रन धूम्रपान परीक्षण
• टैग कोड और टीम के लिए (परीक्षण के लिए और योजना जारी)
  • कार्यात्मक परीक्षण संवाद

  टेस्ट प्रक्रिया (सेलेनियम, उदाहरण के लिए)

• परीक्षण की योजना को क्रियान्वित करने और कार्यात्मक परिदृश्य

एक व्यक्ति रिलीज प्रक्रिया का प्रबंधन करता है, और ens सभी का पालन करता है। इसके अतिरिक्त सभी रिलीज की समीक्षा लॉन्च से एक हफ्ते पहले की जाती है।विज्ञप्ति केवल अनुमोदित कर रहे हैं देखते हैं:

रिलीज प्रक्रिया

• एक विशिष्ट तिथि के लिए विज्ञप्ति जारी की स्वीकृति दें/समय
• समीक्षा रिहाई/रोलबैक योजना
'उत्पादन तैनाती' पैरामीटर साथ
• रन चींटी
• डीबी कार्यों को निष्पादित करें (यदि कोई है) (भी, ये स्क्रिप्ट संस्करण हो सकती हैं और उत्पादन के लिए टैग की जा सकती हैं)
• अन्य सिस्टम परिवर्तन/सी निष्पादित करें onfigs
• संवाद बदल जाता

Answer 6

मैं नहीं पता है या SDLC अभ्यास, लेकिन मेरे लिए, इन उपकरणों चिकनी विज्ञप्ति को प्राप्त करने में अपरिहार्य किया गया है: निर्माण के लिए

• Maven, Nexus स्थानीय भंडार प्रबंधक के साथ
• निरंतर एकीकरण के लिए हडसन, रिलीज बिल्ड, एससीएम टैगिंग और पदोन्नति
• गुणवत्ता मेट्रिक्स के लिए सोनार।
• विकास डाटाबेस स्कीमा के ट्रैकिंग डेटाबेस में परिवर्तन और गुणवत्ता आश्वासन के लिए प्रबंध अद्यतन और जारी DbMaintain के माध्यम से और LiquiBase

Answer 7

एक परियोजना पर जहां मैं काम करता हूं हम डेटाबेस को अपग्रेड और डाउनग्रेड करने के लिए डॉक्टरेट (PHP ORM) माइग्रेशन का उपयोग कर रहे थे।हमारे पास सभी प्रकार की समस्याएं थीं क्योंकि जेनरेट किए गए मॉडल अब डेटाबेस स्कीमा से मेल नहीं खाते हैं जिससे माइग्रेशन आधे रास्ते में पूरी तरह असफल हो जाते हैं।

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

मुझे लगता है कि कहानी की नैतिकता यह है कि कभी-कभी पहिया को फिर से शुरू करने के लिए ठीक है जब तक आप एक अच्छे कारण से ऐसा कर रहे हों।