ब्रांच

ब्रांच व्यू आपकी रिपॉजिटरी में विभिन्न ब्रांच की पूरी जानकारी प्रदान करता है।

स्टेज

Odoo.sh तीन अलग-अलग ब्रांच स्टेज ऑफ़र करता है:

• प्रॉडक्शन

• स्टेजिंग

• डेवलपमेंट

आप किसी ब्रांच की स्टेज को वांछित स्टेज के नीचे ड्रैग और ड्रॉप करके बदल सकते हैं।

टिप्पणी

• डेवलपमेंट ब्रांच को स्टेजिंग के नीचे ले जाया जा सकता है। अगर आप डेवलपमेंट ब्रांच को प्रॉडक्शन के नीचे ले जाने की कोशिश करते हैं, तो एक चेतावनी मैसेज दिखाई देगा जो बताएगा कि प्रति प्रोजेक्ट में सिर्फ़ एक प्रॉडक्शन ब्रांच हो सकती है।

• स्टेजिंग ब्रांच को डेवलपमेंट के नीचे ले जाया जा सकता है, लेकिन उन्हें प्रॉडक्शन के नीचे ले जाना संभव नहीं है।

• प्रॉडक्शन ब्रांच को केवल डेवलपमेंट के नीचे ले जाया जा सकता है। अगर आप इसे स्टेजिंग के नीचे ले जाने की कोशिश करते हैं, तो आप केवल मर्ज कर सकते हैं। इस प्रक्रिया की विस्तृत जानकारी के लिए मर्जिंग सेक्शन देखें।

उत्पादन

प्रॉडक्शन ब्रांच में वह कोड होता है जो प्रॉडक्शन डेटाबेस चलाने के लिए इस्तेमाल किया जाता है। केवल एक ही प्रॉडक्शन ब्रांच हो सकती है।

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

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

यह विधि ऐप्लिकेशन मेन्यू या कमांड लाइन पर -u स्विच का इस्तेमाल करके मॉड्यूल अपग्रेड करने के बराबर है।

टिप्पणी

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

• डेमो डेटा लोड नहीं किया जाता है, क्योंकि यह प्रॉडक्शन डेटाबेस पर इस्तेमाल के लिए नहीं है। <https://en.wikipedia.org/wiki/Unit_testing>यूनिट टेस्ट नहीं किए जाते हैं, क्योंकि इससे अपडेट के दौरान प्रॉडक्शन डेटाबेस की अनुपलब्धता का समय बढ़ जाएगा।

Odoo.sh ऑटोमैटिकली प्रॉडक्शन डेटाबेस का बैकअप लेता है। यह सात दैनिक, चार साप्ताहिक, और तीन मासिक बैकअप रखता है। प्रत्येक बैकअप में डेटाबेस डंप, फ़ाइलस्टोर (अटैचमेंट और बाइनरी फ़ीील्ड), लॉग, और सेशन शामिल होते हैं।

चेतावनी

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

स्टेजिंग

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

न्यूट्रलाइज़ेशन निम्नलिखित को अक्षम करता है:

• शेड्यूल्ड एक्शन

  टिप्पणी

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

• आउटगोइंग ईमेल

  टिप्पणी

  इसके बजाय उन्हें मेल कैचर का उपयोग करके इंटरसेप्ट किया जाता है। डेटाबेस द्वारा भेजे गए ईमेल देखने के लिए आपके Odoo.sh प्रोजेक्ट में एक इंटरफ़ेस प्रदान किया गया है। इस तरह, आपके कॉन्टैक्ट को कोई ईमेल नहीं भेजा जाता है।

• IAP सर्विस

• पेमेंट प्रोवाइडर और शिपिंग कनेक्टर

  टिप्पणी

  उन्हें टेस्ट मोड में रखा जाता है।

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

टिप्पणी

यूनिट टेस्ट नहीं किए जाते हैं। वे डेमो डेटा पर निर्भर करते हैं, जो प्रॉडक्शन और स्टेजिंग डेटाबेस में लोड नहीं होता है। अगर Odoo डेमो डेटा के बिना यूनिट चलाने का समर्थन करना शुरू करता है, तो Odoo.sh स्टेजिंग डेटाबेस पर टेस्ट चलाने पर विचार करेगा।

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

चेतावनी

स्टेजिंग ब्रांच के लिए बनाए गए डेटाबेस एक महीने के बाद ऑटोमैटिकली डिलीट हो जाते हैं। ब्रांच को फिर से इस्तेमाल करने के लिए, आपको इसे रीबिल्ड करना होगा।

डेवलपमेंट

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

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

