WEBVTT

00:00:00.340 --> 00:00:07.080
क्या आप Microsoft 365 Co-Pilot AI Azure और काम के भविश्य को आकार देने वाले लोगों के दस दिनों के लिए तैयार हैं?

00:00:07.880 --> 00:00:12.840
इस जन्वरी M365 कौन वापस आ रहा है और हम और भी बड़े स्तर पे आ रहे हैं हैं।

00:00:12.840 --> 00:00:18.740
लाइव सतरों वास्तविक दुनिया के डेमो और दुनिया भर के MVP और उद्धियों विशेशग्यों से व्यावारिक ज्यान के लिए हमसे जुड़े हैं।

00:00:18.740 --> 00:00:21.900
कोई समाने स्लाइड नहीं, कोई अंतहीन शब्द जाल लें।

00:00:21.900 --> 00:00:29.900
हम वास्तविक चुनौतियों का समधान कर रहे हैं कोपैलर्ट स्टुडियो, AI एजेंट, फैब्रिक, सुरक्षा, गवर्नेंस और आटोमेशन।

00:00:29.900 --> 00:00:35.900
चाहे आप IT प्रो हों, डेवलपर हों या बिजनस लीडर आपके लिए डिजाइन किये गए सत्र उपलब्द हैं।

00:00:35.900 --> 00:00:39.900
दस पूरे दिनों के साथ आप कई तकनीकों का पता लगा सकते हैं।

00:00:39.900 --> 00:00:43.900
लाइव देखें और अपने संगठन के लिए ब्याभारिक अंतरद्रिश्टी प्राप्त करें।

00:00:43.900 --> 00:00:51.900
जनवरी दोजार स्थाइस, दस दिन, एक माइक्रोसॉफ्ट समुदाए पंजी करन अब खुला है।

00:00:51.900 --> 00:01:04.900
आज ही अपना इस्थान सुरक्षित करें। वो है m365con.net अभी m365con.net पे जुड़ें और हम आपको जनवरी में लाइव देखेंगे।

00:01:04.900 --> 00:01:07.900
क्या कभी ऐसा लगा है कि आपके Power Platform Deployment एक Black Box की तरह है।

00:01:07.900 --> 00:01:12.900
क्या आप कोई अपडेट बेचते हैं, अपनी सांसे रोक लेते हैं और बस उम्मीद करते हैं कि ये Dev Test और Prod में काम करें।

00:01:12.900 --> 00:01:21.900
क्या हो अगर आप GitHub Actions का उपयोग करके अपनी ALM प्रक्रिया के हर चरण को वास्ता में नियंतरित और देख सकें बिना किसी अनुवान या Manual काम के, बिना किसी अनुवान के।

00:01:21.900 --> 00:01:28.900
आइए परदे से परदा उठाएं कि कैसे प्रते घटक, सोर्स कंट्रोल, आटोमेशन और सुरक्षित वेरियबल वास्ता में जुड़ते हैं।

00:01:28.900 --> 00:01:29.900
कि कि वह एक और वाक्तर नहीं है।

00:01:29.900 --> 00:01:34.900
यह वो क्यों है जिसे अधिकार्ज गईड शोड़ देती है, ताकि आपका अगला deployment आपको असमंजस में न डाले।

00:01:34.900 --> 00:01:37.900
तो Power Platform में LM एक भूल भूल लई है, जैसा क्यों लगता है।

00:01:37.900 --> 00:01:44.900
यदि आपने कभी Power App को deploy करने के कोशिश की है, और वो अनिशित्ता महसूस की है, जैसे कुछ math phone छूट गया हो, तो आप अखेले नहीं है।

00:01:44.900 --> 00:01:51.900
तागज पर Power Platform आसान app development का वादा करता है, लेकिन उस अनुकूर मुखोटे के बीछे ALM बिल्कुल भी सीधा नहीं है।

00:01:51.900 --> 00:01:58.900
एक web app source, control से deploy होता है, pipeline में बनता है, और अनुमानित वेवार के साथ production में उतरता है।

00:01:58.900 --> 00:02:07.900
दूसरी और, Power Platform, आधी logic को drag and drop UI connector screen और formula गे अंदर शिपा लेता है, जिसे आप किसी git repo में नहीं देख सकते हैं।

00:02:07.900 --> 00:02:11.900
इसलिए भले ही आप अनुचिस्तरी admin guide के हर चरण का पालन करें।

00:02:21.900 --> 00:02:23.900
और उसे कहीं और import करने के बारें बताएंगी।

00:02:23.900 --> 00:02:26.900
काफी सरल है न, लेकिन कैसे केवल एक परत है।

00:02:26.900 --> 00:02:28.900
वी जो छोड़ देते हैं, वो क्यों है।

