Terraform 0.11 - Contributing to Terraform

टेराफॉर्म में योगदान देना




terraform

टेराफॉर्म में योगदान देना

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

हालांकि, आपको निम्नलिखित में से किसी में विशेषज्ञ होने की आवश्यकता नहीं है, ये ऐसी चीजें हैं जो आपके लिए उपयोगी हैं या जानना चाहते हैं:

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

HashiCorp बनाम सामुदायिक प्रदाता

हम प्रदाताओं को "हशीकोर्प प्रोवाइडर्स" और "कम्युनिटी प्रोवाइडर्स" के नाम से अलग करते हैं।

HashiCorp प्रदाता वे प्रदाता हैं जिन्हें हम सुधार करने के लिए पूर्णकालिक संसाधन समर्पित करेंगे, नवीनतम सुविधाओं का समर्थन करेंगे, और बग्स को ठीक करेंगे। ये ऐसे प्रदाता हैं जिन्हें हम गहराई से समझते हैं और आश्वस्त हैं कि हमारे पास खुद को प्रबंधित करने के लिए संसाधन हैं।

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

HashiCorp प्रदाताओं की वर्तमान सूची इस प्रकार है:

हमारे परीक्षण मानक HashiCorp और सामुदायिक प्रदाताओं दोनों के लिए समान हैं, और HashiCorp टेराफ़ॉर्म को स्थिर बनाए रखने के लिए हर प्रदाता के लिए पूरी तरह से स्वीकृति परीक्षण सूट चलाता है।

हम इन दो प्रकार के प्रदाताओं के बीच भेद करने में मदद करने के लिए सामुदायिक प्रयासों की विशाल मात्रा को उजागर करने में मदद करते हैं जो टेराफॉर्म को महान बनाते हैं, और योगदानकर्ताओं को बेहतर समझने में मदद करते हैं कि भूमिका बेस के विभिन्न क्षेत्रों में HashiCorp के कर्मचारी खेलते हैं।

मुद्दे

रिपोर्ट करने वाले चेकलिस्ट जारी करें

हम सुविधा अनुरोध, बग रिपोर्ट और सामान्य प्रश्नों सहित सभी प्रकार के मुद्दों का स्वागत करते हैं। टेराफॉर्म के लिए कोड और इश्यू ट्रैकर https://github.com/hashicorp/terraform । प्रत्येक आधिकारिक तौर पर समर्थित Terraform प्रदाता के पास Terraform Providers GitHub संगठन में अपना GitHub रिपॉजिटरी है।

नीचे आपको प्रत्येक प्रकार के सुव्यवस्थित मुद्दों के दिशानिर्देशों के साथ चेकलिस्ट मिलेंगे।

दोष रिपोर्ट

  • [] नवीनतम रिलीज के खिलाफ परीक्षण: सुनिश्चित करें कि आप नवीनतम जारी संस्करण के खिलाफ परीक्षण करें। यह संभव है कि हम पहले से ही आपके द्वारा अनुभव किए जा रहे बग को ठीक कर लें।

  • [] संभावित डुप्लिकेट रिपोर्टों की खोज करें : बग रिपोर्ट को एक थ्रेड में समेकित रखने में मददगार है, इसलिए किसी अन्य व्यक्ति द्वारा एक ही बात की सूचना देने के लिए मौजूदा बग रिपोर्ट पर त्वरित खोज करें। आप संकीर्ण चीजों को कम करने में मदद करने के लिए "बग" लेबल द्वारा खोजों को स्कोप कर सकते हैं।

  • [] पुन : पेश करने के लिए कदमों को शामिल करें : अपनी .tf फ़ाइलों के साथ समस्या को पुन : उत्पन्न करने के लिए कदम प्रदान करें, हटाए गए रहस्यों के साथ, इसलिए हम इसे पुन: पेश करने का प्रयास कर सकते हैं। इसके बिना, इस मुद्दे को ठीक करना बहुत कठिन हो जाता है।

  • [] पैनिक के लिए, crash.log शामिल करें। यदि आपको घबराहट हुई है, तो कृपया हमें देखने के लिए संपूर्ण जनरेट किए गए क्रैश लॉग का एक समूह बनाएं। डबल चेक कोई संवेदनशील आइटम लॉग में नहीं थे।

