पृष्ठभूमि

मैं एक टीम में काम कर रहा हूँ जो शून्य-डाउनटाइम परिनियोजन लागू करना चाहती है। हम इसे प्राप्त करने के लिए एक नीली / हरी परिनियोजन रणनीति का उपयोग करने की योजना बना रहे हैं। अनुसंधान करने में मुझे जो चीजें महसूस हो रही हैं, उनमें से एक यह है कि डेटाबेस में बदलाव करना कितना जटिल है। एक कॉलम का नाम बदलने जैसा एक सरल ऑपरेशन पूरा होने तक 3 पूर्ण रिलीज साइकिल ले सकता है !

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

मैं जिस चीज़ की तलाश कर रहा हूँ

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

मैं जिस चीज की तलाश कर रहा हूं, वह एक ऐसा तरीका है जिससे TODO टिप्पणी में इसके खिलाफ समय सीमा हो सकती है, और हमारी सतत एकीकरण प्रणाली (वर्तमान में जो हम उपयोग करेंगे) वह निर्माण को अस्वीकार कर देगी यदि यह समय सीमा समाप्त हो गई थी।

उदाहरण के लिए, यदि हम एक कॉलम का नाम बदल देते हैं, तो हम इसके लिए प्रारंभिक माइग्रेशन बना सकते हैं, और फिर दो TODO टिप्पणियां यह सुनिश्चित करने के लिए कि शेष दो माइग्रेशन बनाए गए हैं:

// TODO by v55: Create migration to move constraints to new column, remove references to old column in app
// TODO by v56: Create migration to drop old column

यह लागू करने के लिए काफी सरल लगता है, लेकिन मैं सोच रहा हूं कि क्या ऐसा कुछ पहले से मौजूद है, क्योंकि मैं पहिया का फिर से आविष्कार नहीं करना चाहता हूं।

अतिरिक्त विचार

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

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

— जोशुआ वॉल्श
स्रोत

19

TODO मुद्दा टूलिंग से अधिक अनुशासन का विषय है।

— ब्रैंडन

16

मुझे लगता है कि मनुष्य सभी गलतियाँ करते हैं, और टूलींग इस को कम करने का एक अच्छा तरीका हो सकता है।

— जोशुआ वाल्श

1

मत blog.schauderhaft.de/2014/02/16/your-code-aint-your-to-do-list

— जेन्स Schauder

3

इस कार्यक्रम को पसंद करने के बारे में क्या। मेरा मतलब है कि एक वर्ग के सदस्य अपने संस्करण में लिखें। यदि संस्करण बराबर है तो एप्लिकेशन को प्रारंभ करने में विफल होने पर == 56 संदेश "क्लास y" के साथ इस सुविधा के लिए आपके पास ऐसे संदेशों की एक सूची हो सकती है। तुम क्या सोचते हो?

— तोमर बेन डेविड

6

नाय-कहने वालों के निर्देशन में, मैं असहमत हूं: हमारा कोड आधार बहुत सारे अन्य घटकों पर निर्भर करता है जिन पर हम काम नहीं करते हैं, इसलिए हम TODO <Bug#>:अन्य घटकों के साथ समस्याओं के लिए वर्कअराउंड को ट्रैक करने के लिए उपयोग करते हैं। जब उन घटकों में से एक पर एक बग साफ हो जाता है, तो आप आसानी से संबंधित वर्कअराउंड को ढूंढ और संबोधित कर सकते हैं। यह एक समस्या ट्रैकर को प्रतिस्थापित नहीं करता है, यह बनाए रखना आसान बनाता है।

— टेम्पोरलवुल्फ

53

यह प्रश्न वास्तव में एक में दो प्रश्न हैं।

टोडो टिप्पणी

कार्रवाई आइटम को ट्रैक करने के सभी तरीकों में से, यह सबसे खराब है। TODO टिप्पणियां सक्रिय कार्य के दौरान या एक अनुचर को सुझाव देने के तरीके के रूप में अच्छी हैं, "यहां कुछ ऐसा है जिसे भविष्य में बेहतर किया जा सकता है"। लेकिन अगर आप काम करने के लिए TODO टिप्पणियों पर भरोसा करते हैं, तो आप असफल होने के लिए बर्बाद हैं।

इसके बारे में क्या करना है