00:02:28.900 --> 00:02:32.900
Power Platform deployment उन तरीकों से क्यों टूटता है, जो नेमित code में कभी नहीं होते।

00:02:32.900 --> 00:02:34.900
यही बात अंतहीन भ्रम पैदा करती।

00:02:34.900 --> 00:02:41.900
समस्या की जड़ यह है कि Power Apps में logic, connection और configuration classic code की तरह store नहीं होते हैं।

00:02:41.900 --> 00:02:44.900
आपके और repo clone करके unit test में ही देख रहे हैं।

00:02:44.900 --> 00:02:49.900
इसलिए जब आप अपना app move करने ही कोशिश करते हैं, तो Outlook, SharePoint, Custom API जैसी सभी चिपी होई ने बढ़ता हैं।

00:02:49.900 --> 00:02:57.900
हमेशा उस zip file में ठीक से नहीं जाती हैं। अपको देव environment में एक नया शांदार app मिल जाता है।

00:02:57.900 --> 00:03:02.900
आप एक solution export करते हैं, टेस्ट में import करते हैं। यह शायदी कभी के और file की समस्य होती।

00:03:02.900 --> 00:03:06.900
इसके बजाए connection गलत जगह पर point कर रहे होते हैं, अनुमधिया mail ने खाती हैं।

00:03:06.900 --> 00:03:11.900
और data नीतिया उन connection को block कर देते हैं, जो कुछ मिनिट पहले ठीक लग रहे थे।

00:03:11.900 --> 00:03:18.900
आप इसे तीन environment देव, test और prod में करने की कल्पना करें। जहां हर एक में अलग connection, data सुरक्षा नीतिया अनुमधन करता।

00:03:18.900 --> 00:03:23.900
और admin card का उप्योग होता है। आप copy paste करके इससे बहार नी निकल सकते।

00:03:23.900 --> 00:03:26.900
Research उन बातों की पुष्टी करते हैं, जो admin और makers हर हफते देखते हैं।

00:03:26.900 --> 00:03:33.900
जादे तर Wiffle power platform deployment, guide connector reference या गलत तरीके से प्रबंदित environment variables के कारण होते हैं।

00:03:33.900 --> 00:03:39.900
Connector reference guide होने का मतलब है कि flow अपना outlook या data words connection नहीं ढूण पा रहा है।

00:03:39.900 --> 00:03:45.900
इसलिए जिस मिनट आप किसी अन्य environment में अपना app या flow चलाने की कोशिश करते हैं, आपको runtime error बिलते हैं।

00:03:45.900 --> 00:03:54.900
और क्योंकि power platform में environment variables अन्य Microsoft 365 उतपादों की तुलना में अलग तरसे काम करते हैं, वे अनुभवी developers को भी उचा देते हैं।

00:03:54.900 --> 00:03:58.900
Variables को endpoints, keys या tenant vicious config को संभालने के लिए बनाया गया है।

00:03:58.900 --> 00:04:05.900
लेकिन अगर कोई solution एक्सपोर्ट करने के बाद उन्हें अपडेट करना भूल जाता है, तो एक मामुली बदलाव भी live app को तोड़ सकता है।

00:04:05.900 --> 00:04:08.900
हमेंसे बहुत से लोग शुरुवात में एक ही जाल में फस जाते।

00:04:08.900 --> 00:04:13.900
आप सोच सकते हैं कि solutions एक्सपोर्ट करने से सब कुछ बंडल हो जाता है, लेकिन ये वास्तव में dynamic connector reference को छोड़ देता है।

00:04:13.900 --> 00:04:18.900
उधारन के लिए मालने कि आपके पास एक app है जो देव में 3rd party service के लिए STP connector का उप्योग करता है।

00:04:18.900 --> 00:04:22.900
जब आप test या prod में import करते हैं तो वो static connector instance मौझूद नहीं होगा।

00:04:22.900 --> 00:04:34.900
आपके app के अंदर का connector reference एक guide object को point करता है और solution के अंदर के flow चुप चाप तब तक काम करना बंद कर देते हैं जब तक कोई user या admin manual रूप से connection को फिर से नहीं बिनाता और map नहीं करता।

00:04:34.900 --> 00:04:43.900
यदि आपके पास एक से अधिक मेकरिया admin है तो ये track होना और भी आसान है कि कौन सा reference कहा जाता है और कोई भी उस ये देव में काम कर रहा था वाली स्थिति में नहीं पढ़ना चाहता।

00:04:43.900 --> 00:04:46.520
एक और समस्या, service principles

00:04:46.520 --> 00:04:52.520
जादतर लोग solution export और import करने के लिए user account का उप्योग करना शुरू करते हैं क्योंकि ये शुरू करने के लिए तेज है।