स्टेजिंग ब्रांच की तरह, ईमेल नहीं भेजे जाते हैं बल्कि मेल कैचर द्वारा इंटरसेप्ट किए जाते हैं, और शेड्यूल्ड एक्शन तब तक ट्रिगर नहीं होते जब तक डेटाबेस इस्तेमाल में नहीं होता।

डेवलपमेंट डेटाबेस ऑटोमैटिकली बैकअप नहीं होते हैं, और मैनुअल बैकअप संभव नहीं हैं।

चेतावनी

डेवलपमेंट ब्रांच के लिए बनाए गए डेटाबेस लगभग तीन दिन तक चलने के लिए हैं। उसके बाद, वे बिना पूर्व सूचना के नए डेटाबेस के लिए जगह बनाने के लिए ऑटोमैटिकली गारबेज-कलेक्ट हो सकते हैं।

ब्रांच मर्ज करना

आप अपनी ब्रांच को एक दूसरे में ड्रैग एंड ड्रॉप करके मर्ज कर सकते हैं।

प्रॉडक्शन डेटा के साथ डेवलपमेंट ब्रांच के बदलावों को टेस्ट करने के लिए, आप या तो:

• डेवलपमेंट ब्रांच को स्टेजिंग ब्रांच में मर्ज करें, इसे वांछित ब्रांच पर ड्रैग एंड ड्रॉप करके; या

  

• डेवलपमेंट ब्रांच को Staging सेक्शन के अंदर ड्रैग और ड्रॉप करें ताकि इसे स्टेजिंग ब्रांच बनाया जा सके।

  

जब बदलाव प्रॉडक्शन के लिए तैयार हों, तो स्टेजिंग ब्रांच को प्रॉडक्शन ब्रांच में ड्रैग और ड्रॉप करें ताकि उन्हें मर्ज और डिप्लॉय किया जा सके।

टिप्पणी

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

• आप डेवलपमेंट ब्रांच को एक-दूसरे में, और स्टेजिंग ब्रांच को एक-दूसरे में मर्ज कर सकते हैं।

• आप अपने वर्कस्टेशन पर सीधे git merge का इस्तेमाल करके अपनी ब्रांच को मर्ज कर सकते हैं। जब आपकी ब्रांच में नए रिविज़न पुश किए जाते हैं तो Odoo.sh को सूचित किया जाता है।

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

अगर आप स्टेजिंग ब्रांच में कॉन्फ़िगरेशन बदलावों को टेस्ट करते हैं, और चाहते हैं कि वे प्रॉडक्शन ब्रांच में अप्लाई हों, तो आपको या तो:

• डिफ़ॉल्ट कॉन्फ़िगरेशन या व्यू को ओवरराइड करने के लिए कॉन्फ़िगरेशन बदलावों को ब्रांच में XML डेटा फ़ाइल में लिखें, और फिर इसके मैनिफ़ेस्ट (__manifest__.py) में मॉड्यूल का वर्शन बढ़ाएं ताकि स्टेजिंग ब्रांच को प्रॉडक्शन ब्रांच में मर्ज करते समय मॉड्यूल अपडेट ट्रिगर हो।

  टिप्पणी

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

• उन्हें स्टेजिंग डेटाबेस से प्रॉडक्शन डेटाबेस में कॉपी और पेस्ट करके मैन्युअली पास करें।

टैब्स

इतिहास

History टैब ब्रांच हिस्ट्री की पूरी जानकारी देता है:

• कमिट मैसेज और उनके ऑथर

• प्लेटफ़ॉर्म से जुड़े विभिन्न इवेंट, जैसे स्टेज बदलाव, डेटाबेस इंपोर्ट, और बैकअप रिस्टोर

हर इवेंट के ऊपरी दाएं कोने में एक स्टेटस डेटाबेस पर मौजूदा ऑपरेशन (जैसे, इंस्टॉलेशन, अपडेट, बैकअप इंपोर्ट) या इसके नतीजे (जैसे, टेस्ट फ़ीडबैक, सफल बैकअप इंपोर्ट) को दर्शाता है। अगर कोई ऑपरेशन सफल होता है, तो एक Connect बटन दिखाई देता है, जो आपको डेटाबेस को ऐक्सेस करने की अनुमति देता है।

ईमेल्स

Mails टैब में मेल कैचर है, जो डेटाबेस द्वारा भेजे गए ईमेल की पूरी जानकारी प्रदान करता है।

टिप्पणी

मेल कैचर डेवलपमेंट और स्टेजिंग ब्रांच के लिए उपलब्ध है। प्रॉडक्शन डेटाबेस से ईमेल वास्तव में भेजे जाते हैं और मेल कैचर द्वारा इंटरसेप्ट नहीं किए जाते।

खोल