TODO टिप्पणियां मूल रूप से तकनीकी ऋण हैं, इसलिए उन्हें किसी अन्य तकनीकी ऋण की तरह संभाला जाना चाहिए। या तो उन्हें तुरंत निपटाएं, अगर आपके पास समय है, या उन्हें बैकलॉग में डाल दें ताकि उन्हें ट्रैक किया जा सके और प्राथमिकता दी जा सके।

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

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

डेटाबेस बदलता है

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

पोस्ट-पोस्टिंग प्रक्रिया

पोस्ट-परिनियोजन प्रक्रिया बनाएँ जो समान रिलीज़ के भाग के रूप में चलती है। हालाँकि आप चाहते हैं कि यह काम करे। मैंने जिस आखिरी सिस्टम पर काम किया, उसमें मैंने 4-चरण की तैनाती को डिजाइन किया था:

उपदेश डेटाबेस स्क्रिप्ट
वेब ऐप्स
डेटाबेस स्क्रिप्ट पोस्ट करें
रखरखाव विंडो डेटाबेस स्क्रिप्ट

यह विचार था कि जहाँ भी संभव हो, हम डेटाबेस के परिवर्तनों को यथासंभव प्रचार में डालेंगे।

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

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

बार-बार तैनात करना

यदि आप बार-बार नए रिलीज़ परिनियोजित करते हैं, तो आप एक ऐसे बिंदु पर पहुँच सकते हैं जहाँ 2 या 3 रिलीज़ में परिवर्तन करना तुच्छ है। लंबे समय से जारी चक्र डेटाबेस परिवर्तनों की लागत को बढ़ाते हैं।

— ब्रैंडन
स्रोत

18

टोडो टिप्पणियां काम को ट्रैक करने और प्राथमिकता देने का एक भयानक तरीका हैं। वे यह समझाने का एक वैध तरीका है कि हवा में आधा भरा हुआ कोड क्यों फड़फड़ा रहा है। एक आदर्श दुनिया में कोई भी कोड कभी भी ऐसा नहीं करता है। इस बीच, इस एक में ...

— कैंडिड_ऑरेंज

6

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

— कैंडिड_ऑरेंज

3

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

— जोशुआ वाल्श

3

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

— प्लाज्माएचएच

6

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

— डॉक ब्राउन

24

TODOs का उपयोग न करें। आपके पास पहले से ही अपने प्रोजेक्ट में TODO सूची है। इसे इश्यू ट्रैकर कहा जाता है।

मुझे लगता है कि वास्तविक समस्या इस वाक्य में है:

हम अपनी समस्या प्रबंधन प्रणाली में एक टिकट बना सकते हैं, जो अव्यवस्था पैदा करता है और प्रबंधन द्वारा बाद में स्प्रिंट या बैकलॉग में स्थानांतरित हो सकता है।

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

यदि आपका प्रबंधन किसी कार्य के अंतिम भाग को कम करता है, तो आपके पास दो विकल्प हैं:

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

— जेन्स स्काउडर
स्रोत

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

— जोशुआ वाल्श

11

यह फ़ॉर्म की टिप्पणियों के लिए पूरी तरह से उचित है // TODO(#12345): Frobnicate the sprocket before passing it along, बशर्ते कि बग # 12345 एक "वास्तविक" अंक संख्या है और समस्या किसी को सौंपी गई है। यह स्पष्ट करके स्रोत को पढ़ने में आसान बनाता है: "नहीं, फ्रॉबनेट कदम सहायक विधियों में से एक में छिपा नहीं है, यह सिर्फ फ्लैट-आउट अनिमित है। अधिक संदर्भ के लिए बग # 12345 पर देखें।" आदर्श रूप से, आपके पास कोडबेस पर एक दैनिक लिंटर रन होगा जो निश्चित रूप से बंद या अमान्य अंक संख्याओं की तलाश में है।

— केविन

9

मैं जिस चीज की तलाश कर रहा हूं, वह एक ऐसा तरीका है जिससे TODO टिप्पणी में इसके खिलाफ समय सीमा हो सकती है, और हमारी सतत एकीकरण प्रणाली (वर्तमान में जो हम उपयोग करेंगे) वह निर्माण को अस्वीकार कर देगी यदि यह समय सीमा समाप्त हो गई थी।