00:04:53.520 --> 00:04:59.520
लेकिन जब आप किसी वेक्ति के credentials का उप्योग करके GitHub Actions या किसी CI सिस्टम के साथ automate करने के कोशिश करते हैं तो ये जल्दी ही रुख जाता है।

00:04:59.520 --> 00:05:09.520
आप permission wall से टकराएंगे कभी-कभी बिना spaced error message के या अनुपालन audit भी शुरू हो सकते हैं क्योंकि आप automation के लिए बने किसी साधन के बजाए वेक्तिगत account के तहत महतुपून deployment चला रहे हैं।

00:05:09.520 --> 00:05:18.520
Service principles जो मूल रूप से Azure AD में बनाएगा app identity हैं आपके pipeline के लिए आवश्यक सभी अनुमतियों, longing और auditing का प्रबंधन करते हैं।

00:05:18.520 --> 00:05:25.520
इनके मिना आपकी automation प्रप्रिया वेक्ति दर्वेक्ति हस्तांतरन का एक बिखरा हुआ जाल बन जाती है और आपको कभी पता नहीं चलता कि किसने क्या बदलाब किया।

00:05:25.520 --> 00:05:27.520
Source Control भी अनिश्चित्थिती बन जाता है।

00:05:27.520 --> 00:05:31.520
समान्य code के साथ आपके पास commit history और blame tools होते हैं।

00:05:31.520 --> 00:05:36.520
केवा platform solution file हैं केवल snapshot दिखाती हैं जिसका अर्थ है कि आप विस्तर change tracking हो देते हैं।

00:05:36.520 --> 00:05:43.520
के अन्वास app के screen formula में छिपा हुआ logic या कम दस्तावीजी करने वाले flow तब तक दिखाई नहीं देते जब तक आप उन्हीं दुबारा export ना करें।

00:05:43.520 --> 00:05:49.520
रहें। यदि को UI में flow setting बदल देता है तो यह पता लगाना मुश्किल हो जाता है कि downstream वातावरन अचानक अलग तरह से वेवहार क्यों कर रहे हैं।

00:05:49.520 --> 00:05:57.520
इसका प्रिणाम यह है कि power platform के लिए ARM का प्रबंधन करना एक ऐसी पहली सुजाने जैसा लगता है जिसके आदे टुपड़े काईब हैं या कम से खम box के नीचे छिपे हैं।

00:05:57.520 --> 00:06:06.520
अद्रिशन वरताएं, वातावरन विशिस्ट कनेक्टर और variable जिने आप code में नहीं देख सकते सामाने developer workflow को प्रभावित करते हैं।

00:06:06.520 --> 00:06:16.520
और ये सब तो तब है जब आप उत्पादन वातावरन की विशिक तनुमतियों, अलग डेटा नीथियों और audit आविशक्ताओं का सामना करते हैं जो development ये test में इस पश्ट नहीं होती हैं।

00:06:16.520 --> 00:06:20.520
लेकिन इसका एक सकारात मत पहलुए ये जटिलता यादरचिक नहीं है।

00:06:20.520 --> 00:06:27.520
इसके पीछे एक व्यावाहरिक कारण है कि power, platform, source, variable और connector को इतने अनोखे तरीके से क्यों संभालता है।

00:06:27.520 --> 00:06:32.380
ये व्यावसाइक उप्योग करताओं को code की चिंता कि ये बिना शक्ति-शाली app बनाने की सुविधा देता है।

00:06:32.380 --> 00:06:38.640
इसका एक दुश्प्रभाव ये है कि automation setup करने वाले व्यक्ति के रूप में आपको पर्दे के पीछे चिपीची जीजों पे नज़र रखनी पड़ती है।

00:06:38.640 --> 00:06:46.800
यदि आप जानते हैं कि वे अद्रिश्यतार कहां जोड़े हैं तो आप उन अधिकान शक्रतियों को सुधार सकते हैं या उनसे बस सकते हैं जो power platform ALM को पट्री से उतार देती हैं।

00:06:46.800 --> 00:06:54.000
यदि ये सब संभालने में बहुत अधिक लगता है तो आप गलत नहीं हैं। लेकिन चार ALM स्थम हैं जो वास्ता में इस उल्जन को सुलजाने में मदद करते हैं।

00:06:54.000 --> 00:07:15.000
जब भी कोई power platform pipeline के लिए खहता है जो सही धंग से काम करें तो सबसे पहले उन चार ALM स्थम्भों का ही ख्याल आता है source, build, test, deploy।

00:07:16.000 --> 00:07:19.000
पारमपरिक development जगत में आप इने नीन में भी कर सकते थे।

00:07:19.000 --> 00:07:24.000
पार प्लेटफर्म आपको इतनी आसानी से नहीं छोड़ता। अचानक source का मतलब code नहीं रह जाता।

