Microsoft Power Platform के साथ ALM की मूलभूत बातें
इस आलेख में उन घटकों, उपकरणों और प्रक्रियाओं के बारे में बताया गया है, जो एप्लिकेशन जीवन चक्र प्रबंधन (ALM) को कार्यान्वित करने के लिए आवश्यक हैं.
परिवेश
परिवेश आपके संगठन का व्यवसाय डेटा, ऐप्स और व्यवसाय प्रक्रियाओं को संग्रहित, प्रबंधित और साझा करने का एक स्थान हैं. ये उन ऐप्स को अलग-अलग करने के लिए एक कंटेनर के रूप में भी कार्य करते हैं, जिनकी अलग-अलग भूमिकाएँ, सुरक्षा आवश्यकताएँ या लक्षित दर्शक हो सकते हैं. प्रत्येक परिवेश में केवल एक Microsoft Dataverse डेटाबेस हो सकता है. अधिक जानकारी: परिवेश ओवरव्यू
महत्त्वपूर्ण
जब आप एक परिवेश बनाते हैं, तो आप Dynamics 365 Sales और Dynamics 365 Marketing जैसे Dynamics 365 ऐप्स को स्थापित करना चुन सकते हैं. उस समय यह निर्धारित करना महत्वपूर्ण है कि इन ऐप की आवश्यकता है या नहीं, क्योंकि उन्हें बाद में स्थापित नहीं किया जा सकता या उनकी स्थापना रद्द नहीं की जा सकती. यदि आप इन ऐप्स पर निर्माण नहीं कर रहे हैं और भविष्य में आपको इनकी आवश्यकता नहीं है, तो हम अनुशंसा करते हैं कि आप इन्हें अपने परिवेश में स्थापित न करें. जब आप परिवेशों के बीच समाधान वितरित करेंगे, तो यह निर्भरता जटिलताओं से बचने में मदद करेगा.
ALM में उपयोग किए जाने वाले परिवेशों के प्रकार
Power Platform व्यवस्थापन केंद्र का उपयोग करके, आप इस प्रकार के Power Platform परिवेश बना सकते हैं:
सैंडबॉक्स सैंडबॉक्स परिवेश Dataverse का एक गैर-उत्पादन परिवेश होता है. उत्पादन से अलग, सैंडबॉक्स परिवेश अनुप्रयोग परिवर्तन को सुरक्षित रूप से कम जोखिम के साथ विकसित और जाँचने का स्थान है. सैंडबॉक्स परिवेशों में ऐसी क्षमताएं शामिल होती हैं, जो उत्पादन परिवेश में हानिकारक होंगी, जैसे कि रीसेट, हटाने और प्रतिलिपि बनाने संबंधी कार्रवाइयाँ. अधिक जानकारी: सैंडबॉक्स परिवेश प्रबंधित करें
उत्पादन वह परिवेश, जहां ऐप्स और अन्य सॉफ़्टवेयर को उनके इच्छित उपयोग के लिए काम में लाया जाता है.
डेवलपर (औपचारिक रूप से Community कहा जाता है). Power Apps डेवलपर योजना आपको व्यक्तिगत उपयोग के लिए Power Apps प्रीमियम कार्यक्षमता, Dataverse, और Power Automate तक पहुंच प्रदान करती है. यह योजना मुख्य रूप से Power Apps, Power Automate, और Microsoft Dataverse या सीखने के उद्देश्यों के साथ निर्माण और परीक्षण करने के लिए है. डेवलपर परिवेश एक एकल-उपयोगकर्ता परिवेश होता है और इसका उपयोग उत्पादन ऐप्स को चलाने या साझा करने के लिए नहीं किया जा सकता.
डिफ़ॉल्ट प्रत्येक टैनेंट के लिए एक डिफ़ॉल्ट परिवेश स्वचालित रूप से बना जाता है और उस टैनेंट में सभी उपयोगकर्ताओं द्वारा साझा किया जाता है. टैनेंट उस ग्राहक की पहचान करता है, जिसके पास एक या अधिक Microsoft सदस्यताएँ और उससे संबद्ध सेवाएँ हो सकती हैं. जब भी कोई नया उपयोगकर्ता Power Apps के लिए साइन अप करता है, तो उसे डिफ़ॉल्ट परिवेश की निर्माता भूमिका में स्वचालित रूप से जोड़ दिया जाता है. डिफ़ॉल्ट वातावरण किरायेदार के डिफ़ॉल्ट क्षेत्र के निकटतम क्षेत्र Microsoft Entra में बनाया गया है और इसका नाम दिया गया है: "किरायेदार का नाम{Microsoft Entra (डिफ़ॉल्ट)"}
किसी विशिष्ट उद्देश्य, जैसे विकास, परीक्षण या उत्पादन के लिए सही वातावरण बनाएँ और उसका उपयोग करें.
परिवेशों पर अधिक जानकारी के लिए, परिवेशों का अवलोकन देखें.
किसकी पहुँच होनी चाहिए?
Microsoft Dataverse में अपने संसाधनों और डेटा की सुरक्षा को परिभाषित और प्रबंधित करें. Microsoft Power Platform कार्य करने के लिए परिवेश-स्तरीय व्यवस्थापक भूमिका प्रदान करता है. Dataverse में ऐसी सुरक्षा भूमिकाएँ शामिल होती हैं, जो ऐप्स, ऐप घटकों और संसाधन ऐप तक पहुँच के उस स्तर को परिभाषित करती हैं, जो Dataverse में निर्माताओं और उपयोगकर्ताओं की होती है.
| परिवेश उद्देश्य | ऐसी भूमिकाएँ, जिनकी पहुँच है | टिप्पणियाँ |
|---|---|---|
| विकास | ऐप निर्माता और डेवलपर. | ऐप उपयोगकर्ताओं की पहुँच नहीं होनी चाहिए. संसाधन बनाने के लिए डेवलपर को कम से कम परिवेश निर्माता सुरक्षा भूमिका की आवश्यकता होती है. |
| परीक्षण करें | ऐसे व्यवस्थापक और लोग, जो परीक्षण कर रहे हैं. | ऐप निर्माता, डेवलपर और उत्पादन ऐप के उपयोगकर्ताओं की पहुँच नहीं होनी चाहिए. बस परीक्षण करने के लिए परीक्षण उपयोगकर्ताओं के पास पर्याप्त विशेषाधिकार होने चाहिए. |
| उत्पादन | व्यवस्थापक और ऐप उपयोगकर्ता. उपयोगकर्ताओं के पास बस उन ऐप्स पर कार्य करने के लिए पर्याप्त विशेषाधिकार होने चाहिए, जिनका वे उपयोग करते हैं. | ऐप निर्माताओं और डेवलपर की पहुँच नहीं होनी चाहिए या केवल उपयोगकर्ता-स्तरीय विशेषाधिकार होने चाहिए. |
| डिफ़ॉल्ट | डिफ़ॉल्ट रूप से, आपके टैनेंट का प्रत्येक उपयोगकर्ता, डेटाबेस वाले Dataverse डिफ़ॉल्ट परिवेश में ऐप्स बना और संपादित कर सकता है. | हम पुरज़ोर अनुशंसा करते हैं कि आप किसी विशिष्ट उद्देश्य के लिए परिवेश बनाएँ और केवल उन लोगों को उचित भूमिकाएँ और विशेषाधिकार प्रदान करें, जिन्हें उनकी आवश्यकता है. |
और जानकारी:
- परिवेशों का अवलोकन
- परिवेश तक उपयोगकर्ता पहुँच नियंत्रित करें: सुरक्षा समूह और लाइसेंस
- उपयोगकर्ता बनाएँ और सुरक्षा भूमिकाएँ असाइन करें
- परिवेश बनाएँ
समाधान
समाधानों का उपयोग, एक परिवेश से दूसरे परिवेश में ऐप्स और घटकों को ले जाने के लिए किया जाता है या मौजूदा ऐप्स में अनुकूलनों के एक सेट को लागू करने के लिए किया जाता है.
समाधानों में ये सुविधाएँ मौजूद हैं:
उनमें मेटाडेटा और कॉन्फ़िगरेशन डेटा वाले कुछ निकाय शामिल होते हैं. समाधानों में कोई व्यावसायिक डेटा शामिल नहीं होता.
उनमें कई अलग-अलग Microsoft Power Platform घटक हो सकते हैं, जैसे मॉडल-चालित ऐप, कैनवास ऐप, साइट मानचित्र, प्रवाह, निकाय, प्रपत्र, कस्टम कनेक्टर, वेब संसाधन, विकल्प सेट, चार्ट और फ़ील्ड. ध्यान दें कि समाधान में सभी निकाय शामिल नहीं किए जा सकते. उदाहरण के लिए, एप्लिकेशन उपयोगकर्ता, कस्टम API और संगठन सेटिंग सिस्टम तालिकाओं को समाधान में नहीं जोड़ा जा सकता है.
वे एक इकाई के रूप में पैक किए जाते हैं, ताकि उन्हें अन्य परिवेशों पर निर्यात और आयात किया जा सके और परिसंपत्तियों के लिए स्रोत कोड के रूप में स्रोत नियंत्रण में विघटित और जाँचें जा सकें. मौजूदा समाधानों में परिवर्तन लागू करने के लिए भी समाधानों का उपयोग किया जाता है.
प्रबंधित समाधान का उपयोग किसी भी ऐसे परिवेश को परिनियोजित करने के लिए किया जाता है, जो उस समाधान के लिए डेवलपमेंट परिवेश नहीं है. इसमें परीक्षण, उपयोगकर्ता स्वीकृति परीक्षण (UAT), सिस्टम एकीकरण परीक्षण (SIT) और उत्पादन परिवेश शामिल हैं. किसी परिवेश में प्रबंधित समाधानों को अन्य प्रबंधित समाधानों से स्वतंत्र रूप से सेवित (नवीनीकरण, पैच और हटाना) किया जा सकता है. ALM सर्वोत्तम प्रथा के रूप में, प्रबंधित समाधान एक बिल्ड सर्वर द्वारा उत्पन्न किया जाना चाहिए और एक बिल्ड आर्टिफ़ैक्ट माना जाना चाहिए.
प्रबंधित समाधान अद्यतन, प्रबंधित समाधान के पिछले संस्करण पर परिनियोजित किए गए हैं. यह एक अतिरिक्त समाधान लेयर नहीं बनाता. आप अद्यतन का उपयोग करके घटकों को नहीं हटा सकते.
पैच में केवल पैरेंट प्रबंधित समाधान के लिए परिवर्तन शामिल होते हैं. आपको केवल छोटे अद्यतन (हॉटफ़िक्स के समान) करते समय पैच का उपयोग करना चाहिए और आपको संभवतया उसकी स्थापना रद्द करनी होगी. जब पैच आयात किए जाते हैं, तो वे मूल समाधान के शीर्ष पर लेयर किए जाते हैं. आप पैच का उपयोग करके घटकों को नहीं हटा सकते.
किसी समाधान का नवीनीकरण करने से, तुरंत आधार लेयर और किसी मौजूदा पैच के ऊपर एक नई समाधान लेयर स्थापित हो जाती है.
समाधान अद्यतन लागू करने पर, सभी मौजूदा पैच और आधार लेयर हट जाते हैं.
समाधान नवीनीकरण में वे घटक हटा दिए जाएंगे जो मौजूद तो हैं परंतु अब नवीनीकृत संस्करण में शामिल नहीं हैं.
अधिक जानकारी: समाधान अवधारणाएँ
स्रोत नियंत्रण
स्रोत नियंत्रण, जिसे संस्करण नियंत्रण भी कहा जाता है, एक प्रणाली है, जो सॉफ़्टवेयर डेवलपमेंट परिसंपत्तियों को बनाए रखती है और सुरक्षित रूप से उन्हें संग्रहित करती है और उन परिसंपत्तियों में परिवर्तनों को ट्रैक करती है. परिवर्तन ट्रैकिंग विशेष रूप से तब महत्वपूर्ण होती है, जब कई ऐप निर्माता और डेवलपर फ़ाइलों के एक ही सेट पर काम कर रहे होते हैं. स्रोत नियंत्रण प्रणाली आपको परिवर्तनों को वापस करने या हटाई गए फ़ाइलों को पुनर्स्थापित करने की क्षमता भी देती है.
स्रोत नियंत्रण प्रणाली, स्वस्थ्य ALM प्राप्त करने में संगठनों की मदद करती है, क्योंकि स्रोत नियंत्रण प्रणाली में बनाई रखी गई परिसंपत्तियाँ "सत्य का एकल स्रोत" होती हैं"—या दूसरे शब्दों में, आपके समाधान के लिए पहुँच और संशोधन का एकल बिंदु होती हैं.
ब्रांचिंग और मर्जिंग कार्यनीति
लगभग हर स्रोत नियंत्रण प्रणाली में कुछ तरह का ब्रांचिंग और मर्जिंग समर्थन शामिल होता है. ब्रांचिंग का मतलब है कि आप डेवलपमेंट की मुख्य रेखा से भटक गए हैं और मुख्य रेखा को बदले बिना काम करना जारी रखें. मर्जिंग की प्रक्रिया में एक ब्रांच को दूसरी ब्रांच से संयोजित करना शामिल होता है, जैसे कि डेवलपमेंट ब्रांच को मुख्य रेखा ब्रांच से संयोजित करना. ट्रंक-आधारित ब्रांचिंग, रिलीज़ ब्रांचिंग और सुविधा ब्रांचिंग, कुछ सामान्य ब्रांचिंग कार्यनीतियाँ हैं. अधिक जानकारी: Git ब्रांचिंग कार्यनीति अपनाएं
समाधान का उपयोग कर रही स्रोत नियंत्रण प्रक्रिया
स्रोत नियंत्रण प्रणाली में समाधान के साथ कार्य करते समय आप दो मुख्य पथ का उपयोग कर सकते हैं:
- अप्रबंधित समाधान निर्यात करें और उसे स्रोत नियंत्रण प्रणाली में अनपैक के रूप में रखें. निर्माण प्रक्रिया, अस्थायी निर्माण परिवेश (सैंडबॉक्स परिवेश) में अप्रबंधित के रूप में पैक्ड समाधान को आयात करती है. उसके बाद, समाधान को प्रबंधित के रूप में निर्यात करें और उसे अपनी स्रोत नियंत्रण प्रणाली में बिल्ड आर्टिफ़ैक्ट के रूप में संग्रहित करें.
- समाधान को अप्रबंधित के रूप में निर्यात करें और साथ ही समाधान को प्रबंधित के रूप में भी निर्यात करें और स्रोत नियंत्रण प्रणाली में दोनों को रखें. हालाँकि, इस पद्धति के लिए बिल्ड परिवेश की आवश्यकता नहीं होती है, लेकिन इसके लिए सभी घटकों की दो प्रतियों को बनाए रखने की आवश्यकता होती है (अप्रबंधित समाधान से सभी अप्रबंधित घटकों की एक प्रति और प्रबंधित समाधान से सभी प्रबंधित घटकों की एक प्रति).
अधिक जानकारी: उपकरण कार्य बनाएँ
स्वचालन
स्वचालन एप्लिकेशन जीवनचक्र का एक महत्वपूर्ण हिस्सा है, जो ALM की उत्पादकता, विश्वसनीयता, गुणवत्ता और दक्षता में सुधार करता है. स्वचालन उपकरणों और कार्यों का उपयोग सैंडबॉक्स परिवेश बनाने और रीसेट करने के अलावा, समाधानों को सत्यापित, निर्यात, पैक और अनपैक करने के लिए किया जाता है.
अधिक जानकारी: Microsoft Power Platform Build Tools क्या हैं?
साझा स्रोत नियंत्रण का उपयोग करने वाली टीम डेवलपमेंट
यह विचार करना महत्वपूर्ण है कि परियोजना को बनाने के लिए आप और आपकी डेवलपमेंट टीम एक-साथ कैसे कार्य करेंगे. साइलोज़ और फ़ोस्ट्रिंग दृश्यों और वार्तालाप को ब्रेक डाउन करना, बेहतर सॉफ़्टवेयर वितरित करने में आपकी टीम को सक्षम कर सकता है. कुछ उपकरण और कार्यप्रवाह—जैसे कि जो Git, GitHub और Azure DevOps—में प्रदान किए गए हैं, वे संचार और सॉफ़्टवेयर की गुणवत्ता में सुधार के एक्सप्रेस उद्देश्य के लिए डिज़ाइन किए गए थे. ध्यान दें कि एक समाधान प्रणाली में कॉन्फ़िगरेशन के साथ कार्य करना, टीम डेवलपमेंट के लिए चुनौतियां पैदा कर सकता है. जितना संभव हो उतना अधिक मर्ज विरोधाभासों से बचने के लिए, संगठनों को कई डेवलपर के परिवर्तनों को आर्केस्ट्रेट करना चाहिए, क्योंकि स्रोत नियंत्रण प्रणालियों की मर्ज करने के तरीके को लेकर कुछ सीमाएँ हैं. हम अनुशंसा करते हैं कि आप उन परिस्थितियों से बचें, जहां कई लोग जटिल घटकों में परिवर्तन करते हैं—जैसे एक ही समय पर प्रपत्र, प्रवाह—और कैनवास ऐप्स में परिवर्तन करना.
अधिक जानकारी: परिदृश्य 5: टीम विकास का समर्थन करना
निरंतर एकीकरण और परिनियोजन
आप किसी भी स्रोत नियंत्रण प्रणाली का उपयोग कर सकते हैं और निरंतर एकीकरण और निरंतर परिनियोजन (CI/CD) के साथ शुरू करने के लिए एक पाइपलाइन का निर्माण कर सकते हैं. हालाँकि, यह मार्गदर्शिका GitHub और Azure DevOps पर केंद्रित है. GitHub एक डेवलपमेंट प्लेटफ़ॉर्म है, जिसका उपयोग लाखों डेवलपर करते हैं. Azure DevOps कार्य की योजना बनाने, कोड डेवलपमेंट पर सहयोग करने और एप्लिकेशन बनाने और परिनियोजित करने में टीम की मदद करने हेतु डेवलपर सेवाएं प्रदान करता है.
प्रारंभ करने के लिए, आपको निम्न की आवश्यकता है:
एक GitHub खाता, जहाँ आप एक रिपॉज़िटरी बना सकते हैं. यदि आपके पास वह नहीं है, तो आप मुफ़्त में एक बना सकते हैं.
एक Azure DevOps संगठन. यदि आपके पास वह नहीं है, तो आप मुफ़्त में एक बना सकते हैं.
अधिक जानकारी: अपनी पहली पाइपलाइन बनाएं
लाइसेंसिंग
Power Apps और Power Automate का उपयोग करके ऐप्स और प्रवाह बनाने या संपादित करने के लिए, क्रमशः, उपयोगकर्ताओं को Power Apps या Power Automate के लिए प्रति-उपयोगकर्ता लाइसेंस की आवश्यकता होगी या एक उपयुक्त Dynamics 365 एप्लिकेशन लाइसेंस की आवश्यकता होगी. अधिक जानकारी के लिए, Microsoft Power Platform के लिए लाइसेंसिंग ओवरव्यू देखें. हम आपकी लाइसेंस आवश्यकताओं पर चर्चा करने के लिए आपको अपने Microsoft खाता प्रतिनिधि से संपर्क करने की भी सलाह देते हैं.
ALM विचार
जब आप Microsoft Power Platform पर ऐप्स बनाने के लिए ALM को एक अभिन्न हिस्सा मानते हैं , तो वह ऐप की गति, विश्वसनीयता और उपयोगकर्ता अनुभव में काफी सुधार कर सकता है. यह ये भी सुनिश्चित करता है कि कई डेवलपर, पारंपरिक डेवलपर लेखन कोड और नागरिक डेवलपर दोनों संयुक्त रूप से बनाए जाए रहे एप्लिकेशन में योगदान कर सकते हैं.
निम्न आलेख देखें, जो किसी ऐप डेवलपमेंट के शुरू होने पर विचार करने के लिए कई आइटम पर चर्चा करता है: