Ratkaisujen järjesteleminen

Ennen kuin luot ratkaisuja, suunnittele ympäristöstrategiasi ja ratkaisustrategiasi etukäteen. Ota huomioon seuraavat seikat:

Ominaisuus Huomioitavia seikkoja
Sovelluksen vaikutusalue Kattaako toteutus useita sovelluksia, kuten myynti, asiakaspalvelu, kenttäpalvelu, rahoitus jne.?
Päivitysväli Kuinka usein aiot ottaa päivityksiä käyttöön tuotannossa?
Perustuuko toimitusmenetelmäsi ketteriin käytäntöihin, kuten sprinttijaksoihin?
Tuotantotuki Miten käsittelet kiireelliset korjaukset tuotannossa ilman uusien ominaisuuksien ennenaikaista käyttöönottoa?
Ratkaisuarkkitehtuuri Kuinka monta ratkaisua hallitset?
Jakavatko nämä ratkaisut komponentteja tai riippuvat toisistaan?
Ympäristön suunnittelu Kuinka monta Microsoft Dataverse -ympäristöä tarvitset kehityksen elinkaaren tukemiseksi?
Tarvitsetko erillisiä ympäristöjä kehitykseen, testaukseen ja tuotantoon?
Toimivatko kehittäjät yhteistyössä jaetussa ympäristössä, vai tarvitsevatko he eristetyt ympäristöt toimiakseen itsenäisesti?

Seuraavissa osissa hahmotellaan kolme strategiaa, jotka on järjestetty yksinkertaisimmasta monimutkaisimpaan, ja korostetaan niiden etuja ja haittoja.

Yksittäisen ratkaisun strategia

Kaikki mukautukset ryhmitetään yhdeksi hallitsemattomaksi ratkaisuksi kehityksen aikana, joka viedään myöhemmin yksittäisenä hallittuna ratkaisuna käyttöönottoon.

Suositus lle:

  • Pienimuotoiset toteutukset
  • Skenaariot, joissa tuleva modulaarinen tila on epätodennäköinen
Etu Haitta
Yksinkertaistettu ympäristön asennus ja hallinta. Vaatii enemmän työtä skaalata tai modularisoida myöhemmin tarvittaessa.
Yksinkertaistettu käyttöönotto. Vain yhdellä ratkaisulla voit hallita, vieminen ja tuominen ympäristöjen välillä on yksinkertaista ja vähemmän virhe altis. Suuri määrä mukautuksia sisältävä yksittäinen ratkaisu voi pidentää käyttöönottoaikoja. Jos haluat pienentää ratkaisun kokoa, käytä taulukon segmentointia. Jos haluat lyhentää tuontiaikoja, siirry suorituskykysuosituksiin.
Helpompi etsiä, valvoa ja hallita muutoksia. Kun useat kehittäjät työskentelevät samassa kehitysympäristössä, he saattavat korvata toistensa muutokset. Tätä riskiä voidaan vähentää ottamalla käyttöön lähdekoodien versioinnit, ottamalla käyttöön haarautuva strategia ja käyttämällä jokaiselle haaralle varattua kehitysympäristöä. Lähdekoodin versiointi- ja haarastrategia tarjoavat muutosten seurannan, yhteistyötuen ja ristiriitojen ratkaisumekanismit. Lisätietoja: Omaksu Git-haarautumisstrategia.

Muistiinpano

Microsoft Power Platformin viimeaikaisten parannusten tuontiajat ovat lyhentyneet hallittujen ratkaisujen osalta, mukaan lukien ne, jotka käyttävät päivitysvaihtoehtoa. Näihin optimointeihin kuuluu osien riippuvuuksien parempi käsittely ja muuttumattomien osien kuormitusten pieneneminen. Jos haluat oppia hyötymään näistä parannuksista, siirry suorituskykysuosituksiin.

Useita ratkaisuja yhdessä kehitysympäristössä

Yhdessä kehitysympäristössä ylläpidetään useita hallitsemattomia ratkaisuja, joista jokainen on yleensä omistettu liittymättömille ominaisuuksille tai moduuleille.

Varoitus