00:07:24.000 --> 00:07:33.000
इसका मतलब है solution फाइलों से जूजना apps flow और कभी-कभी उन connectors के zip बंडलों को export करना जो source का हिस्सा होने का दिखावा करते हैं।

00:07:33.000 --> 00:07:35.000
आए बुनियादी बातों से शुरू करें।

00:07:35.000 --> 00:07:38.000
और फिर देखें कि इस दुनिया में प्रतिक स्तंबु को क्या चीज़ थोड़ा जीब बनाती है।

00:07:38.000 --> 00:07:40.000
आपके बास अपनी solutions जिफ फाइल होती है।

00:07:40.000 --> 00:07:42.000
इस हमाने अर्थों में code नहीं है।

00:07:42.000 --> 00:07:45.000
इसे खोलें और आपका स्वागत XML और JSON फाइले करते हैं।

00:07:45.000 --> 00:07:48.000
कि वो लॉजिक जो आपको टाइप स्क्रिप्ट जैसी स्ट में दिखता है।

00:07:48.000 --> 00:07:50.000
लेकिन पावर प्रेटफॉर्म के लिए यह सूर सूर सूर।

00:07:50.000 --> 00:07:52.000
टी में अकसर यहीं उलच जाती है।

00:07:52.000 --> 00:07:56.000
यह पोर्टेबल लगता है जब तक आपको यहसास नहों कि अधिकांच बदलाओ।

00:07:56.000 --> 00:07:59.000
जैसे स्क्रीन में फॉर्मुला अप्डेट करना है या फ्लो का लॉजिक बदलना।

00:07:59.000 --> 00:08:02.000
नई solutions जब एक्सपोर्ट करने तक सपष्ट नहीं होते।

00:08:02.000 --> 00:08:10.000
तो हाँ आप इन solution फाइलों को git में वर्शन कर सकते हैं लेकिन जब तक आप हर ज़रूरी बदलाओ के बाद एक्सपोर्ट करने में अनुशासत नहीं है तब तक आपकी इतिहास में बड़ी खामिया होंगी।

00:08:10.000 --> 00:08:12.000
अब बात करते configuration की।

00:08:12.000 --> 00:08:17.000
समानने apps के लिए आप connection strings को config file में store करके काम चला सकते हैं।

00:08:17.000 --> 00:08:21.000
Power Platform and Solutions के अंदर environment vicious data को शिपा कर ले जाता है।

00:08:21.000 --> 00:08:29.000
यह सिर्फ environment variables नहीं बलकि connector reference, dynamic and points, role और अनमतियां हैं जो business logic के साथ bundle की गई होती हैं।

00:08:29.000 --> 00:08:36.000
यदि आप Dave ये test से export करने से पहले इन्हें update करना भूल जाते हैं तो आप गलज जगा के pointers को lock कर रहे होते हैं।

00:08:36.000 --> 00:08:39.000
मैंने टीमों को अपनी solution zip file में पूरी निष्ठा से commit करते देखा है।

00:08:39.000 --> 00:08:48.000
लेकिन deployment के बाद पता चलता है कि उनका आधा app अभी भी prod के बजाए Dave डिटावर से बात कर रहा है क्योंकि किसी ने connector reference को remap नहीं किया, क्योंकि किसी ने connector reference को remap नहीं किया।

00:08:48.000 --> 00:08:50.000
फिर हमारे पास build है।

00:08:50.000 --> 00:08:55.000
Build शब्द आम तोर पर code को compile करने और CI job में हरे निशान देखने की छवी लाता है।

00:08:55.000 --> 00:09:02.000
Power platform के साथ build प्रक्रिया का मतलब उन zip बंडलों को सहेजना, schema के दुबारा जाच करना और dependency को सत्यापित करना है।

00:09:02.000 --> 00:09:12.000
GitHub actions pipeline में एक build job आपकी commit की गई solution फाइल लेती है, फिर Microsoft के power platform CLI का उप्योग करके solution को unpack, validate और repack करती है।

00:09:12.000 --> 00:09:18.000
Validation step वोई है, जहाँ जादू या गड़बड होती है। यह टूटे वी reference या समर्थेद actions को पकड़ सकता है।

00:09:18.000 --> 00:09:26.000
इससे में पूरा यह है कि यदि आपके flow में कोई मदलाव किसी custom connector पर निरभर है जो source control में कभी आए नहीं, तो आपका build चुपचाप कुछ अधूरा pack कर देता है।

00:09:26.000 --> 00:09:28.000
यहीं पर चीज़े पेचीदा हो जाती है।

00:09:28.000 --> 00:09:36.000
वे build jobs compile करने के बारे में कम और एक विश्वसनी export को गिवस्तित करने और यह सुनिश्चित करने के बारे में अधिक हैं कि अंदर की समगरी ship करने योग्य है।