Shell टैब कंटेनर तक शेल ऐक्सेस प्रदान करता है।

शेल पर क्लिक करने से एक नया ब्राउज़र टैब खुलता है जहाँ आप बेसिक Linux कमांड (ls, top) चला सकते हैं। आप psql चलाकर डेटाबेस पर शेल खोल सकते हैं।

सलाह

आप एक साथ कई शेल टैब खोल सकते हैं और उन्हें ड्रैग और ड्रॉप करके उनका लेआउट व्यवस्थित कर सकते हैं।

टिप्पणी

• प्रॉडक्शन इंस्टेंस शेल को लाल रंग में हाइलाइट किया जाता है ताकि प्रॉडक्शन इंस्टेंस को सीधे हेरफेर करने के खतरे पर जोर दिया जा सके, जबकि स्टेजिंग/डेवलपमेंट इंस्टेंस शेल को पीले रंग में हाइलाइट किया जाता है।

• लंबे समय तक चलने वाले शेल इंस्टेंस/आइडल शेल सेशन को रिसोर्स खाली करने के लिए किसी भी समय समाप्त किया जा सकता है।

कमांड

यहाँ उपयोगी कमांड की पूरी जानकारी है जो आप Odoo.sh डेटाबेस टर्मिनल पर चला सकते हैं:

• odoo-bin shell: Odoo शेल खोलने के लिए

• odoo-update: डेटाबेस में मॉड्यूल अपडेट करने के लिए

• odoosh-restart: Odoo.sh सर्विस (http या cron) को रीस्टार्ट करने के लिए

• odoosh-storage: आपके इंस्टेंस के कंटेनर फाइलसिस्टम के स्टोरेज उपयोग की जांच करने के लिए

• psql: डेटाबेस शेल खोलने के लिए

• mutt: यह जांचने के लिए कि टेक्स्ट क्लाइंट पर ईमेल कैसे दिखाई देते हैं (स्टेजिंग और डेवलपमेंट इंस्टेंस)

• lnav ~/logs/odoo.log: आपके इंस्टेंस की odoo.log फ़ाइल में नेविगेट करने के लिए

• ncdu: इंटरैक्टिव इंटरफ़ेस के साथ डिस्क उपयोग विश्लेषक को लॉन्च करने के लिए

• grep: लॉग या कॉन्फ़िगरेशन फ़ाइल में जानकारी फ़िल्टर और खोजने के लिए

एडिटर

एडिटर पर क्लिक करने से सोर्स कोड को एडिट करने के लिए एक ऑनलाइन इंटीग्रेटेड डेवलपमेंट एनवायरमेंट (IDE) तक पहुँचने के लिए एक नया ब्राउज़र टैब खुलता है। आप टर्मिनल, Python कंसोल और Odoo शेल कंसोल भी खोल सकते हैं।

आप कई टैब खोल सकते हैं और उन्हें ड्रैग और ड्रॉप करके अपनी इच्छानुसार लेआउट व्यवस्थित कर सकते हैं।

यह भी देखें

ऑनलाइन एडिटर दस्तावेज़।

मॉनिटर

मॉनिटर टैब में मौजूदा बिल्ड की विभिन्न परफ़ॉर्मेंस मॉनिटरिंग मेट्रिक्स प्रदर्शित होती हैं।

समय सीमा समायोजित करने के लिए अपने कर्सर से ज़ूम इन करें या समय सीमा सिलेक्टर से इसे मैन्युअली चुनें। टाइम ज़ोन बदलना भी संभव है।

टिप्पणी

• टेक्निकल लॉग हमेशा UTC का इस्तेमाल करते हैं। अपनी मॉनिटरिंग मेट्रिक्स के साथ इन लॉग्स का विश्लेषण करने के लिए, सुनिश्चित करें कि मॉनिटरिंग टूल में UTC चुना गया है।

• इसी तरह, सपोर्ट टिकट भेजते समय सुनिश्चित करें कि आपके द्वारा शेयर की गई जानकारी UTC पर आधारित है, क्योंकि Odoo परफ़ॉर्मेंस समस्याओं की जांच के लिए इस टाइम ज़ोन का इस्तेमाल करता है।

जानकारी समय-समय पर एकत्रित की जाती है। जब ऐसा होता है, तो एक नीली बिंदीदार लाइन प्रदर्शित होती है और साथ में Aggregate Date टैग दिखता है। इसका मतलब है कि इस तारीख से पहले का डेटा इस तारीख के बाद के डेटा की तुलना में समतल दिखाई देगा। इसलिए, मॉनिटरिंग टूल का इस्तेमाल करते समय, सबसे विस्तृत जानकारी प्राप्त करने के लिए हाल के इवेंट पर ध्यान केंद्रित करने की अनुशंसा की जाती है।