यदि आप काम करने को तैयार हैं और आपका अनुसरण करने के लिए तैयार हैं, तो आपके लिए क्या करना उचित है।

// TODO by v55: नए कॉलम में बाधाओं को स्थानांतरित करने के लिए माइग्रेशन बनाएं, ऐप में पुराने कॉलम के संदर्भ हटा दें // TODO द्वारा v56: पुराने कॉलम को छोड़ने के लिए माइग्रेशन बनाएं

//TODO by v55g55 के लिए जब यह v55 को तैनात करने का समय है। डिप्लॉय बिल्ड एक स्क्रिप्ट चलाता है जो एकीकरण परीक्षण के रूप में करता है।

आप अपने संस्करण ट्रैकिंग में 55 बाँध सकते हैं या बस इसके लिए संकेत दे सकते हैं।

यह दिलचस्प हो जाता है यदि आप // TODO के लिए v54 द्वारा 55 के लिए जाँच करना चाहते हैं। बल्कि कोड कोड को 55 बार खोजें // TODO द्वारा खोजें। फिर 1 से 55 के परिणाम के लिए फ़िल्टर करें। अब 56 एक असफल ट्रिगर नहीं होगा।

आप सोच सकते हैं "ओह हमें इसकी आवश्यकता नहीं है। जब तक हमारे पास चेक है, तब तक हम हर बार इन्हें ठीक करेंगे।" नहीं, आप नहीं करेंगे।

— candied_orange
स्रोत

4

अगर ऐसा होता है तो हम यहां सिफारिशें नहीं करते हैं।

— कैंडिड_ऑरेंज

3

यदि इस तरह की चीज़ के लिए एक सामान्य नाम है, जो प्रदान किया जा सकता है, लेकिन यदि आप उस पृष्ठ को पढ़ते हैं जिसे आपने सिफारिशों के बारे में बताया है, तो आपको इस बारे में बताया जाएगा: softwareengineering.meta.stackexchange.com/a/6487/131624

— cand__ange

6

स्पष्ट होने के लिए, यह आपकी टिप्पणी है कि मैं पूरे प्रश्न के बजाय आपत्ति कर रहा हूं।

— कैंडिड_ऑरेंज

2

@YM_Indenders SE साइटें स्वयं समाहित करती हैं, अनुशंसाएँ मूल रूप से बाहरी साइटों के लिंक के साथ सरल उत्तर हैं, या आपको लिंक के बजाय इसे Google में आमंत्रित करना है लेकिन यह अंत में समान है। वे समाप्त हो सकते हैं और मृत हो सकते हैं। तो सिफारिश के बारे में एक सवाल ऑफ-टॉपिक है, हालांकि कोई व्यक्ति किसी टूल का जवाब या सरल टिप्पणी के पूरक के रूप में उल्लेख करना चाहता है, वह ऐसा कर सकता है।

— वालफ्रैट

2

"मैं सोच रहा था कि क्या कोई मौजूदा समाधान मौजूद है" - हमें सॉफ्टवेअरसेकस्टैक्सएक्सचेंज

— डॉट कॉम

4

हमें अपनी टीम में एक समान समस्या थी। इसे हल करने के लिए हमने एक स्थैतिक विश्लेषण जांच लिखी जो कि इन TODO को JIRA मुद्दे या Git समस्या की जाँच करके बताती है कि वे संदर्भ देते हैं। जब निर्दिष्ट समस्या "इन डेवलपमेंट" कॉलम से आगे बढ़ती है तो हमारा निर्माण विफल हो जाता है।

इसलिए हम आराम से TODO के बारे में चिंता किए बिना उन्हें भूल जाने के बारे में बता सकते हैं।

मैंने जावा में इसका एक ओपन-सोर्स कार्यान्वयन बनाया। हां, एक अस्वीकरण यह है कि मैंने यह लिखा था, लेकिन जैसा मैंने कहा कि यह पूरी तरह से खुला और लाइसेंस प्राप्त है।

उपकरण को वेस्टी कहा जाता है और जीएआरए मुद्दा परीक्षक का एक उदाहरण README.md पर है। GitIssueAnalyser भी देखें।

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

— tjheslin1
स्रोत

1