00:09:36.000 --> 00:09:41.000
जो टी में इसे छोड़ देती हैं, जल्द वाजी करती हैं, वे जल्द ही, एसे इस्तिती में आजाती हैं, जहां भी लिटकनी की रूप से सफल होता है।

00:09:41.000 --> 00:09:45.000
लेकिन यूए टी अप्राइड में जो पहुँचता है, उसमें आधे फीचर्स गाइब होता है।

00:09:45.000 --> 00:09:50.440
Microsoft इस संदेश को बढ़ावा देता रहता है कि solution फाइले ALM को portable बनाती हैं, लेकिन हमेशा एक footnote होता है।

00:09:50.440 --> 00:09:55.320
Portability इस बात पर निर्भर करती है कि connectors सही तरीके से map किये गए हों और roles सभी environments में set up हों।

00:09:55.320 --> 00:09:57.000
Testing अगला source बटन है।

00:09:57.000 --> 00:10:02.440
Web App Pipeline में सचाले test, unit test या UI check चला सकते हैं।

00:10:02.440 --> 00:10:05.440
Power Platform के लिए क्या test माना जाएगा ये बहस का विशह है।

00:10:05.440 --> 00:10:12.440
कभी-कभी ये solution validation होता है, दूसरे शब्दों में क्या solution खुलता है और क्या मुख्य dependency हल होती है।

00:10:12.440 --> 00:10:18.440
अन्ने समय में ये test flow चलाना ये जांचना होता है कि connectors test environment में प्रतिक्रिया दे रहे हैं या नहीं।

00:10:18.440 --> 00:10:24.440
अक्सर testing manual होती है क्योंकि canvas app के अंदर business logic को validate करना अभी automated pipeline से नहीं जुडा है।

00:10:24.440 --> 00:10:33.440
लेकिन आप guy app connectors का पता लगाने महतुपून flow को validate करने या credentials काम कर रहे हैं ये जांचने के लिए test environment को pink करने जैसे check को automate कर सकते हैं।

00:10:33.440 --> 00:10:35.440
deployment के समय मुश्किलें बढ़ जाते हैं।

00:10:35.440 --> 00:10:39.440
जब कोई standard app deploy होता है तो आप शायद बस एक web artifact को Azure को push करते हैं।

00:10:39.440 --> 00:10:45.440
Power platform के साथ आपको connections map करने, अनुमतिया sign करने, secrets update करने, environment variables बदलने

00:10:45.440 --> 00:10:49.440
और अंत में service principle का उप्योग करके import trigger करना होता है न कि किसी समानी account का

00:10:49.440 --> 00:10:52.440
अन्य था आप audit और अनुमतिन न मिलने की समस्याओं में फस जाएंगे।

00:10:52.440 --> 00:11:00.440
GitHub actions, GitHub actions इस प्रक्रिया को एक साथ जोड सकता है लेकिन तब ही जब हर जौब को पता होगी किस environment को target करना है और कौन से secrets का उप्योग करना है।

00:11:00.440 --> 00:11:10.440
मैंने टीमों को देव और प्रॉड के बीच एक ही credential सेट का उपयोग करके shortcut लेते देखा है जो अराजकता, data leak, अनुम्मती संबंधी त्रूटियों और केवल एक environment में दिखने वाले खराब features को न्योता देता है।

00:11:10.440 --> 00:11:13.440
कुछ महीने पहले मेरे साथ काम करने वाले class 15 का उधार।

00:11:13.440 --> 00:11:20.440
उन्होंने जाधातर काम सही किये थे जैसे standard git repose, version solution zip और spust branching लेकर उनकी pipeline हमेशा deployment के समय फेर रजा देते।

00:11:20.440 --> 00:11:26.440
उन्होंने prod में import करने से पहले environment variables को बदलना या connector reference को update करना कभी ज़रूरी नहीं समझा।

00:11:26.440 --> 00:11:31.440
इसे मुख्य flow गलत endpoints पे point करने लगे और data गलत systems में जाने लगा।

00:11:31.440 --> 00:11:37.440
समधान ये था कि उनकी github pipeline में ऐसे scripted steps चोड़े जाएं जो import के समय variables बदले और हर connector को remap करें।

00:11:37.440 --> 00:11:40.440
Microsoft का अपना मानुदाशन इस बारे में सपष्ट है।

00:11:40.440 --> 00:11:43.440
Environment की भी चीजों को ले जाने के लिए solution files का उपयोग करें।

00:11:43.440 --> 00:11:47.440
लेकिन connector reference और role mapping को हमेशा अपनी pipeline का हिस्सा बनाए।

00:11:47.440 --> 00:11:51.440
उनका कहना है कि इन steps को छोड़ना apps को खराब करने का सबसे बड़ा कारण है।

00:11:51.440 --> 00:11:53.440
खास कर जब environment अधिक सुरक्षित हो जाते हैं।