सुविधा का अनुरोध

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

  • [] एक उपयोग मामला विवरण शामिल करें : आप जिस सुविधा को देखना चाहते हैं, उसके व्यवहार का वर्णन करने के अलावा, यह इस कारण से भी उपयोगी है कि यह सुविधा महत्वपूर्ण क्यों होगी और यह टेराफ़ॉर्म उपयोगकर्ताओं को कैसे लाभान्वित करेगी।

प्रशन

  • [] टेराफ़ॉर्म प्रलेखन में उत्तरों की खोज करें : हम GitHub मुद्दों में प्रश्नों का उत्तर देने में प्रसन्न हैं, लेकिन यदि आप दस्तावेज़ में सामान्य प्रश्नों के उत्तर खोजने के लिए काम करते हैं, तो यह समस्या को कम करने में मदद करता है। भविष्य के उपयोगकर्ताओं की सहायता के लिए कई बार प्रश्न जारी करने से दस्तावेज़ीकरण अपडेट होता है, इसलिए यदि आपको कोई उत्तर नहीं मिलता है, तो आप हमें ऐसे बिंदु दे सकते हैं जहाँ आप डॉक्स में इसे देखने की अपेक्षा करेंगे।

मुद्दा जीवनचक्र

  1. मुद्दे की सूचना है।

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

  3. जब तक यह महत्वपूर्ण नहीं होता है, मुद्दा समय की अवधि (कभी-कभी कई सप्ताह) के लिए छोड़ दिया जाता है, जिससे बाहरी योगदानकर्ताओं को समस्या का समाधान करने का मौका मिलता है।

  4. समस्या को पुल अनुरोध या प्रतिबद्ध में संबोधित किया जाता है। इस मुद्दे को प्रतिबद्ध संदेश में संदर्भित किया जाएगा ताकि इसे ठीक करने वाला कोड स्पष्ट रूप से जुड़ा हो।

  5. मुद्दा बंद है। कभी-कभी, समस्या को ट्रैकर को साफ रखने के लिए वैध मुद्दों को बंद कर दिया जाएगा। समस्या अभी भी अनुक्रमित है और भविष्य के दर्शकों के लिए उपलब्ध है, या यदि आवश्यक हो तो फिर से खोला जा सकता है।

अनुरोधों को खींचो

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

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

पुल अनुरोध जीवनचक्र

  1. पूरी तरह से पूरा होने से पहले आप टिप्पणी या समीक्षा के लिए अपने पुल अनुरोध को प्रस्तुत करने का स्वागत करते हैं। कृपया इसे इंगित करने के लिए "[WIP]" के साथ अपने पुल अनुरोध का शीर्षक उपसर्ग करें। यह उन विशिष्ट प्रश्नों या वस्तुओं को शामिल करने के लिए एक अच्छा विचार है जिन पर आप प्रतिक्रिया चाहते हैं।

  2. एक बार जब आप मानते हैं कि आपका पुल अनुरोध विलय होने के लिए तैयार है, तो आप शीर्षक से किसी भी "[WIP]" उपसर्ग को हटा सकते हैं और एक कोर टीम के सदस्य समीक्षा करेंगे। यह सुनिश्चित करने में मदद के लिए नीचे दिए गए चेकलिस्ट का पालन करें कि आपका योगदान जल्दी से विलय हो जाएगा।

  3. टेराफॉर्म की कोर टीम के सदस्यों में से एक आपके योगदान को देखेगा और या तो आपको यह बताने के लिए टिप्पणियां देगा कि क्या कुछ करना बाकी है। हम समय पर प्रतिक्रिया देने की पूरी कोशिश करते हैं, लेकिन हमें प्रतिक्रिया देने में कुछ समय लग सकता है।

  4. एक बार सभी बकाया टिप्पणियों और चेकलिस्ट आइटम को संबोधित करने के बाद, आपके योगदान को मिला दिया जाएगा! मर्ज किए गए PR को अगले टेराफ़ॉर्म रिलीज़ में शामिल किया जाएगा। कोर टीम, मर्ज होने के साथ ही CHANGELOG को अपडेट करने का ध्यान रखती है।

  5. दुर्लभ मामलों में, हम यह तय कर सकते हैं कि एक पीआर बंद होना चाहिए। ऐसा होने पर हम स्पष्ट तर्क प्रदान करना सुनिश्चित करेंगे।