यह अच्छा है! हम JIRA का भी उपयोग करते हैं, मैं इसका उपयोग कर सकता हूं। यह वास्तव में हमारे मुद्दे-प्रबंधन प्रणाली में अव्यवस्था पैदा करने के बारे में मेरी चिंताओं को हल नहीं करता है, लेकिन कम से कम यह गारंटी देगा कि उन्हें भुलाया नहीं जा सकता है।

— जोशुआ वाल्श

@YM_Indenders मुझे खुशी है। मुझे कोई योगदान स्वीकार करने या उठाए गए मुद्दों पर काम करने में खुशी होगी।

— tjheslin1

4

ToDo मत करो। अभी करो।

TLDR: लिखें और (परीक्षण) अपनी DB स्क्रिप्ट अभी, बाद में नहीं; बस उन्हें कोड दें ताकि उनका निष्पादन DB संस्करण पर आकस्मिक हो।

उदाहरण

एक उदाहरण के लिए, मान लें कि आप से एक स्तंभ नाम बदलना चाहते हैं जाने SSNके लिए TaxIDजब अंतरराष्ट्रीय जा रहा है, एक आम आवश्यकता।

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

हमारे उदाहरण में, हम 101 का निर्माण करते हुए संगतता बनाए रखेंगे, जिसमें 102 का निर्माण (जिसमें नया कॉलम होगा)।

यहाँ कदम हैं।

1. वर्जनिंग टेबल सेट करें

Configurationदो स्तंभों के साथ एक एकल तालिका जोड़ें , Nameऔर Value।
Name"TargetVersion" के साथ एक पंक्ति जोड़ें और Valueतैनात किए जाने वाले नए बिल्ड के संस्करण पर सेट करें ।
Name"संगत" के साथ एक पंक्ति जोड़ें और Valueन्यूनतम संस्करण संख्या निर्धारित करें जिसके साथ तैनाती संगत होनी चाहिए।

हर तैनाती से पहले इन पंक्तियों का निरीक्षण और अद्यतन करें।

2. परिनियोजन स्क्रिप्ट को संशोधित करें

एक स्क्रिप्ट जोड़ें, जो एक नया कॉलम बनाता है TaxID, जिसके साथ कंधे से कंधा मिलाकर SSN, उसे SSNकॉलम से पॉप्युलेट करता है । इस कोड को एक Ifकथन में संलग्न करें जो टारगेटवर्जन की जाँच करता है; यदि लक्ष्य संस्करण बहुत कम है (अर्थात TaxIDअभी तक आवश्यक नहीं है), छोड़ें।
```
SELECT @TargetVersion = TargetVersion FROM Configuration
IF @TargetVersion < '102' THEN RETURN
ALTER TABLE Customer ADD COLUMN taxID VarChar(12) NOT NULL
UPDATE Customer SET TaxID = SSN
```
एक स्क्रिप्ट जोड़ें जो एक ट्रिगर बनाता है जो TaxIDडालने या अपडेट करने SSNऔर इसके विपरीत पॉप्युलेट करता है । इस कोड को एक Ifबयान में संलग्न करें जो लक्ष्य संस्करण और संगत संस्करण की जांच करता है; छोड़ें अगर TargetVersion बहुत कम है ( TaxIDआवश्यक नहीं है) या यदि संगत संस्करण बहुत अधिक है ( SSNफ़ील्ड की आवश्यकता नहीं है)।
```
SELECT @TargetVersion  = TargetVersion,
       @CompatibleWith = CompatibleWith 
FROM Configuration
IF @TargetVersion  < '102' THEN RETURN
IF @CompatibleWith > '101' THEN RETURN
CREATE TRIGGER SSNAndTaxIDTrigger ON Customer etc.
```
SSNकॉलम हटाने के लिए एक स्क्रिप्ट जोड़ें । एक Ifकथन में संलग्न करें जो कॉलम को केवल तभी निकालता है जब कम्पेटिबल वर्थ पर्याप्त रूप से पर्याप्त हो (जिसकी SSNअब आवश्यकता नहीं है)।
```
SELECT @CompatibleWith = CompatibleWith FROM Configuration
IF @CompatibleWith <= '101' THEN RETURN
IF OBJECT_ID('SSNAndTaxIDTrigger') IS NOT NULL DROP TRIGGER SSNAndTaxIDTrigger
IF EXISTS (SELECT * FROM syscolumns c JOIN sysobject o ON o.id = c.is WHERE o.Name = 'Custeomr' AND c.Name = 'SSN') BEGIN
    ALTER TABLE Customer DROP COLUMN SSN
END
```