टिप्पणी

अन्य रंगों की बिंदीदार लाइनें बिल्ड में अन्य परिवर्तनों (डेटाबेस इंपोर्ट, git push, आदि) से संबंधित होने में आपकी मदद करती हैं।

सलाह

प्रत्येक ग्राफ़ पर, ऊपरी-बाएं कोने में एक 𝕚 (जानकारी) आइकॉन प्रदर्शित होता है। ग्राफ़ क्या दर्शाता है, इसके बारे में अधिक जानकारी प्राप्त करने के लिए अपने माउस को इस पर होवर करें।

मेट्रिक्स

सिस्टम

Memory ग्राफ़ मेमोरी खपत के बारे में जानकारी प्रदर्शित करता है:

• Memory container Odoo वर्कर्स और कंटेनर प्रोसेसेज़ को दर्शाता है।

• Memory postgresql डेटाबेस को दर्शाता है।

CPU ग्राफ़ CPU खपत के बारे में जानकारी प्रदर्शित करता है:

• CPU http Odoo वर्कर्स को दर्शाता है।

• CPU cron/mail शेड्यूल्ड एक्शन और इनकमिंग ईमेल को दर्शाता है।

• CPU postgresql (डेटाबेस प्रोसेसेज़)

• CPU other वेबशेल, संपादक आदि को दर्शाता है।

Storage ग्राफ़ उपयोग किए गए स्टोरेज के बारे में जानकारी प्रदर्शित करता है:

• Container फ़ाइलस्टोर, लॉग फ़ाइलें और उपयोगकर्ता फ़ाइलों को दर्शाता है।

• Postgresql डेटाबेस और इंडेक्स को दर्शाता है।

HTTP

Requests ग्राफ़ प्रति सेकंड HTTP अनुरोधों की संख्या के बारे में जानकारी प्रदर्शित करता है:

• HTTP successes सफल अनुरोधों को दर्शाता है।

• HTTP errors विफल अनुरोधों को दर्शाता है (odoo.log जाँचें)।

• HTTP rate limited अस्वीकृत अनुरोधों को दर्शाता है, संभवतः वर्कर्स की कमी के कारण।

Concurrent requests (max) ग्राफ़ प्रति सेकंड समवर्ती HTTP अनुरोधों की अधिकतम संख्या प्रदर्शित करता है।

टिप्पणी

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

Average Response time HTTP अनुरोधों के औसत प्रतिक्रिया समय (मिलीसेकंड में) को प्रदर्शित करता है।

ईमेल्स

Incoming ग्राफ़ आने वाले ईमेल की दैनिक संख्या के बारे में डेटा प्रदर्शित करता है:

• Received Emails सफलतापूर्वक प्राप्त ईमेल को दर्शाता है।

• Received Emails bounced असफल रूप से प्राप्त ईमेल को दर्शाता है।

आउटगोइंग ग्राफ़ आउटगोइंग ईमेल की दैनिक संख्या के बारे में डेटा दिखाता है:

• सेंट ईमेल्स सफलतापूर्वक भेजे गए ईमेल को दर्शाता है।

• सेंट ईमेल्स बाउंस्ड असफल रूप से भेजे गए ईमेल को दर्शाता है।

लॉग्स

लॉग्स टैब आपके सर्वर के लॉग का रियल-टाइम व्यू ऑफ़र करता है।

विभिन्न लॉग उपलब्ध हैं:

• pip.log: Python डिपेंडेंसीज़ इंस्टॉलेशन

• install.log: डेटाबेस इंस्टॉलेशन (डेवलपमेंट ब्रांचेज़ के लिए, टेस्ट शामिल हैं)

• odoosh-import-database.log: अंतिम इंपोर्ट किया गया डंप प्रोसेस

• odoo.log: चल रहा सर्वर

• update.log: डेटाबेस अपडेट

• pg_slow_queries.log: psql क्वेरीज़ जो असामान्य समय लेती हैं

• sh_webshell.log: वेबशेल में की गई कार्रवाइयाँ

• sh_editor.log: एडिटर में की गई कार्रवाइयाँ

• neutralize.log: डेटाबेस का न्यूट्रलाइज़ेशन (सिर्फ़ स्टेजिंग)

जब लॉग में नई लाइनें जोड़ी जाती हैं, तो वे ऑटोमैटिकली दिखाई देती हैं। अगर आप नीचे तक स्क्रॉल करते हैं, तो हर बार नई लाइन जोड़े जाने पर ब्राउज़र ऑटोमैटिकली स्क्रॉल करता है।

आप ऊपरी दाएँ कोने में (पॉज़) बटन पर क्लिक करके लॉग फ़ेचिंग प्रोसेस को रोक सकते हैं। अन्यथा, प्रोसेस पाँच मिनट बाद रुक जाती है। आप (प्ले) बटन पर क्लिक करके इसे फिर से शुरू कर सकते हैं।

बैकअप्स

बैकअप टैब डाउनलोड और रिस्टोर करने के लिए उपलब्ध बैकअप की सूची दिखाता है, मैन्युअल बैकअप करने और डेटाबेस इंपोर्ट करने की सुविधा देता है।

प्रॉडक्शन डेटाबेस ऑटोमैटिकली रोज़ाना बैक अप किया जाता है। सात दैनिक, चार साप्ताहिक, और तीन मासिक बैकअप रखे जाते हैं। प्रत्येक बैकअप में डेटाबेस डंप, फ़ाइलस्टोर (अटैचमेंट और बाइनरी फ़ील्ड), लॉग, और सेशन शामिल होते हैं।

टिप्पणी

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

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

लिस्ट में आपके प्रॉडक्शन डेटाबेस के सर्वर पर रखे गए बैकअप होते हैं। यह सर्वर सिर्फ़ एक महीना के बैकअप रखता है: सात दैनिक और चार साप्ताहिक बैकअप।

समर्पित बैकअप सर्वर वही बैकअप रखते हैं, साथ ही तीन अतिरिक्त मासिक बैकअप। इनमें से किसी एक मासिक बैकअप को रिस्टोर या डाउनलोड करने के लिए, Odoo Support से संपर्क करें।

जब एक या कई मॉड्यूल के वर्शन को अपडेट करने वाले कमिट को मर्ज किया जाता है (__manifest__.py में), या उनकी लिंक्ड Python डिपेंडेंसीज़ को (requirements.txt में), तो Odoo.sh एक ऑटोमैटिक बैकअप परफ़ॉर्म करता है (लिस्ट में टाइप Update के साथ फ़्लैग किया गया), क्योंकि या तो कंटेनर नए pip पैकेजेस की इंस्टॉलेशन द्वारा बदला जाएगा, या फिर डेटाबेस खुद बाद में ट्रिगर किए गए मॉड्यूल अपडेट के साथ बदला जाएगा। इन दोनों मामलों में, एक बैकअप ट्रिगर होता है क्योंकि यह कुछ तोड़ सकता है।

अगर मर्ज किया गया कमिट किसी मॉड्यूल या लिंक्ड डिपेंडेंसीज़ के वर्शन को अपडेट नहीं करता है, तो Odoo.sh द्वारा कोई बैकअप ट्रिगर नहीं होता है, क्योंकि न तो कंटेनर और न ही डेटाबेस मॉडिफ़ाई होता है; इसलिए, प्लेटफ़ॉर्म इसे काफ़ी सुरक्षित मानता है। अतिरिक्त सावधानी के रूप में, आप प्रॉडक्शन सोर्सेस को मॉडिफ़ाई करने से पहले एक मैन्युअल बैकअप बना सकते हैं।

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

स्टेज	ऑटोमैटिक बैकअप	मैन्युअल बैकअप
उत्पादन	हां (3 महीने तक)	हां (3 दिन)
स्टेजिंग	नहीं	हां (3 दिन)
डेवलपमेंट	नहीं	नहीं

Import Database फ़ीचर निम्नलिखित से डेटाबेस आर्काइव स्वीकार करता है:

• स्टैंडर्ड Odoo डेटाबेस मैनेजर (ऑन-प्रिमाइस Odoo सर्वर के लिए /web/database/manager के तहत उपलब्ध)

• Odoo Online डेटाबेस मैनेजर

• Odoo.sh Backups टैब ( (Download Options) बटन का उपयोग करके)

• Odoo.sh Builds व्यू (Download DB dump पर क्लिक करके)

अपग्रेड

अपग्रेड टैब का इस्तेमाल वैलिड प्रोजेक्ट की प्रॉडक्शन और स्टेजिंग ब्रांच को अपग्रेड करने के लिए किया जा सकता है। अपग्रेड प्रोसेस के बारे में ज़्यादा जानकारी के लिए अपग्रेड दस्तावेज़ देखें।

टूल

टूल टैब में कोड प्रोफाइलर होता है। इसका इस्तेमाल प्रोफाइलिंग सेशन शुरू करने के लिए किया जाता है, जो इंस्टेंस में चल रहे Odoo वर्कर की एक्टिविटी को ज़्यादा से ज़्यादा पाँच मिनट तक रिकॉर्ड करता है। आप सेशन को पहले खत्म करना चुन सकते हैं, क्योंकि टूल को कम समय तक चलाने से रिपोर्ट में शोर की मात्रा कम हो जाती है।