योगदान के लिए चेकलिस्ट

कई अलग-अलग प्रकार के योगदान हैं, जिनमें से प्रत्येक के पास एक तेज समीक्षा के लिए अपने स्वयं के मानक हैं। निम्नलिखित अनुभाग प्रत्येक प्रकार के योगदान के लिए दिशानिर्देशों का वर्णन करते हैं।

प्रलेखन अद्यतन

क्योंकि टेराफॉर्म की वेबसाइट कोड के समान रेपो में है, इसलिए हमारे डॉक्स को बेहतर बनाने में हमारी मदद करना किसी के लिए भी आसान है।

  • [] डॉक्स अपडेट के लिए रीजनिंग : समीक्षकों के लिए अपडेट की आवश्यकता क्यों है, इसके लिए एक त्वरित स्पष्टीकरण सहित।
  • [] प्रासंगिक टेराफ़ॉर्म संस्करण : क्या यह अपडेट तुरंत साइट पर तैनात करने के लायक है, या क्या यह टेराफ़ॉर्म के आगामी संस्करण को संदर्भित कर रहा है और अगली रिलीज़ के साथ बाहर जाना चाहिए?

जैसा कि ऊपर उल्लेख किया गया है, प्रत्येक टेराफ़ॉर्म प्रदाता के पास टेराफ़ॉर्म प्रोवाइडर्स में अपना कोड रिपॉजिटरी है। प्रत्येक रिपॉजिटरी के पास website नाम का अपना फ़ोल्डर होता है, जिसमें उस प्रदाता के दस्तावेज होते हैं। किसी विशिष्ट प्रदाता के लिए दस्तावेज़ीकरण के अपडेट को वहां रिपोर्ट या पोस्ट किया जाना चाहिए।

एक संसाधन के लिए संवर्धन / Bugfix

मौजूदा संसाधनों पर काम करना टेराफॉर्म योगदानकर्ता के रूप में शुरू करने का एक शानदार तरीका है क्योंकि आप मौजूदा कोड और परीक्षणों के भीतर काम कर सकते हैं कि क्या करना है।

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

नया संसाधन