Useiden ratkaisujen käyttäminen yhdessä ympäristössä voi aiheuttaa ongelmia jatkoympäristöihin tehtävissä käyttöönotossa, mukaan lukien tuotantoympäristöt. Jos päätät työskennellä useiden ratkaisujen parissa kehitysympäristössäsi, ymmärrä tässä osiossa annettujen ohjeiden noudattamisen tärkeys. Jos haluat lisätietoja, katso Mitä sinun tulee tietää, ennen kuin työskentelet useiden ratkaisujen kanssa samassa ympäristössä.

Suositus lle:

  • Pienet ja keskisuuret toteutukset, joissa on erillisiä ja itsenäisiä toiminta-alueita , jotka eivät jaa komponentteja.
Etu Haitta
Yksinkertaistettu ympäristön asennus ja hallinta. Useiden hallitsemattomien ratkaisujen ylläpitäminen samassa kehitysympäristössä lisää riippuvuusristiriitojen todennäköisyyttä. Saatat esimerkiksi kohdata tilanteen, jossa ratkaisua A ei voi tuoda, koska se riippuu ratkaisusta B, kun taas ratkaisua B ei voi tuoda, koska se on riippuvainen ratkaisusta A.
Toiminnallisia alueita voi ottaa käyttöön erillään toisistaan. Useat samassa kehitysympäristössä työskentelevät kehittäjät saattavat korvata toistensa muutokset. Hallitsemattomassa ratkaisussa toimiminen ei eristä sitä. Jokainen muokkaus otetaan käyttöön suoraan ympäristöön riippumatta siitä, mitä ratkaisua muokataan.

Kun sinulla on useita ratkaisuja samassa kehitysympäristössä, luot usein kerroksia sen jälkeen, kun olet tuonut hallitut ratkaisut kohdeympäristöösi. Lisätietoja on kohdassa Ratkaisukerrokset ja yhdistämisen toiminta.

Mitä sinun on tiedettävä, ennen kuin työskentelet useiden ratkaisujen kanssa samassa ympäristössä

Noudata näitä käytäntöjä käsitellessäsi useita hallitsemattomia ratkaisuja yhdessä kehitysympäristössä:

  • Käytä vain yhtä ratkaisun julkaisijaa. Ratkaisun julkaisija omistaa hallitun ratkaisun komponentit, eikä sen liitosta voi muuttaa myöhemmin. Jos esimerkiksi tuot mukautetun taulun hallittuna ratkaisuun A julkaisijalla X, et voi myöhemmin siirtää taulua ratkaisuun B julkaisijalla Y. Ainoa vaihtoehto on poistaa taulu, päivittää ratkaisu A taulun poistamiseksi kohdejärjestelmästä ja luoda sitten taulu uudelleen ratkaisussa B julkaisijalla Y ja tuoda ratkaisu B. Tämä poistamisprosessi johtaa kaikkien mukautettuun tauluun tallennettujen tietojen menettämiseen, ellet siirrä niitä etukäteen.
  • Käytä kehitysympäristössä yksittäistä hallitsematonta ratkaisua. Jos haluat mukauttaa hallittua osaa toisesta hallitusta ratkaisusta, lisää komponentti omaan hallitsemattomaan ratkaisuusi. Jos haluat mukauttaa hallittua komponenttia, hallittujen ominaisuuksien asetuksena on oltava Mukautettavissa. Vie tämän jälkeen ei-hallittu ratkaisu hallittuna muihin ympäristöihin käyttöönottoa varten. Lisätietoja on kohdassa Hallitut ominaisuudet.
  • Jos käytät useita ratkaisuja, älä sisällytä samaa hallitsematonta komponenttia useampaan kuin yhteen ratkaisuun.
  • Jos käytät useita ratkaisuja, pidä vain yksi ratkaisu, joka sisältää kaikki taulukot. Älä käytä kahta erilaista ratkaisua, joissa molemmat sisältävät taulukoita. Tämä ehto on olemassa, koska yksittäiseen taulukoiden väliseen suhteeseen liittyy usein riskejä, mikä luo ratkaisujen välisen riippuvuuden ja aiheuttaa ratkaisun päivitys- tai poisto-ongelmia kohdeympäristössä myöhemmin.
  • Jos käytät useita ratkaisuja, vältä riippuvuuksien luomista ratkaisujen välille. Riippuvuudet valvovat tuontitilausta ja voivat aiheuttaa ongelmia. Jos sinulla on esimerkiksi yksi ratkaisu taulukoille ja toinen pilvipalvelutyönkuluille ja työnkulku käyttää mukautettua saraketta, se toimii kehityksessä, koska sarake on olemassa. Jos kuitenkin tuot kohdeympäristöön vain pilvityönkulkuratkaisun, tuontiprosessi ei välttämättä tunnista mukautetun sarakkeen riippuvuutta. Tämän seurauksena työnkulkuratkaisun asennus onnistuu, mutta työnkulku ei toimi. Lisätietoja on artikkelissa Esimerkkejä useiden ratkaisujen luomista riippuvuuksista.

Mitä kannattaa välttää käsiteltäessä useita ratkaisuja samassa ympäristössä

Tässä esimerkissä ympäristö ei anna käyttäjän poistaa kummankaan hallitun ratkaisun asennusta tai päivittää niitä, koska eri julkaisijoiden kaksi ratkaisua yrittävät päivittää samaa komponenttia. Tilanne:

  • Samaan ympäristöön asennetaan kaksi eri julkaisijan hallittua ratkaisua.
  • Vähintään yksi komponentti (Komponentti 1) on Publisher A:n omistama, mutta Publisher B on laajentanut sitä. Publisher A:n ratkaisu on kyseisen komponentin peruskerros, ja Publisher B:n ratkaisu on sen päällä.
  • Vähintään yhden muun osan (osa 2) omistaa Publisher B, ja se on Publisher A:n laajentama. Tämä ehto on päinvastainen edellisestä luetelmakohdasta.
Taso Osa 1 Osa 2
Ylin Ratkaisu B (Publisher B) Ratkaisu A (Publisher A)
Pohja Ratkaisu A (Publisher A) Ratkaisu B (Publisher B)

Tämä ongelma ilmenee, koska se aiheuttaa komponentille kehäriippuvuuden sekä ratkaisujen että ympäristön kanssa, eikä ympäristö anna käyttäjän poistaa komponentin asennusta tai päivittää komponenttia. Tässä esimerkissä:

  • Ratkaisun A asennusta ei voi poistaa, koska se omistaa komponentin 1 ja sen päällä on mukautus ratkaisusta, joka kuuluu julkaisijalle B. Jos haluat poistaa ratkaisun A asennuksen, poista ensin ratkaisun B asennus.
  • Ratkaisun B asennusta ei voi poistaa, koska se omistaa komponentin 2 ja sen päällä on mukautus ratkaisusta, joka kuuluu julkaisijalle A. Jos haluat poistaa ratkaisun B asennuksen, poista ensin ratkaisun A asennus.

Esimerkkejä useiden ratkaisujen luomista riippuvuuksista

  • Sovelluksen nauhat Kun useat ratkaisut muokkaavat sovelluksen valintanauhaa tai saman sovelluksen sivustokarttaa.
  • Laajennukset tai pilvityönkulut. Jos laajennus tai työnkulku käynnistyy mukautetussa sarakkeessa tai päivittää mukautetun taulukon, objekti riippuu kyseisistä mukautetuista taulukoista.
  • Turvaroolit. Kun mukautettuja taulukoita on olemassa, käyttöoikeusroolit riippuvat yleensä siitä, mitä taulukoita käyttäjä käyttää.

Useita ratkaisuja, joissa on useita erillisiä kehitysympäristöjä

Tämä strategia sisältää kunkin hallitsemattoman ratkaisun kehittämisen omassa eristetyssä Dataverse-kehitysympäristössään. Tätä strategiaa käytetään yleisesti modulaarisissa arkkitehtuureissa, joissa esimerkiksi eri sovelluksia, kuten myynti, asiakaspalvelu tai kenttäpalvelu, luodaan ja ylläpidetään itsenäisesti. Perusratkaisu, joka sisältää yleisiä komponentteja (esimerkiksi tili- ja yhteystietotaulukoita), luodaan ja otetaan käyttöön hallittuna ratkaisuna jokaisessa sovelluskohtaisessa kehitysympäristössä. Jokaisella sovelluksella on sitten oma hallitsematon ratkaisunsa, joka on kerrostettu perushallitun ratkaisun päälle, jolloin tiimit voivat laajentaa toimintoja muuttamatta peruspohjaa.