हर सेशन के बाद, एक इंटरैक्टिव फ्लेम ग्राफ़ बनाया जाता है जो आपको यह विज़ुअलाइज़ करने में मदद करता है कि Odoo वर्कर अपना समय कैसे आवंटित करते हैं।

चेतावनी

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

कॉन्फ़िगरेशन

सेटिंग टैब वर्तमान में चुनी गई ब्रांच के लिए उपलब्ध कॉन्फ़िगरेशन ऑप्शन की सूची दिखाता है। ऑप्शन हर स्टेज के लिए अलग-अलग होते हैं।

नए कमिट पर व्यवहार

आप डेवलपमेंट और स्टेजिंग ब्रांच के लिए नया कमिट मिलने पर ब्रांच के व्यवहार को बदल सकते हैं।

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

अगर आप स्टेजिंग ब्रांच के लिए नया बिल्ड चुनते हैं, तो हर बार कमिट पुश होने पर प्रॉडक्शन बिल्ड की एक ताज़ा कॉपी बनाई जाती है।

जो ब्रांच स्टेजिंग से डेवलपमेंट में मूव की जाती है, वह ऑटोमैटिकली कुछ न करें पर सेट हो जाती है।

मॉड्यूल इंस्टॉलेशन

आप चुन सकते हैं कि डेवलपमेंट ब्रांच के लिए कौन से मॉड्यूल ऑटोमैटिकली इंस्टॉल होने चाहिए।

डिफ़ॉल्ट व्यवहार बदलने के लिए, डेवलपमेंट बिल्ड व्यवहार के तहत डिफ़ॉल्ट इस्तेमाल करें ऑप्शन को अनटिक करें और मॉड्यूल इंस्टॉलेशन के तहत निम्नलिखित में से एक ऑप्शन चुनें:

• सिर्फ़ मेरे मॉड्यूल इंस्टॉल करें (सबमॉड्यूल शामिल नहीं): सिर्फ़ ब्रांच के मॉड्यूल इंस्टॉल करता है, सबमॉड्यूल को छोड़कर। यह डिफ़ॉल्ट ऑप्शन है।

• पूर्ण इंस्टॉलेशन (कोई टेस्ट सूट नहीं): ब्रांच के मॉड्यूल, सबमॉड्यूल और सभी स्टैंडर्ड Odoo मॉड्यूल इंस्टॉल करता है। पूर्ण इंस्टॉलेशन चलाते समय, टेस्ट सूट अक्षम हो जाता है।

• मॉड्यूल की सूची इंस्टॉल करें: निर्दिष्ट मॉड्यूल इंस्टॉल करता है। ऐसा करने के लिए, उनका टेक्निकल नाम दर्ज करें और उन्हें कॉमा से अलग करें (जैसे, sale_management,website,accountant)।

टिप्पणी

अगर टेस्ट सूट सक्षम है, तो सभी स्टैंडर्ड Odoo मॉड्यूल इंस्टॉल करने में एक घंटे तक का समय लग सकता है।

टेस्ट सूट

डिफ़ॉल्ट रूप से, डेवलपमेंट ब्रांच के लिए टेस्ट सूट सक्षम होता है। आप टेस्ट टैग दर्ज करके और उन्हें कॉमा से अलग करके यह सीमित कर सकते हैं कि कौन से टेस्ट चलाए जाएं (जैसे, custom_tags,at_install,post_install)।

टेस्ट सूट को पूरी तरह से अक्षम करने के लिए, नए बिल्ड पर टेस्ट सूट को वैलिडेट करें को अनटिक करें।

Odoo वर्शन

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

डिफ़ॉल्ट रूप से, लेटेस्ट को रिवीज़न के रूप में चुना जाता है, और आपके Odoo सर्वर के सोर्स साप्ताहिक रूप से ऑटोमैटिकली अपडेट होते हैं ताकि नवीनतम बग, सुरक्षा और परफ़ॉर्मेंस फ़िक्स का लाभ मिल सके।

इसके बजाय कोई विशिष्ट रिवीज़न चुनने के लिए, रिवीज़न फ़ील्ड का इस्तेमाल करके इसे चुनें।

चेतावनी

रिवीज़न तीन महीने बाद समाप्त हो जाते हैं। रिवीज़न की समाप्ति तिथि नज़दीक आने पर आपको ईमेल द्वारा सूचित किया जाएगा। अगर समाप्त होने पर आपने कोई कार्रवाई नहीं की है, तो रिवीज़न फ़ील्ड ऑटोमैटिकली लेटेस्ट पर वापस सेट हो जाती है।

कस्टम डोमेन