एक नए संसाधन को लागू करना एक अच्छा तरीका है, जिसके बारे में अधिक जानने के लिए कि कैसे Terraform अपस्ट्रीम एपीआई के साथ बातचीत करता है। मौजूदा संसाधनों से आकर्षित करने के लिए बहुत सारे उदाहरण हैं, लेकिन आपको अभी भी कुछ नया लागू करना है।

  • [] न्यूनतम एलओसी : कई संसाधनों के साथ एक बड़े पीआर पर लंबी प्रतिक्रिया चक्र के माध्यम से समीक्षक और लेखक दोनों के लिए यह अक्षम हो सकता है। इसलिए हम आपको एक बार में केवल 1 संसाधन प्रस्तुत करने के लिए प्रोत्साहित करते हैं।
  • [] स्वीकृति परीक्षण : नए संसाधनों में अपने व्यवहार को शामिल करने वाले स्वीकृति परीक्षण शामिल होने चाहिए। इनसे कैसे संपर्क करें, इस बारे में विस्तृत गाइड के लिए नीचे दिए गए लेखन स्वीकृति टेस्ट देखें।
  • [] प्रलेखन : प्रत्येक संसाधन को टेराफ़ॉर्म प्रलेखन में एक पृष्ठ मिलता है। टेराफ़ॉर्म वेबसाइट स्रोत इस रेपो में है और यदि आप अपने परिवर्तनों का पूर्वावलोकन करना चाहते हैं तो साइट की एक स्थानीय प्रतिलिपि प्राप्त करने और चलाने के निर्देश शामिल हैं। एक संसाधन के लिए, आप एक नई फ़ाइल को उपयुक्त स्थान पर जोड़ना चाहते हैं और उस पृष्ठ के साइडबार में लिंक जोड़ सकते हैं।
  • [] अच्छी तरह से बनाई गई कोड : कोडबेस में आपके द्वारा देखे गए मौजूदा सम्मेलनों का पालन करने के लिए अपना सर्वश्रेष्ठ प्रयास करें, और सुनिश्चित करें कि आपका कोड go fmt साथ स्वरूपित हो। (ट्रैविस सीआई बिल्ड विफल हो जाएगा यदि आने वाले कोड पर go fmt नहीं चलाया गया है।) पीआर समीक्षक इस मोर्चे पर मदद कर सकते हैं, और कोड को बेहतर बनाने के लिए सुझावों के साथ टिप्पणियां प्रदान कर सकते हैं।

नया प्रदाता

एक नए प्रदाता को लागू करने से टेराफॉर्म को एक पूरे नए एपीआई में संसाधनों का प्रबंधन करने की क्षमता मिलती है। यह एक बड़ा उपक्रम है, लेकिन टेराफॉर्म में प्रमुख नई कार्यक्षमता लाता है।

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

कोर बगफिक्स / एन्हांसमेंट

जब किसी भी डेवलपर को मदद करने के लिए टेराफॉर्म के कोर में गोता लगाने में दिलचस्पी होती है तो हम हमेशा खुश रहते हैं! यहाँ हम छोटे Core PRs की तलाश कर रहे हैं।

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

कोर फ़ीचर

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

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

लेखन परीक्षण स्वीकार करते हैं

टेराफॉर्म में एक स्वीकृति परीक्षण हार्नेस शामिल है जो संसाधन के परीक्षण में शामिल अधिकांश दोहराए गए कार्य करता है।

स्वीकृति टेस्ट अक्सर चलाने के लिए पैसे खर्च होते हैं

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

एक स्वीकृति परीक्षण चल रहा है

testacc में testacc लक्ष्य का उपयोग करके स्वीकृति परीक्षण चलाया जा सकता है। चलाने के लिए व्यक्तिगत परीक्षणों को एक नियमित अभिव्यक्ति का उपयोग करके नियंत्रित किया जा सकता है। परीक्षण प्रदाता कॉन्फ़िगरेशन चलाने से पहले एक्सेस कुंजियाँ जैसे कि पर्यावरण चर के रूप में उपलब्ध कराई जानी चाहिए।

उदाहरण के लिए, Azure संसाधन प्रबंधक प्रदाता के विरुद्ध स्वीकृति परीक्षण चलाने के लिए, निम्नलिखित पर्यावरण चर निर्धारित किए जाने चाहिए:

export ARM_SUBSCRIPTION_ID=...
export ARM_CLIENT_ID=...
export ARM_CLIENT_SECRET=...
export ARM_TENANT_ID=...

फिर परीक्षण प्रदाता को निर्दिष्ट करके और परीक्षण चलाने के लिए एक नियमित अभिव्यक्ति निर्धारित करके टेस्ट चलाए जा सकते हैं:

$ make testacc TEST=./builtin/providers/azurerm TESTARGS='-run=TestAccAzureRMPublicIpStatic_update'
==> Checking that code complies with gofmt requirements...
go generate ./...
TF_ACC=1 go test ./builtin/providers/azurerm -v -run=TestAccAzureRMPublicIpStatic_update -timeout 120m
=== RUN   TestAccAzureRMPublicIpStatic_update
--- PASS: TestAccAzureRMPublicIpStatic_update (177.48s)
PASS
ok      github.com/hashicorp/terraform/builtin/providers/azurerm    177.504s

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

