Lahenduste korraldamine

Enne lahenduste loomist võtke aega, et planeerida oma keskkonnastrateegia ja lahendusstrateegia. Mõelge järgmistele aspektidele:

Aspekt	Kaalutlus
Rakenduse ulatus	Kas teie juurutus hõlmab mitut rakendust, nagu müük, klienditeenindus, väliteenindus, rahandus jne?
Väljaandmise sagedus	Kui sageli kavatsete värskendusi tootmisse juurutada? Kas teie tarnemetoodika põhineb agiilsetel tavadel, nagu sprinditsüklid?
Tootmise tugi	Kuidas käsitleda kiireloomulisi parandusi tootmises ilma uusi funktsioone enneaegselt kasutusele võtmata?
Lahenduse arhitektuur	Mitut lahendust haldate? Kas need lahendused jagavad komponente või sõltuvad üksteisest?
Keskkonna planeerimine	Mitut Microsoft Dataverse keskkonda vajate oma arenduse elutsükli toetamiseks? Kas vajate arendamiseks, testimiseks ja tootmiseks eraldi keskkondi? Kas arendajad teevad koostööd jagatud keskkonnas või vajavad nad iseseisvaks töötamiseks isoleeritud keskkondi?

Järgmistes jaotistes kirjeldatakse kolme strateegiat, mis on paigutatud kõige lihtsamast kõige keerukamani, ning tuuakse välja nende vastavad eelised ja puudused.

Ühe lahenduse strateegia

Kõik kohandused rühmitatakse arenduse käigus üheks mittehallatavaks lahenduseks, mis eksporditakse hiljem juurutamiseks ühe hallatava lahendusena.

Soovitatav:

• Väikesed-keskmise ulatusega rakendused
• Stsenaariumid, mille puhul tulevane modulariseerimine on ebatõenäoline

Eelis	Puuduseks
Lihtsustatud keskkonna seadistamine ja haldamine.	Nõuab rohkem pingutusi, et vajadusel hiljem skaleerida või modulariseerida.
Lihtsustatud juurutamine. Kuna haldamiseks on ainult üks lahendus, on keskkondade vahel eksportimine ja importimine lihtne ja vähem veaohtlik.	Üks lahendus, mis sisaldab suurt hulka kohandusi, võib kaasa tuua pikema juurutusaja. Lahenduse suuruse vähendamiseks kasutage tabeli segmenteerimist. Impordiaja lühendamiseks minge toimivussoovituste lehele.
Muudatuste leidmine, auditeerimine ja haldamine on lihtsam.	Kui samas arenduskeskkonnas töötab mitu arendajat, riskivad nad üksteise muudatused üle kirjutada. Seda riski saab vähendada, rakendades lähtekoodi versioonimist, võttes kasutusele hargnemisstrateegia ja kasutades iga haru jaoks spetsiaalset arenduskeskkonda. Lähtekoodi versioonimine ja hargnemisstrateegia pakuvad muudatuste jälgimist, koostöötuge ja konfliktide lahendamise mehhanisme. Lisateave: Giti hargnemisstrateegia kasutuselevõtt.

Märkus.

Microsoft Power Platformi hiljutised täiustused on vähendanud hallatavate lahenduste, sealhulgas täiendusvõimalust kasutavate lahenduste impordiaega. Need optimeerimised hõlmavad komponentide sõltuvuste paremat käsitlemist ja muutumatute komponentide väiksemaid üldkulusid. Teavet selle kohta, kuidas nendest täiustustest kasu saada, leiate jaotisest Toimivussoovitused.

Mitu lahendust samas arenduskeskkonnas

Ühes arenduskeskkonnas hoitakse mitut mittehallatavat lahendust, millest igaüks on tavaliselt pühendatud mitteseotud funktsioonidele või moodulitele.

Soovitatav:

• Väikesed-keskmise ulatusega rakendused, millel on selged ja sõltumatud funktsionaalsed valdkonnad, millel ei ole ühiseid komponente.

Eelis	Puuduseks
Lihtsustatud keskkonna seadistamine ja haldamine.	Mitme haldamata lahenduse säilitamine samas arenduskeskkonnas suurendab sõltuvuskonfliktide tõenäosust. Näiteks võib tekkida olukord, kus lahendust A ei saa importida, kuna see sõltub lahendusest B, samas kui lahendust B ei saa importida, kuna see sõltub lahendusest A.
Funktsionaalseid alasid saab kasutada üksteisest sõltumatult.	Mitu samas arenduskeskkonnas töötavat arendajat võivad üksteise muudatused üle kirjutada. Mittehallatava lahendusega töötamine ei taga isolatsiooni. Iga muudatus rakendatakse otse keskkonnale, olenemata sellest, millist lahendust redigeeritakse.

Märkus.

Kui teil on samas arenduskeskkonnas mitu lahendust, loote pärast hallatavate lahenduste sihtkeskkonda importimist sageli kihte. Lisateave: Lahenduse kihid ja ühendamise käitumine

Oluline on, et:

• Ärge lisage sama mittehallatavat komponenti rohkem kui ühte lahendusse.
• Kasutage ainult ühte lahendust, mis sisaldab kõiki teie tabeleid. Teil pole kahte erinevat lahendust, kus mõlemad sisaldavad tabeleid. Põhjus on selles, et tabelite vahel esineb sageli üksikuid seoseid, mis loob lahenduseülese sõltuvusse ja põhjustab hiljem sihtkeskkonnas lahenduse täiendamise või kustutamise probleemid.
• Kasutage ainult ühte lahenduse väljastajat. Lahenduse avaldaja omab hallatava lahenduse komponente ja selle seost ei saa hiljem muuta. Näiteks kui kohandatud tabel imporditakse hallatuna lahenduse A kaudu koos väljaandjaga X, ei saa te seda tabelit hiljem teisaldada lahendusse B koos Publisheriga Y. Ainus võimalus on tabeli kustutamine, lahenduse A täiendamine tabeli eemaldamiseks sihtsüsteemist, seejärel tabeli uuesti loomine lahenduses B väljaandjaga Y ja lahenduse B importimine. Selle protsessi tulemuseks on kõigi kohandatud tabelisse salvestatud andmete kaotsiminek, välja arvatud juhul, kui neid eelnevalt migreeritakse.
• Vältige lahenduste vahel sõltuvuste loomist. Sõltuvused jõustavad impordijärjekorra ja võivad põhjustada probleeme. Näiteks kui teil on üks lahendus tabelite jaoks ja teine pilvevoogude jaoks ning voog tugineb kohandatud veerule, töötab see arenduses, kuna veerg on olemas. Kui aga sihtkeskkonda imporditakse ainult pilvevoo lahendus, ei pruugi impordiprotsess tuvastada sõltuvust kohandatud veerust. Selle tulemusena installitakse voolahendus edukalt, kuid voog ise ei tööta. Lisateave: Mitme lahenduse loodud sõltuvuste näited

Näited mitme lahenduse loodud sõltuvustest

• Rakenduse lindid. Kui mitu lahendust muudavad sama rakenduse rakenduse linti või saidikaarti.
• Pistikprogrammid või pilvevood. Kui pistikprogramm või voog käivitub kohandatud veerus või värskendab kohandatud tabelit, sõltub objekt nendest kohandatud tabelitest.
• Turberollid. Kui kohandatud tabelid on olemas, sõltuvad turberollid tavaliselt nendest tabelitest kasutaja juurdepääsuks.

Mitu lahendust spetsiaalsete arenduskeskkondadega

See strateegia hõlmab iga mittehallatava lahenduse arendamist eraldi Dataverse'i arenduskeskkonnas. Seda strateegiat kasutatakse tavaliselt moodularhitektuurides, kus näiteks erinevaid rakendusi (nt Sales, Customer Service või Field Service) ehitatakse ja hooldatakse sõltumatult. Baaslahendus, mis sisaldab ühiseid komponente (näiteks konto- ja kontaktitabeleid), luuakse ja juurutatakse hallatava lahendusena igasse rakendusepõhisesse arenduskeskkonda. Igal rakendusel on seejärel oma mittehallatav lahendus, mis on kihistatud hallatava baaslahenduse peale, võimaldades meeskondadel laiendada funktsionaalsust ilma baasalust muutmata.

Soovitatav:

• Suuremahulised ettevõtlusprojektid.
• Mitme arendaja või partneriga meeskonnad
• Stsenaariumid, mis nõuavad ranget juhtimist ja CI/CD konveiereid.

Eelis	Puuduseks
Süsteemi on lihtsam kasvatada ja arendada, lisades või värskendades mooduleid ilma teisi mõjutamata.	Suuremad infrastruktuuri- ja hoolduskulud.
Mitu meeskonda saavad töötada paralleelselt erinevate moodulite kallal, ilma et see oleks üksteise muudatustega vastuolus.	Nõuab tugevat keskkonnastrateegiat ja juhtimist.
Lihtsam rakendada automatiseeritud testimist ja DevOpsi tavasid.	Keerulisem juurutamine.
Väiksemaid lahendusi on kiirem juurutada, eriti CI/CD konveierites, kui peate juurutama ainult konkreetse rakenduse.
Vigu või regressioone on lihtsam jälgida, kui muudatused on isoleeritud konkreetsetele moodulitele.

Kuidas luua oma lahenduse kihilisust

Märkus.

Enne järgmistes etappides lahenduste loomist kasutage kõigi oma keskkondade lahenduste jaoks sama väljaandjat. Lisateave. Lahenduse väljastaja

1. "Baas" arenduskeskkonnas on teie baaslahendus tavaliste mittehallatavate tabelitega ja ilma muude tabeliteta. Seejärel eksportige see lahendus hallatuna.
2. Seadistate laienduse või "rakenduse" kihi jaoks teise arenduskeskkonna, mis asub hiljem aluskihi peal.
3. Impordite hallatava aluskihi rakendusekihi arenduskeskkonda ja loote rakendusekihi jaoks mittehallatava lahenduse.
4. Nüüd saate andmemudelit laiendada, lisades konkreetsele rakenduselahendusele täiendavaid tabeleid, veerge, tabeliseoseid, lisandmooduleid, voogusid jne. Seejärel eksportige see lahendus hallatavana. Pange tähele, et rakenduse lahendus sõltub endiselt aluskihi lahendusest, kuid mitme lahenduse selline haldamine on parem lähenemisviis. Mõelge eespool mainitud näitele kohandatud veerule tugineva voo kohta. Enamikul juhtudel asuvad nii kohandatud veerg kui ka voog samas rakenduselahenduses. Kuid isegi kui kohandatud veerg on osa põhilahendusest, peate selle baaslahenduse esmalt hallatuna lõpule viima ja juurutama, vastasel juhul ei saa rakenduse lahenduse sees olevat voogu isegi luua.
5. Oma tootmises tuleb importida hallatav baaskiht ja seejärel importida hallatav rakendusekiht. See loob keskkonnas kaks hallatavat kihti, millel on hallatavate lahenduste vahel selged sõltuvused.
6. Korrake seda mustrit, et teil oleks nii palju erinevaid lahendusi, kui teil on vaja säilitada. Siiski soovitame teil säilitada lahenduste arvu nii väiksena, kui võimalik, et hoida lahenduse kihtimist hallatavana.

Seotud artiklid

Tabeli segmenteerimise kasutamine
Stsenaarium 5: Meeskonna arengu toetamine