एक सतत एकीकरण डैशबोर्ड का समर्थन करने के लिए जो स्केलेबल, परफॉर्मेंट और लचीला है, वीटीएस डैशबोर्ड बैकएंड को डेटाबेस कार्यक्षमता की मजबूत समझ के साथ सावधानीपूर्वक डिजाइन किया जाना चाहिए। Google क्लाउड डेटास्टोर एक NoSQL डेटाबेस है जो लेनदेन संबंधी ACID गारंटी और अंतिम स्थिरता के साथ-साथ इकाई समूहों के भीतर मजबूत स्थिरता प्रदान करता है। हालाँकि, संरचना SQLडेटाबेस (और यहां तक कि क्लाउड बिगटेबल) से बहुत अलग है; तालिकाओं, पंक्तियों और कोशिकाओं के बजाय प्रकार, इकाइयाँ और गुण हैं।
निम्नलिखित अनुभाग वीटीएस डैशबोर्ड वेब सेवा के लिए एक प्रभावी बैकएंड बनाने के लिए डेटा संरचना और क्वेरी पैटर्न की रूपरेखा तैयार करते हैं।
इकाइयां,
निम्नलिखित इकाइयाँ VTS परीक्षण रन से सारांश और संसाधन संग्रहीत करती हैं:
- परीक्षण इकाई . किसी विशेष परीक्षण के परीक्षण रन के बारे में मेटाडेटा संग्रहीत करता है। इसकी कुंजी परीक्षण का नाम है और इसके गुणों में विफलता की गिनती, पासिंग की गिनती और अलर्ट जॉब्स द्वारा इसे अपडेट करने के समय से टेस्ट केस के टूटने की सूची शामिल है।
- टेस्ट रन एंटिटी । किसी विशेष परीक्षण के रन से मेटाडेटा शामिल है। इसमें परीक्षण प्रारंभ और समाप्ति टाइमस्टैम्प, परीक्षण बिल्ड आईडी, उत्तीर्ण और असफल परीक्षण मामलों की संख्या, रन का प्रकार (उदाहरण के लिए प्री-सबमिट, पोस्ट-सबमिट, या स्थानीय), लॉग लिंक की एक सूची, होस्ट को संग्रहीत करना होगा। मशीन का नाम, और कवरेज सारांश मायने रखता है।
- डिवाइस सूचना इकाई . इसमें परीक्षण के दौरान उपयोग किए गए उपकरणों के बारे में विवरण शामिल हैं। इसमें डिवाइस बिल्ड आईडी, उत्पाद का नाम, बिल्ड लक्ष्य, शाखा और एबीआई जानकारी शामिल है। इसे एक-से-अनेक तरीके से मल्टी-डिवाइस टेस्ट रन का समर्थन करने के लिए टेस्ट रन इकाई से अलग से संग्रहीत किया जाता है।
- प्रोफाइलिंग प्वाइंट रन एंटिटी । परीक्षण चलाने के दौरान किसी विशेष प्रोफ़ाइलिंग बिंदु के लिए एकत्र किए गए डेटा का सारांश प्रस्तुत करता है। यह प्रोफाइलिंग डेटा के अक्ष लेबल, प्रोफाइलिंग बिंदु नाम, मान, प्रकार और प्रतिगमन मोड का वर्णन करता है।
- कवरेज इकाई . एक फ़ाइल के लिए एकत्रित कवरेज डेटा का वर्णन करता है। इसमें Git प्रोजेक्ट जानकारी, फ़ाइल पथ और स्रोत फ़ाइल में प्रति पंक्ति कवरेज गणना की सूची शामिल है।
- टेस्ट केस रन एंटिटी । टेस्ट रन से किसी विशेष टेस्ट केस के परिणाम का वर्णन करता है, जिसमें टेस्ट केस का नाम और उसका परिणाम भी शामिल है।
- उपयोगकर्ता की पसंदीदा इकाई . प्रत्येक उपयोगकर्ता सदस्यता को एक इकाई में दर्शाया जा सकता है जिसमें परीक्षण का संदर्भ और ऐप इंजन उपयोगकर्ता सेवा से उत्पन्न उपयोगकर्ता आईडी शामिल है। यह कुशल द्वि-दिशात्मक पूछताछ की अनुमति देता है (अर्थात एक परीक्षण के लिए सदस्यता लेने वाले सभी उपयोगकर्ताओं के लिए और एक उपयोगकर्ता द्वारा पसंदीदा सभी परीक्षणों के लिए)।
इकाई समूहन
प्रत्येक परीक्षण मॉड्यूल एक इकाई समूह की जड़ का प्रतिनिधित्व करता है। टेस्ट रन इकाइयां इस समूह के बच्चे और डिवाइस इकाइयों, प्रोफाइलिंग पॉइंट इकाइयों और संबंधित परीक्षण और टेस्ट रन पूर्वजों से संबंधित कवरेज इकाइयों के माता-पिता दोनों हैं।
मुख्य बिंदु: वंश संबंधों को डिज़ाइन करते समय, आपको डेटाबेस द्वारा लागू सीमाओं के विरुद्ध प्रभावी और सुसंगत क्वेरी तंत्र प्रदान करने की आवश्यकता को संतुलित करना होगा।
फ़ायदे
स्थिरता की आवश्यकता यह सुनिश्चित करती है कि भविष्य के संचालन में लेनदेन के प्रभाव तब तक दिखाई नहीं देंगे जब तक कि यह प्रतिबद्ध न हो जाए, और अतीत में लेनदेन वर्तमान संचालन में दिखाई दे। क्लाउड डेटास्टोर में, इकाई समूहन समूह के भीतर मजबूत पढ़ने और लिखने की स्थिरता के द्वीप बनाता है, जो इस मामले में परीक्षण मॉड्यूल से संबंधित सभी परीक्षण रन और डेटा है। यह निम्नलिखित लाभ प्रदान करता है:
- अलर्ट नौकरियों द्वारा परीक्षण मॉड्यूल स्थिति को पढ़ने और अपडेट करने को परमाणु माना जा सकता है
- परीक्षण मॉड्यूल के भीतर परीक्षण मामले के परिणामों के लगातार दृश्य की गारंटी
- वंश वृक्षों के भीतर तेज़ पूछताछ
सीमाएँ
किसी इकाई समूह को प्रति सेकंड एक इकाई से अधिक तेज़ गति से लिखने की सलाह नहीं दी जाती है क्योंकि कुछ लेखन को अस्वीकार किया जा सकता है। जब तक अलर्ट कार्य और अपलोडिंग प्रति सेकंड एक लेखन से तेज गति से नहीं होती है, तब तक संरचना ठोस है और मजबूत स्थिरता की गारंटी देती है।
अंततः, प्रति परीक्षण मॉड्यूल प्रति सेकंड एक लिखने की सीमा उचित है क्योंकि परीक्षण चलाने में आमतौर पर वीटीएस ढांचे के ओवरहेड सहित कम से कम एक मिनट लगता है; जब तक एक परीक्षण लगातार 60 से अधिक विभिन्न होस्टों पर एक साथ निष्पादित नहीं किया जा रहा है, तब तक कोई लेखन बाधा नहीं हो सकती है। यह और भी असंभावित हो जाता है क्योंकि प्रत्येक मॉड्यूल एक परीक्षण योजना का हिस्सा है जिसमें अक्सर एक घंटे से अधिक समय लगता है। यदि होस्ट एक ही समय में परीक्षण चलाते हैं, तो विसंगतियों को आसानी से नियंत्रित किया जा सकता है, जिससे एक ही होस्ट पर लेखन की छोटी-छोटी घटनाएं हो सकती हैं (उदाहरण के लिए लेखन त्रुटियों को पकड़ना और फिर से प्रयास करना)।
स्केलिंग संबंधी विचार
एक परीक्षण चलाने के लिए आवश्यक नहीं है कि परीक्षण उसके माता-पिता के रूप में हो (उदाहरण के लिए इसमें कोई अन्य कुंजी हो सकती है और परीक्षण नाम, परीक्षण प्रारंभ समय गुण के रूप में हो सकता है); हालाँकि, यह अंतिम स्थिरता के लिए मजबूत स्थिरता का आदान-प्रदान करेगा। उदाहरण के लिए, अलर्ट जॉब एक परीक्षण मॉड्यूल के भीतर सबसे हालिया परीक्षण रन का परस्पर सुसंगत स्नैपशॉट नहीं देख सकता है, जिसका अर्थ है कि वैश्विक स्थिति परीक्षण रन के अनुक्रम का पूरी तरह से सटीक प्रतिनिधित्व नहीं कर सकती है। यह एकल परीक्षण मॉड्यूल के भीतर परीक्षण रन के प्रदर्शन को भी प्रभावित कर सकता है, जो जरूरी नहीं कि रन अनुक्रम का एक सुसंगत स्नैपशॉट हो। आख़िरकार स्नैपशॉट सुसंगत होगा, लेकिन इसकी कोई गारंटी नहीं है कि सबसे ताज़ा डेटा होगा।
परीक्षण के मामलों
एक अन्य संभावित बाधा कई परीक्षण मामलों के साथ बड़े परीक्षण हैं। दो ऑपरेटिव बाधाएं एक इकाई समूह के भीतर प्रति सेकंड एक के राइट थ्रूपुट के साथ-साथ 500 इकाइयों के अधिकतम लेनदेन आकार की हैं।
एक दृष्टिकोण एक परीक्षण मामले को निर्दिष्ट करना होगा जिसमें पूर्वज के रूप में परीक्षण चलाया गया हो (उसी तरह जैसे कवरेज डेटा, प्रोफाइलिंग डेटा और डिवाइस जानकारी संग्रहीत की जाती है):
हालांकि यह दृष्टिकोण परमाणुता और स्थिरता प्रदान करता है, यह परीक्षणों पर मजबूत सीमाएं लगाता है: यदि कोई लेनदेन 500 संस्थाओं तक सीमित है, तो एक परीक्षण में 498 से अधिक परीक्षण मामले नहीं हो सकते हैं (कोई कवरेज या प्रोफाइलिंग डेटा नहीं मानते हुए)। यदि कोई परीक्षण इससे अधिक होता है, तो एक एकल लेनदेन सभी परीक्षण मामले के परिणामों को एक साथ नहीं लिख सकता है, और परीक्षण मामलों को अलग-अलग लेनदेन में विभाजित करने से प्रति सेकंड एक पुनरावृत्ति के अधिकतम इकाई समूह लिखने के थ्रूपुट से अधिक हो सकता है। चूंकि यह समाधान प्रदर्शन से समझौता किए बिना अच्छी तरह से विकसित नहीं होगा, इसलिए इसकी अनुशंसा नहीं की जाती है।
हालाँकि, टेस्ट केस के परिणामों को टेस्ट रन के बच्चों के रूप में संग्रहीत करने के बजाय, टेस्ट केस को स्वतंत्र रूप से संग्रहीत किया जा सकता है और उनकी कुंजी टेस्ट रन के लिए प्रदान की जाती है (एक टेस्ट रन में इसके टेस्ट केस इकाइयों के पहचानकर्ताओं की एक सूची होती है):
पहली नज़र में, यह मजबूत निरंतरता की गारंटी को तोड़ता हुआ प्रतीत हो सकता है। हालाँकि, यदि क्लाइंट के पास एक टेस्ट रन इकाई और टेस्ट केस पहचानकर्ताओं की एक सूची है, तो उसे क्वेरी बनाने की आवश्यकता नहीं है; इसके बजाय यह सीधे उनके पहचानकर्ताओं द्वारा परीक्षण मामलों को प्राप्त कर सकता है, जो हमेशा सुसंगत होने की गारंटी है। यह दृष्टिकोण एक इकाई समूह के भीतर अत्यधिक लेखन की धमकी के बिना मजबूत स्थिरता प्राप्त करते समय परीक्षण चलाने वाले परीक्षण मामलों की संख्या पर बाधा को काफी हद तक कम कर देता है।
डेटा एक्सेस पैटर्न
वीटीएस डैशबोर्ड निम्नलिखित डेटा एक्सेस पैटर्न का उपयोग करता है:
- उपयोगकर्ता पसंदीदा . एक संपत्ति के रूप में विशेष ऐप इंजन उपयोगकर्ता ऑब्जेक्ट वाली उपयोगकर्ता पसंदीदा इकाइयों पर समानता फ़िल्टर का उपयोग करके पूछताछ की जा सकती है।
- परीक्षण सूची . परीक्षण इकाइयों की सरल क्वेरी. होम पेज को प्रस्तुत करने के लिए बैंडविड्थ को कम करने के लिए, उत्तीर्ण और असफल गणनाओं पर एक प्रक्षेपण का उपयोग किया जा सकता है ताकि असफल परीक्षण केस आईडी और चेतावनी नौकरियों द्वारा उपयोग किए जाने वाले अन्य मेटाडेटा की संभावित लंबी सूची को छोड़ा जा सके।
- परीक्षण चलता है . परीक्षण चलाने वाली इकाइयों के लिए क्वेरी करने के लिए कुंजी (टाइमस्टैम्प) पर एक प्रकार की आवश्यकता होती है और टेस्ट रन गुणों जैसे बिल्ड आईडी, पासिंग काउंट इत्यादि पर संभावित फ़िल्टरिंग की आवश्यकता होती है। परीक्षण इकाई कुंजी के साथ पूर्वज क्वेरी करने से, रीड दृढ़ता से सुसंगत होता है। इस बिंदु पर, टेस्ट रन प्रॉपर्टी में संग्रहीत आईडी की सूची का उपयोग करके सभी टेस्ट केस परिणाम प्राप्त किए जा सकते हैं; डेटास्टोर प्राप्त संचालन की प्रकृति के कारण यह भी दृढ़ता से सुसंगत परिणाम होने की गारंटी है।
- प्रोफ़ाइलिंग और कवरेज डेटा . किसी परीक्षण से जुड़े प्रोफाइलिंग या कवरेज डेटा के लिए पूछताछ किसी अन्य टेस्ट रन डेटा (जैसे अन्य प्रोफाइलिंग/कवरेज डेटा, टेस्ट केस डेटा इत्यादि) को पुनर्प्राप्त किए बिना भी की जा सकती है। परीक्षण परीक्षण और परीक्षण रन इकाई कुंजियों का उपयोग करके एक पूर्वज क्वेरी परीक्षण रन के दौरान दर्ज किए गए सभी प्रोफाइलिंग बिंदुओं को पुनः प्राप्त करेगी; प्रोफ़ाइलिंग बिंदु नाम या फ़ाइल नाम पर फ़िल्टर करके, एकल प्रोफ़ाइलिंग या कवरेज इकाई को पुनः प्राप्त किया जा सकता है। पूर्वज प्रश्नों की प्रकृति के कारण, यह ऑपरेशन दृढ़ता से सुसंगत है।
यूआई और इन डेटा पैटर्न के स्क्रीनशॉट के विवरण के लिए, वीटीएस डैशबोर्ड यूआई देखें।