आप सभी ब्रांच प्रकारों के लिए अतिरिक्त <name>.odoo.com डोमेन या अपने खुद के कस्टम डोमेन कॉन्फ़िगर कर सकते हैं।

अपने खुद के कस्टम डोमेन का इस्तेमाल करने के लिए, यह आवश्यक है:

• डोमेन नाम का स्वामित्व रखें या खरीदें।

• कस्टम डोमेन के तहत डोमेन नाम दर्ज करें (जैसे, www.mycompany.com), फिर डोमेन जोड़ें पर क्लिक करें।

• अपने रजिस्ट्रार के डोमेन नाम मैनेजर का इस्तेमाल करके डोमेन नाम (जैसे, www.mycompany.com) को CNAME रिकॉर्ड वैल्यू के साथ कॉन्फ़िगर करें जो आपके प्रॉडक्शन डेटाबेस डोमेन नाम (जैसे, mycompany.odoo.com) पर सेट हो।

महत्त्वपूर्ण

बेयर डोमेन (जैसे, mycompany.com) स्वीकार नहीं किए जाते हैं। उन्हें केवल A रिकॉर्ड का इस्तेमाल करके कॉन्फ़िगर किया जा सकता है, जो केवल आईपी पते को अपनी वैल्यू के रूप में स्वीकार करते हैं। इसलिए, एक बेयर डोमेन अचानक काम करना बंद कर सकता है, क्योंकि डेटाबेस का आईपी पता बदल सकता है (जैसे, अपग्रेड के बाद, हार्डवेयर विफलता, डेटाबेस होस्टिंग जगह में बदलाव)।

अपने बेयर डोमेन (जैसे, mycompany.com) और www डोमेन (जैसे, www.mycompany.com) दोनों को काम करने के लिए, बेयर डोमेन को www डोमेन पर रीडायरेक्ट करना आवश्यक है। अधिकांश डोमेन मैनेजर इस रीडायरेक्शन को कॉन्फ़िगर करने का तरीका प्रदान करते हैं, जिसे आमतौर पर वेब रीडायरेक्शन कहा जाता है।

HTTPS/SSL

अगर रीडायरेक्शन सही तरीके से सेट किया गया है, तो एक घंटे के भीतर Let's Encrypt का इस्तेमाल करके ऑटोमैटिकली SSL सर्टिफ़िकेट जेनरेट हो जाता है, जिसका मतलब है कि आपका डोमेन HTTPS के माध्यम से सुलभ होगा।

SPF और DKIM अनुपालन

अगर आपके ईमेल पतों का डोमेन SPF या DKIM प्रमाणीकरण प्रोटोकॉल का इस्तेमाल करता है, तो आउटगोइंग ईमेल की डिलीवरी बढ़ाने के लिए डोमेन नाम सेटिंग में Odoo को सेंडिंग होस्ट के रूप में अधिकृत करना ज़रूरी है। ज़्यादा जानकारी के लिए, Odoo में ईमेल भेजने के लिए DNS रिकॉर्ड कॉन्फ़िगर करें दस्तावेज़ देखें।

महत्त्वपूर्ण

अगर Odoo को सेंडिंग होस्ट के रूप में अधिकृत नहीं किया गया है, तो आपके आउटगोइंग ईमेल को स्पैम के रूप में फ़्लैग किया जा सकता है।

शेल कमांड्स

व्यू के ऊपरी दाएं कोने में, कई शेल कमांड दिखाए जाते हैं। कमांड को क्लिपबोर्ड बटन का इस्तेमाल करके कॉपी किया जा सकता है और फिर टर्मिनल में इस्तेमाल किया जा सकता है। इसके अलावा, उनमें से कुछ को सीधे Odoo.sh के इंटरफ़ेस से इस्तेमाल किया जा सकता है।

क्लोन

क्लोन कमांड का इस्तेमाल आपके Git रिपॉजिटरी की लोकल कॉपी बनाने के लिए किया जाता है।

Example

git clone --recurse-submodules --branch development git@github.com:my-organization/my-repository.git

• --recurse-submodules आपकी रिपॉजिटरी के सबमॉड्यूल डाउनलोड करने के लिए

• --branch main रिपॉजिटरी की किसी खास ब्रांच (जैसे, development) को चेक आउट करने के लिए

टिप्पणी

रन बटन उपलब्ध नहीं है क्योंकि कमांड का इस्तेमाल आपकी मशीन पर लोकल कॉपी बनाने के लिए किया जाता है।

काँटा

फ़ोर्क कमांड का इस्तेमाल मौजूदा ब्रांच के आधार पर नई ब्रांच बनाने के लिए किया जाता है।

Example

git checkout -b main-1 development && git push -u origin development-1