00:11:53.440 --> 00:11:58.440
एक बार जब आप source, build, test और deploy को अलग-लग steps के बजाए जुड़े हुए हिस्सों की रूप में देखते हैं।

00:11:58.440 --> 00:12:02.440
तो यह समझना आसान हो जाता है कि इतने सारे ALM प्रयास क्यों विफल होते हैं।

00:12:02.440 --> 00:12:07.440
प्रातना करने के बजाए वास्तना करने के बजाए वास्ता में समस्याओं का निवारिन कैसे कर सकते हैं।

00:12:07.440 --> 00:12:11.440
आगे, आएए जाने कि कैसे GitHub Actions इस पूरी प्रक्रिया को विवस्तित करता है।

00:12:11.440 --> 00:12:17.440
जिसमें Triggers, Branching और Jobs Separation शामिल हैं जो आपके Power Platform, Automation को लचीला और सुरक्षित रखते हैं।

00:12:17.440 --> 00:12:20.440
GitHub Actions, Triggers और Jobs के साथ चीज़ों को जोड़ना।

00:12:20.440 --> 00:12:28.440
यदि आपना Power App Update करने के बाद GitHub Actions Pipeline के पूरा होने का इंतजार किया तो आप पहले सी जानते हैं कि Automation का मतलब तुरंद नहीं है और निश्ची तुरूप से इसका मतलब तुरंद नहीं है और निश्ची तुरूप से इसका मतलब जदू नहीं है।

00:12:28.440 --> 00:12:58.420
ज़्यादा तर टीमें अपने पहले workflow run को देखने के उत्सा के तुरंद बाद इस बादा का सामना करती हैं।

00:12:58.440 --> 00:13:08.440
ज़्यादा तर नए लोग ऐसा workflow बनाते हैं जो हर push पर या main branch में pull request आने पर चलता है।

00:13:08.440 --> 00:13:13.440
उपर से देखने पर ये बहतरी नतरी करते हैं। क्यों नहीं हर बार काम बदलने पर अपना pipeline करें। या एक pench है।

00:13:13.440 --> 00:13:17.440
जब आपके वाल main पर trigger set करते हैं तो सब कुछ एक ही रास्ते से ओके गुजरता है।

00:13:17.440 --> 00:13:19.440
क्या होगा अगर बदलाव के वाल dev में जाने चाहिए, test या prod में नहीं।

00:13:19.440 --> 00:13:23.440
क्या होगा अगर आप prod में push कर निकले त्यार हैं लेकिन test अभी भी validation कर रहा है।

00:13:23.440 --> 00:13:28.440
जो टीमें एक ही तरह का trigger का इस्तिमाल करती हैं उन्हें ऐसी समस्याओं का सामना करना पड़ता है।

00:13:28.440 --> 00:13:34.440
जहां development के लिए बने features production में आ जाते हैं या test deployment गलती से prod settings को override कर देते हैं।

00:13:34.440 --> 00:13:38.440
आप हर environment dev test और prod के लिए अलग workflow मना सकते हैं।

00:13:38.440 --> 00:13:41.440
और हर एक के लिए विशिश trigger set कर सकते हैं।

00:13:41.440 --> 00:13:45.440
उधारन के लिए एक workflow set करें जो किवल डेव branch में push होने पर चले।

00:13:45.440 --> 00:13:49.440
या जब कोई हर release prod में merge करें तो एक अलग workflow शुरू हो।

00:13:49.440 --> 00:13:54.440
यह दृष्टी को अधिक नेंतरन देता है और चल रहे काम बलाएं बदलाओं के वीच एक पश्च सीमा बनाता है।

00:13:54.440 --> 00:13:57.440
लेकिन कई इस पश्च सीमा बनाने के बाद अपने triggers को दुबारा नहीं देखती।

00:13:57.440 --> 00:14:01.440
इसी वज़े से एक environment के secrets दूसरे में चले जाते हैं।

00:14:01.440 --> 00:14:05.440
और डेव के लिए बनी configuration गलती से प्राउड में पहुंच जाती है।

00:14:05.440 --> 00:14:10.440
मेरे साथ काम करने वाली एक टीम ने अपनी पूरी LM प्रक्रिया एक ही workflow से चलाने की कोशिश की।

00:14:10.440 --> 00:14:21.440
कुछ समय तक सब ठीक लगा, जब तक किसी ने ध्यान नहीं दिया कि production, database, connection, string, dev environment में दिख रही थी, उन्हें आहसास ये नहीं हुआ कि उनके secrets jobs के बीच साज़ा हो रहे थे।

00:14:21.440 --> 00:14:24.440
और जैसे ही code environment के बीच move हुआ, वे secrets भी साथ में लीख हो गया।