$ make testacc TEST=./builtin/providers/azurerm TESTARGS='-run=TestAccAzureRMPublicIpStatic'
==> Checking that code complies with gofmt requirements...
go generate ./...
TF_ACC=1 go test ./builtin/providers/azurerm -v -run=TestAccAzureRMPublicIpStatic -timeout 120m
=== RUN   TestAccAzureRMPublicIpStatic_basic
--- PASS: TestAccAzureRMPublicIpStatic_basic (137.74s)
=== RUN   TestAccAzureRMPublicIpStatic_update
--- PASS: TestAccAzureRMPublicIpStatic_update (180.63s)
PASS
ok      github.com/hashicorp/terraform/builtin/providers/azurerm    318.392s

एक्सेप्टेंस टेस्ट लिखना

टेराफॉर्म में स्वीकृति परीक्षण लिखने के लिए एक रूपरेखा है जो सामान्य परीक्षण पैटर्न का उपयोग करने के लिए आवश्यक बॉयलरप्लेट कोड की मात्रा को कम करता है। फ्रेमवर्क में प्रवेश बिंदु resource.Test() है। resource.Test() फ़ंक्शन।

टेस्ट TestStep एस में विभाजित हैं। प्रत्येक TestStep प्रदाता परीक्षण के तहत प्रदाता का उपयोग करके कुछ TestStep कॉन्फ़िगरेशन को लागू करके आगे बढ़ता है, और फिर यह सत्यापित करते हुए कि प्रदाता API का उपयोग करके दावे के अनुसार परिणाम अपेक्षित हैं। एकल परीक्षण फ़ंक्शन के लिए और एकल संसाधन के लिए अद्यतनों के निर्माण के लिए यह आम बात है। अधिकांश परीक्षण एक समान संरचना का पालन करते हैं।

  1. प्री-फ्लाइट चेक यह सुनिश्चित करने के लिए किए गए हैं कि पर्याप्त प्रदाता कॉन्फ़िगरेशन आगे बढ़ने में सक्षम हो - उदाहरण के लिए AWS, AWS_ACCESS_KEY_ID और AWS_SECRET_ACCESS_KEY को लक्षित करने के लिए स्वीकृति परीक्षण चलाने से पहले सेट किया जाना चाहिए। यह एकल प्रदाता के व्यायाम करने वाले सभी परीक्षणों के लिए सामान्य है।

प्रत्येक TestStep को TestStep resource.Test() में परिभाषित किया गया है। अधिकांश अभिकथन कार्यों को परीक्षणों के साथ बैंड के बाहर परिभाषित किया गया है। यह परीक्षणों को पढ़ने योग्य रखता है, और एक ही प्रकार के संसाधन के विभिन्न परीक्षणों में अभिकथन कार्यों के पुन: उपयोग की अनुमति देता है। एक पूर्ण परीक्षण की परिभाषा इस प्रकार है:

func TestAccAzureRMPublicIpStatic_update(t *testing.T) {
        resource.Test(t, resource.TestCase{
                PreCheck:     func() { testAccPreCheck(t) },
                Providers:    testAccProviders,
                CheckDestroy: testCheckAzureRMPublicIpDestroy,
                Steps: []resource.TestStep{
                        resource.TestStep{
                                Config: testAccAzureRMVPublicIpStatic_basic,
                                Check: resource.ComposeTestCheckFunc(
                                        testCheckAzureRMPublicIpExists("azurerm_public_ip.test"),
                                ),
                        },
        },
    })
}

