साझा स्रोत
एक सामान्य Git स्रोत से शुरू करें और रिलीज़ से जुड़े सटीक commit तथा उपयोगकर्ता-अनुकूल संस्करण को सुरक्षित रखें। अलग-अलग डिप्लॉयमेंट प्रकार स्वतंत्र रूप से आगे बढ़ सकते हैं, फिर भी उसी स्रोत इतिहास से जुड़े रहते हैं।
सॉफ़्टवेयर डिलीवरी
साझा स्रोत से नियंत्रित डिप्लॉयमेंट तक।
Microwave Pie की सॉफ़्टवेयर डिलीवरी क्षमताएँ सेल्फ-होस्टेड एप्लिकेशन के कार्यान्वयन को आसान बनाने के लिए डिज़ाइन की गई हैं: साझा स्रोत से रिलीज़ प्रबंधित करें, डिप्लॉयमेंट के लिए सही पैकेज बनाएँ, लाइसेंसिंग लागू करें और इंस्टॉलेशन व अपडेट को ज्ञात रिलीज़ से जोड़े रखें।
साझा डिलीवरी मॉडल
1साझा एप्लिकेशन स्रोतएक स्रोत इतिहास और रिलीज़ पहचान।
2प्लेटफ़ॉर्म रिलीज़निर्धारित डिप्लॉयमेंट लक्ष्य के लिए बनाएँ।
स्रोत पैकेज
कंपाइल्ड पैकेज
3लाइसेंस वाला पैकेजकिसी विशिष्ट कार्यान्वयन के लिए पैकेज जारी करें।
4इंस्टॉल और अपडेट करेंडिप्लॉयमेंट इतिहास को दी गई रिलीज़ से जुड़ा रखें।
क्षमताएँ
नियंत्रण खोए बिना रिलीज़ विकल्पों को लचीला रखें।
अलग-अलग वातावरणों को हमेशा एक ही पैकेज फ़ॉर्मैट या एक ही समय पर एक ही रिलीज़ की आवश्यकता नहीं होती। Microwave Pie साझा एप्लिकेशन स्रोत, पुन: उपयोग योग्य रिलीज़, पैकेज, लाइसेंस और इंस्टॉल किए गए इंस्टेंस को अलग रखता है ताकि हर पहलू को सोच-समझकर आगे बढ़ाया जा सके।
स्रोत पैकेज
जब पारदर्शिता, सीधे रनटाइम डिप्लॉयमेंट या प्लेटफ़ॉर्म-विशिष्ट Python इंस्टॉलेशन बेहतर विकल्प हो, तो एप्लिकेशन को स्रोत के रूप में दें। स्रोत पैकेज वही रिलीज़ और लाइसेंसिंग मॉडल बनाए रखते हैं जो कंपाइल्ड पैकेज में होता है।
कंपाइल्ड पैकेज
जब अधिक स्व-समाहित रनटाइम पसंद हो, तो कंपाइल्ड एप्लिकेशन पैकेज दें। कंपाइलेशन डिलीवरी का चुनाव है, अलग उत्पाद वंश नहीं, इसलिए रिलीज़ की उत्पत्ति सुसंगत रहती है।
पैकेज और लाइसेंस प्रबंधन
ऐसा पैकेज जारी करें जिसमें उसका लाइसेंस और लक्ष्य डिप्लॉयमेंट संदर्भ पहले से जुड़ा हो। पैकेज जीवनचक्र, लाइसेंस स्थिति, डाउनलोड, इंस्टॉलेशन, अपडेट, निरस्तीकरण और बंद करना बाद में दोबारा जोड़ने के बजाय साथ में प्रबंधित किए जा सकते हैं।
लक्ष्य-विशिष्ट रिलीज़ विकल्प
जब कारण हो, Raspberry Pi, GCP, स्रोत और कंपाइल्ड डिप्लॉयमेंट प्रकार अलग रिलीज़ स्तरों पर रह सकते हैं। गुम Git commits को डिप्लॉयमेंट प्रकार के अनुसार तथा पूरे एप्लिकेशन में देखा जा सकता है।
UI से प्रबंधित अपडेट
प्रबंधित एप्लिकेशन स्वीकृत अपडेट उपलब्ध होने पर उसे बिना थोपे स्वतः दिखा सकते हैं। व्यवस्थापक एप्लिकेशन UI में तय करता है कि अपडेट कब तैयार और लागू करना है; पुनः शुरू होने के बाद इंस्टॉल की गई रिलीज़ को साझा डिलीवरी सेवा में पुष्टि की जा सकती है, जबकि Package और License का संबंध बना रहता है।
कार्यान्वयन
अनिश्चितता नहीं, डिप्लॉयमेंट को पैकेज करें।
सॉफ़्टवेयर पैकेज में वह कार्यान्वयन संदर्भ हो सकता है जो एप्लिकेशन रिलीज़ को कार्यशील डिप्लॉयमेंट में बदलने के लिए चाहिए: लक्ष्य प्लेटफ़ॉर्म, पैकेज फ़ॉर्मैट, इंस्टॉलेशन व्यवहार, रिलीज़ पहचान और लाइसेंसिंग संबंध।
इससे कार्यान्वयन प्रक्रिया किसी ज्ञात रिलीज़ से शुरू हो सकती है, बजाय इसके कि हर वातावरण बिल्ड और डिलीवरी के निर्णय अलग-अलग दोहराए। जब नई रिलीज़ उपयुक्त हो, मौजूदा Package और License संबंध बनाए रखते हुए चुनी गई रिलीज़ को सोच-समझकर आगे बढ़ाया जा सकता है।
Application Releases वास्तव में बने artifact और Git पहचान को सुरक्षित रखते हैं।
उपलब्धता की सूचना स्वतः दी जा सकती है, लेकिन डाउनलोड, तैयारी, लागू करना और पुनः शुरू करना व्यवस्थापक की जानबूझकर की जाने वाली कार्रवाइयाँ रहती हैं।
पैकेज, लाइसेंस और इंस्टॉल किए गए इंस्टेंस इंस्टॉलेशन, अपडेट, निरस्तीकरण और बंद करने के दौरान जुड़े रहते हैं।
Blackcap
आज इस मॉडल का उपयोग एक एप्लिकेशन कर रहा है।
Blackcap को समर्थित Raspberry Pi और GCP वातावरण में स्रोत या कंपाइल्ड पैकेज के रूप में डिप्लॉय किया जा सकता है, जबकि रिलीज़, पैकेज, लाइसेंस और अपडेट व्यवहार एक-दूसरे के अनुरूप रहते हैं।