00:14:24.440 --> 00:14:34.440
इस तरह का data leak आपकी सोच से कहीं अधिक समाने है, खास करें दिया, आप अपने workflow में secrets और environment variables को अलग न करें।

00:14:34.440 --> 00:14:39.440
GitHub Actions workflow का प्रतेक job प्रक्रिया के एक सबस्च हिस्से को संभालता है।

00:14:39.440 --> 00:14:51.440
एक job source environment से solution export कर सकता है, जबकि दूसरा job validation, unpacking, solution, metadata को scan करने, सभी dependencies की जाच करने, और ये सुनिश्चित करने का काम करता है कि connector reference मौझूद है।

00:14:51.440 --> 00:14:58.440
और अगला job वो आता है, जो environment vicious variables तैयार करता है, ताकि solution अपने target environment के अनुरूप हो सके।

00:14:58.440 --> 00:15:17.440
अन्तिम job service principles का उप्योग करके import प्रक्रियर शुरू करता है, ताकि बतलाव सही environment में लिखे जा सके हैं।

00:15:17.440 --> 00:15:19.440
लेकिन वे कभी भी सिवाओं के पार leak नहीं होने चाहिए।

00:15:19.440 --> 00:15:29.440
पावर platform ALM-ALM में आपके पास प्रतेक वातावरं के लिए एक अलग dataverse connection हो सकता है, या आपके इस flow या power app को लक्षित कर रहे हैं, उसके अधार पर आपको endpoints को swap करना पड़ सकता है, उसके अधार पर आपड़ सकता है।

00:15:29.440 --> 00:15:36.440
यदि आप variables का पुनुप्योग करते हैं या secrets को, hardcode करते हैं तो अंतता आपके पास एक कमजोर pipeline है, उससे भी बत्तर गंबीर सुरक्षा जोखिम होंगे।

00:15:36.440 --> 00:15:44.440
आयात प्रिक्रिया केवल सही वाल्ड से secrets कीशने पर निर्भर करती है, ताकि production वातावरन टेस्टिया डेव की कल्थियों से उजागर न हो।

00:15:44.440 --> 00:16:14.440
GitHub Actions में secrets के लिए एक अच्छा मालसिक मॉडल ये है कि प्रतेक वातावरन को अपने डिजिटल वाल्ड की रूप में देखें, एक ऐसा lockbox जिसे के वल सही जॉप सी देख सकती हैं, GitHub आपको सटिक नेंतर प्रदान करता है, आप secrets को वातावरन के अनसार सीमित कर सकते हैं ताक

00:16:14.440 --> 00:16:44.440
स्वरक्षा नेमों और सक्ट secrets scoping के सिला देते हैं, ताकि Cross Environment League को शुरू होने से पहले ही रोका जा सके, इस तरह की स्वरक्षा के बिना सबसे बहतर डिजाइन किये गए, ALM workflows भी विफल हो जाते हैं, कल्प ना करें कि एक workflow prod में तैनात हो रहा है और उसमें अभी भी Dave connection string है य

00:16:44.440 --> 00:17:14.440
नहीं हैं, वे सुरक्षा जाल हैं जो आपकी automation को चुप चाब विफल होने से बचाते हैं, वर्कफ्लोस को विबाजित करने में भी मुल्य है, नकिवल वातावरन के आधार पर बलकी जिम्मेदारी के आधार पर, जो code solutions को export और validate करता है, उसे ये भी नहीं पता होना चाहिए

00:17:14.440 --> 00:17:44.440
ये समझना की कैसे GitHub Action Secrets को सीमित रखते हुए और Triggers को सपष्ट रूप से परिभाशित करते हुए एक जौब से, दूसरी जौब में काम सौपते हैं, एलम को एक आशाजनक प्रयोग से, एक विश्वसनिय सुरक्षित और पूर्वानमानित अभ्यास में बदल देता है, ये

00:17:44.440 --> 00:18:14.440
Automation के मार्थ हम से एक साथ काम कर रहे हैं, तो समय आ गया है कि हम घर्शन के एक और बिंदू का समाधान करें, Connectors, Service Principles और पे छोटी मगर महत्मों बाधा हैं, जो आपके आत्म विश्वास के समय ही आपके deployment को रोख सकती है, कुप्त, Service Principles और Connectors से जुड़ी समझ से आएं, य

00:18:14.440 --> 00:18:44.440
तक सीमित नहीं है, हर power platform admin को आखिकार इस समस्या का सामना करना पड़ता है, समस्या की जड़ इस बात में है कि background में Connectors और Secrets कैसे काम करते हैं, आपके वल development से solution जिप export करके ये उमीद नहीं कर सकते कि वो कहीं और काम करेगा, क्योंकि जिन तारों पर ये निरभर है, वे हर environment क