Suositus lle:

  • Suuren mittakaavan yritysprojektit.
  • Tiimit, joissa on useita kehittäjiä tai kumppaneita
  • Skenaariot, jotka edellyttävät tiukkaa hallintoa ja CI/CD-putkia.
Etu Haitta
Helpompi kasvaa ja kehittää järjestelmää lisäämällä tai päivittämällä moduuleja vaikuttamatta muihin. Suurempi infrastruktuuri ja ylläpidon yleiskulut.
Useat tiimit voivat työskennellä rinnakkain eri moduuleissa ilman, että ne ovat ristiriidassa toistensa muutosten kanssa. Vaatii vankan ympäristöstrategian ja -hallinnon.
Helpompi toteuttaa automatisoitu testaus ja DevOps-käytännöt. Monimutkaisempi käyttöönotto.
Pienemmät ratkaisut on nopeampaa ottaa käyttöön erityisesti CI-/CD-jaksoissa, jos vain tietty sovellus on otettava käyttöön.
Virheitä tai regressioita on helpompi jäljittää, kun muutokset eristetään tiettyihin moduuleihin.

Ratkaisujen kerrostamisen luominen

Muistiinpano

Ennen kuin luot ratkaisuja seuraavissa vaiheissa, käytä samaa julkaisijaa kaikille ratkaisuillesi kaikissa ympäristöissäsi. Lisätietoja: Ratkaisujulkaisija

  1. Peruskehitysympäristössä sinulla on perusratkaisusi yleisten hallitsemattomien taulukoiden kanssa, ei muita taulukoita. Tämä ratkaisu voidaan sitten viedä hallittuna ratkaistuna.
  2. Olet määrittänyt toisen kehitysympäristön laajennus- tai sovelluskerrokselle, joka sijaitsee myöhemmin peruskerroksen päällä.
  3. Tuot hallitun perustason sovellustason kehitysympäristöön ja luot hallitsemattoman ratkaisun sovelluskerrokselle. Asianmukainen ratkaisun kerrostaminen käyttämällä useita ratkaisuja ja useita ympäristöjä
  4. Voit nyt laajentaa tietomallia lisäämällä lisätaulukoita, sarakkeita, taulukkosuhteita, laajennuksia, työnkulkuja jne. tiettyyn sovellusratkaisuun. Sovellusratkaisu viedään sitten hallittuna ratkaisuna. Huomaa, että sovellusratkaisu on edelleen riippuvainen perustasoratkaisusta, mutta useiden ratkaisujen hallinta tällä tavalla on parempi tapa. Tarkastele esimerkkiä, joka mainittiin ennen työnkulkua, joka on riippuvainen mukautetusta sarakkeesta. Useimmissa tapauksissa sekä mukautettu sarake että työnkulku sijaitsevat samassa sovellusratkaisussa. Vaikka mukautettu sarake olisi osa perusratkaisua, sinun on saatava kyseinen perusratkaisu valmiiksi ja otettava se käyttöön hallittuna ensimmäisenä. Muussa tapauksessa sovellusratkaisun sisältämää työnkulkua ei voi edes luoda.
  5. Hallittu perustason kerros tuodaan tuotantoympäristössä ensin ja hallittu sovelluskerros tuodaan sitten. Tämä luo ympäristöön kaksi hallittua kerrosta, joilla on selkeät riippuvuudet hallittujen ratkaisujen välillä.
  6. Toista tämä malli, jotta sinulla on niin monta erilaista ratkaisua kuin sinun on ylläpidettävä. On kuitenkin suositeltava ratkaisujen määrän pitämistä mahdollisimman alhaisena, jotta ratkaisun kerrostaminen pysyy hallittavana.

Taulukon segmentoinnin käyttäminen
Skenaario 5: Tukihenkilöstön kehittäminen

  • Viimeksi päivitetty