• git checkout -b main-1 main मौजूदा ब्रांच (जैसे, development) के आधार पर नई ब्रांच (जैसे, development-1) बनाने के लिए एक कमांड

• git push -u origin development-1 नई ब्रांच (जैसे, development-1) को रिमोट रिपॉजिटरी पर अपलोड करने के लिए एक कमांड

मिलाना

मर्ज कमांड का इस्तेमाल एक ब्रांच पर किए गए बदलावों को दूसरी ब्रांच में जोड़ने के लिए किया जाता है।

Example

git merge staging-1 && git push -u origin staging

• git merge staging-1 मौजूदा ब्रांच के बदलावों को दूसरी ब्रांच (जैसे, staging-1) में मर्ज करने के लिए एक कमांड

• git push -u origin staging मर्ज किए गए बदलावों को रिमोट रिपॉजिटरी ब्रांच (जैसे, staging) पर अपलोड करने के लिए एक कमांड

SSH

SSH कमांड का इस्तेमाल SSH का उपयोग करके बिल्ड से कनेक्ट करने के लिए किया जाता है।

SSH कमांड का इस्तेमाल करने के लिए, पहले SSH की सेट अप करना ज़रूरी है। ऐसा करने के लिए:

• नई SSH की जनरेट करें।

• SSH की को अपने क्लिपबोर्ड पर कॉपी करें।

• Odoo.sh पर, ऊपर-दाईं ओर अपने GitHub यूज़र पर क्लिक करें और प्रोफ़ाइल चुनें।

  

• मैन्युअल रूप से की जोड़ें फ़ील्ड के तहत SSH की पेस्ट करें और जोड़ें पर क्लिक करें।

  

Example

ssh 25004381@my-user-my-repository-staging-25004381.dev.odoo.com

• 25004381 बिल्ड आईडी

• my-user-my-repository-staging-25004381.dev.odoo.com बिल्ड से कनेक्ट करने के लिए उपयोग किया जाने वाला डोमेन

बशर्ते कि आपके पास प्रोजेक्ट पर आवश्यक एक्सेस राइट्स हों, आपको बिल्ड तक SSH एक्सेस दिया जाएगा।

टिप्पणी

लंबे समय तक चलने वाले SSH कनेक्शन की गारंटी नहीं है। रिसोर्स फ्री करने के लिए आइडल कनेक्शन डिस्कनेक्ट किए जा सकते हैं।

सबमॉड्यूल

सबमॉड्यूल कमांड का उपयोग किसी अन्य रिपॉज़िटरी से ब्रांच को अपनी मौजूदा ब्रांच में सबमॉड्यूल के रूप में जोड़ने के लिए किया जाता है।

यह भी देखें

सबमॉड्यूल दस्तावेज़

Example

git submodule add -b master <URL> <PATH> && git commit -a && git push -u origin staging

• git submodule add -b master <URL> <PATH> एक कमांड जो किसी रिपॉज़िटरी (<URL>) की विशिष्ट ब्रांच (जैसे master) को आपकी मौजूदा ब्रांच में निर्दिष्ट पाथ (<PATH>) के तहत सबमॉड्यूल के रूप में जोड़ती है।

• git commit -a सभी वर्तमान परिवर्तनों को कमिट करने के लिए एक कमांड

• git push -u origin staging मौजूदा ब्रांच (जैसे staging) के परिवर्तनों को रिमोट रिपॉज़िटरी में अपलोड करने के लिए एक कमांड।

हटाएं

डिलीट कमांड का उपयोग आपकी रिपॉज़िटरी से ब्रांच को मिटाने के लिए किया जाता है।

टिप्पणी

एक बार जब आप ब्रांच मिटा देते हैं, तो इसे पुनः प्राप्त करने का कोई तरीका नहीं है जब तक कि बैकअप मौजूद न हो। स्टेजिंग ब्रांच ऑटोमैटिकली बैकअप नहीं होती हैं, लेकिन मैन्युअल रूप से हो सकती हैं। डेवलपमेंट ब्रांच का बैकअप नहीं लिया जा सकता।

Example

git push origin :staging && git branch -D staging

• git push origin :staging रिमोट रिपॉज़िटरी पर विशिष्ट ब्रांच (जैसे staging) को मिटाने के लिए एक कमांड

• git branch -D staging रिपॉज़िटरी की अपनी लोकल कॉपी पर विशिष्ट ब्रांच को मिटाने के लिए एक कमांड

चेतावनी

ब्रांच मिटाने से पहले, यह समझने के लिए बैकअप सेक्शन देखें कि वे कैसे काम करते हैं और आपको मैन्युअल बैकअप कब बनाना चाहिए।