परीक्षण निष्पादित करते समय, प्रत्येक TestStep लिए निम्नलिखित कदम उठाए जाते हैं:

  1. परीक्षण के लिए आवश्यक टेराफ़ॉर्म कॉन्फ़िगरेशन लागू किया जाता है। यह परीक्षण के तहत संसाधन को कॉन्फ़िगर करने और इसके लिए किसी भी निर्भरता के लिए जिम्मेदार है। उदाहरण के लिए, azurerm_public_ip संसाधन का परीक्षण करने के लिए, azurerm_resource_group की आवश्यकता होती है। इसके परिणामस्वरूप कॉन्फ़िगरेशन ऐसा दिखता है:

    resource "azurerm_resource_group" "test" {
        name = "acceptanceTestResourceGroup1"
        location = "West US"
    }
    
    resource "azurerm_public_ip" "test" {
        name = "acceptanceTestPublicIp1"
        location = "West US"
        resource_group_name = "${azurerm_resource_group.test.name}"
        public_ip_address_allocation = "static"
    }
    
  2. प्रदाता API का उपयोग करके दावे चलाए जा रहे हैं। ये रिसोर्स API का उपयोग रिसोर्स स्टेट के विरुद्ध दावा करने के बजाय सीधे करते हैं। उदाहरण के लिए, यह प्रमाणित करने के लिए कि ऊपर वर्णित azurerm_public_ip सफलतापूर्वक बनाया गया था, इस तरह एक परीक्षण फ़ंक्शन का उपयोग किया जाता है:

    func testCheckAzureRMPublicIpExists(name string) resource.TestCheckFunc {
        return func(s *terraform.State) error {
            // Ensure we have enough information in state to look up in API
            rs, ok := s.RootModule().Resources[name]
            if !ok {
                return fmt.Errorf("Not found: %s", name)
            }
    
            publicIPName := rs.Primary.Attributes["name"]
            resourceGroup, hasResourceGroup := rs.Primary.Attributes["resource_group_name"]
            if !hasResourceGroup {
                return fmt.Errorf("Bad: no resource group found in state for public ip: %s", availSetName)
            }
    
            conn := testAccProvider.Meta().(*ArmClient).publicIPClient
    
            resp, err := conn.Get(resourceGroup, publicIPName, "")
            if err != nil {
                return fmt.Errorf("Bad: Get on publicIPClient: %s", err)
            }
    
            if resp.StatusCode == http.StatusNotFound {
                return fmt.Errorf("Bad: Public IP %q (resource group: %q) does not exist", name, resourceGroup)
            }
    
            return nil
        }
    }
    

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

```go
resource.TestCheckResourceAttr("azurerm_public_ip.test", "domain_name_label", "mylabel01"),
```
  1. परीक्षण द्वारा बनाए गए संसाधन नष्ट हो जाते हैं। यह चरण स्वचालित रूप से होता है, और terraform destroy को कॉल करने के बराबर है।

  2. यह सत्यापित करने के लिए प्रदाता API के खिलाफ दावे किए जाते हैं कि संसाधन वास्तव में हटा दिए गए हैं। यदि ये जांच विफल हो जाती है, तो परीक्षण विफल हो जाता है और "झूलने वाले संसाधनों" की रिपोर्ट करता है। यह सुनिश्चित करने के लिए कोड कि azurerm_public_ip ऊपर दिखाया गया है, इस तरह दिखता है:

    func testCheckAzureRMPublicIpDestroy(s *terraform.State) error {
        conn := testAccProvider.Meta().(*ArmClient).publicIPClient
    
        for _, rs := range s.RootModule().Resources {
            if rs.Type != "azurerm_public_ip" {
                continue
            }
    
            name := rs.Primary.Attributes["name"]
            resourceGroup := rs.Primary.Attributes["resource_group_name"]
    
            resp, err := conn.Get(resourceGroup, name, "")
    
            if err != nil {
                return nil
            }
    
            if resp.StatusCode != http.StatusNotFound {
                return fmt.Errorf("Public IP still exists:\n%#v", resp.Properties)
            }
        }
    
        return nil
    }
    

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