00:18:44.440 --> 00:19:14.440
अपना solution export करते हैं, तो connector reference भुकमा की तरह काम करते हैं, वे उन connection objects की और इशारा करते हैं, जो केवल उसी environment में मौझूद होते हैं, जहां उने बनाया गया था, इसलिए जब आप test या prod में import करते हैं, तो आपका शांदार HTTP endpoint या dataverse link ज़रूरी नहीं, कि उसी तरह या बिल्क�

00:19:14.440 --> 00:19:44.440
बहुत से लोग environment के बीच user credentials साजा करके इससे बचने की कोशिश करते हैं, उन्हें लगता है कि यदि आप उसी account या password का उपयोग करें, जिससे डेव में connection बनाया गया था, तो शायद ये prod में काम कर जाए, अनमतियस भी का यह है कि ये कई समस्याओं को नहीं होता देता है, �

00:19:44.440 --> 00:20:14.440
इसमें कोई सबस्ट जवाब दे ही नहीं होती, और जब मूल user को flag किया जाता है, हटा दिया जाता है, या उसका access खतम हो जाता है, तो अनमतियां pipeline को block कर देती हैं, अब आद करते हैं service principle, यदि आपने उनके साथ काम नहीं किया है, तो service principle को automation के लिए विशेश रूप से बना

00:20:14.440 --> 00:20:44.440
पड़े हैं, किसी ऐसे user पर निर्भर रहने के बजाए, जो संगठन छोड़ सकता है, या पुमिका बदल सकता है, deployment सो संगठ, audit योग्या, और trust करने योग्य बने रहते हैं, हर environment को केवल सही connections और resources का access मिलता है, और कोई भी बदला, इसी robot account के ताहट log किया जाता है, log किया ज

00:20:44.440 --> 00:21:14.440
inbox API API से जुड़ता है, जब पूर्ट पर जाने का समय आता है, तो वो connector के बगाय भी नहीं होता, बलकि हो सकता है कि संगठ नात्मक डेटा नीतियां, इसकी अनुमती भी न दे, यदि आप remap करना भूल जाते हैं, तो app गलत endpoint को call करता है, या पूरी तरह से खराब हो जाता है

00:21:14.440 --> 00:21:44.440
जब तक की गलत पाइपों के माधियम से वास्तविक data प्रवाहित नहीं होने लगा, जब तक की गलत पाइपों के माधियम से वास्तविक data प्रवाहित नहीं होने लगा, environment variables इस परशानी को कुछ हध तक कम करने में मदद करते हैं, endpoints या API API कीज को hard coding करने के विए, pre-it environment variables आ�

00:21:44.440 --> 00:21:47.200
प्रोट टेबल का उप्योग करने के लिए configure किया जा सकता है।

00:21:47.200 --> 00:21:50.640
वई, GitHub Actions Pipeline इसे वैवरिक बला दी है।

00:21:50.640 --> 00:21:53.800
प्रतिक जॉब सही समय पर सही value डाल सकती है।

00:21:53.800 --> 00:21:55.960
लेकिन यहां भी अनुशासन ही कुझी है।

00:21:55.960 --> 00:22:02.600
किसी variable को update करना भूल जाएं या secrets को environment की बीच leak होने दें और अचानक आपका workflow expose हो जाता है।

00:22:02.600 --> 00:22:09.800
Microsoft secrets को साथधानी पूरवक scope करने और connector reference को जानबूच कर मैप करने की आवश्यक्ता पर जोर देता है।

00:22:09.800 --> 00:22:17.800
उनकी DLP data loss prevention नीतियां एक कारण से मौजूद हैं ताकि समवेधन शील जानकारी को environment के बीच भटकने या गलत जगह पर सामने आने से रोका जा सके।

00:22:17.800 --> 00:22:26.800
यदि आप variables या connections को साजा करके इने बाइपास करने के कोशिश करते हैं तो आप corporate सुरक्षा या अनुपालन नियंतरणों में फज जाएंगे।

00:22:26.800 --> 00:22:44.800
इससे भी महतुन बात यह है कि आप पूर्वान वान लगाने के शमताख हो देते हैं क्योंकि आप डिप्लाइमेंट पूर्वान वानित हो जाती है।

00:22:44.800 --> 00:22:49.100
जब चीज़े खराब होती हैं तो आपके पास custody की एक specification लाहते हैं और आप जानते हैं कि वास्ता में कहां देखना है।

00:22:49.100 --> 00:22:52.800
क्या ये एक connector mapping थी, कोई variable था या कोई छूटी हूई अनुमती थी।

00:22:52.800 --> 00:22:57.800
auditor बदलावों को track कर सकते हैं और जब कोई संगठन छोड़ता है या password बदलता है तो कोई अनिश्यता नहीं रहती।

00:22:57.800 --> 00:23:01.800
ये सब secrets, connectors और service principles को ऐसे संभालने पर आता है जैसे कि वे महतपूर हूँ।