3. परीक्षण

ब्लू / ग्रीन संस्करण संख्या के किसी भी संयोजन के साथ अपनी तैनाती का परीक्षण करना सुनिश्चित करें जो आप उत्पादन में समर्थन करने में सक्षम होना चाहते हैं। Configurationअपने QA वातावरण में तालिका में हेरफेर करके, कोड तैयार होते ही आप परीक्षण कर सकते हैं।

4. आपकी तैनाती प्लेबुक में

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

नुकसान

आपकी तैनाती लिपियों के लिए यह ठीक है कि उस DB तालिका में उन संस्करण संख्याओं को संदर्भित करें और उन पर निर्भर रहें। रनटाइम कोड नहीं।

यदि आप संस्करण संख्याओं का निरीक्षण करने के लिए अपना रनटाइम कोड लिखना शुरू करते हैं, तो आप अपने आवेदन में जटिलता का एक नया स्तर पेश कर रहे हैं जो संभवतः एक बड़ी स्थिरता समस्या बन सकती है। प्रत्येक रनटाइम निष्पादन पथ का परीक्षण किया जाना चाहिए; यदि आप इन स्थितियों को आगे बढ़ाते हैं, तो QA को प्रत्येक रिलीज़ के साथ उन्हें सत्यापित करने के लिए दर्द का एक मैट्रिक्स रखना होगा । मेरी सलाह है कि इस तरह की स्थितियों को केवल तैनाती लिपियों में रखें।

इस सब का नतीजा

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

इस तरह से आप सभी कोड को सामने से लिख और परीक्षण कर सकते हैं, जब आप इसके बारे में सोच रहे होते हैं, और आपको उन गंदे टॉड टिप्पणियों से निपटने की आवश्यकता नहीं होती है।

— जॉन वू
स्रोत

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

— जोशुआ वाल्श

1

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

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

— Eternal21
स्रोत

1

हां, मैं आदर्श रूप से एक समाप्त हो चुके TODO को एक असफल परीक्षण के रूप में मानने की उम्मीद कर रहा था। TODOs के खिलाफ पुशबैक की मात्रा ने मुझे थोड़ा आश्चर्यचकित किया है, मुझे पता है कि वे एक मुद्दे प्रबंधन प्रणाली का विकल्प नहीं हैं, लेकिन TDD / BDD की व्यापकता को देखते हुए यह स्पष्ट है कि कोड में आवश्यकताओं को परिभाषित करने और कोड का उपयोग करने के लिए कोई वास्तविक समस्या नहीं है सुविधा पूर्ण।

— जोशुआ वाल्श

-2

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

— mpiazza
स्रोत

1

नीले / हरे रंग की तैनाती में डेटाबेस की पुनरावृत्ति करने से बहुत अधिक सिरदर्द होता है। जब मेरे ठेस env कहीं नीले और हरे रंग के बीच होते हैं, (प्रत्येक के लिए 50% भार वितरित किया जाता है, उदाहरण के लिए) मुझे प्रतिकृति कोड को दोनों डेटाबेस को सिंक में रखने की आवश्यकता होती है, भले ही उनका स्कीमा अलग हो। मैंने जो शोध किया है उससे लगता है कि वास्तविक दुनिया के अधिकांश लोगों के पास अपने नीले और हरे रंग के ढेर के बीच एक साझा DB उदाहरण है। मैं इसे एक प्रमुख मुद्दे के रूप में नहीं देखता हूं जब तक कि डेटाबेस माइग्रेशन काफी तेज हो। नीले / हरे रंग के ढेर को स्वाभाविक रूप से कुछ संसाधनों को साझा करने की आवश्यकता होती है, बहुत कम से कम लोड बैलेंसर / रिवर्स प्रॉक्सी।

— जोशुआ वाल्श

TODO की समय सीमा के साथ टिप्पणी?

पृष्ठभूमि

मैं जिस चीज़ की तलाश कर रहा हूँ

अतिरिक्त विचार

टोडो टिप्पणी

डेटाबेस बदलता है

ToDo मत करो। अभी करो।