Power BI:n käyttöönoton suunnittelu: sisällön kehittäminen ja muutosten hallinta

Muistiinpano

Tämä artikkeli on osa Power BI:n käyttöönoton suunnittelun artikkelisarjaa. Tässä sarjassa keskitytään ensisijaisesti Microsoft Fabricin Power BI -kokemukseen. Johdanto sarjaan on artikkelissa Power BI:n käyttöönoton suunnittelu.

Tämän artikkelin avulla voit kehittää sisältöä ja hallita muutoksia osana sisällön elinkaaren hallintaa. Se on ensisijaisesti kohdistettu seuraaviin:

• Center of Excellence (COE) ja BI-tiimit: Tiimit, jotka vastaavat Power BI:n valvonnasta organisaatiossa. Näihin tiimeihin kuuluu päättäjiä, jotka päättävät, miten Power BI -sisällön elinkaarta hallitaan. Näihin tiimeihin voi kuulua myös rooleja, kuten julkaisupäälliköitä, jotka käsittelevät sisältöjulkaisujen elinkaarta, tai insinöörejä, jotka luovat ja hallitsevat komponentteja, joita tarvitaan elinkaaren hallinnan tehokkaaseen käyttöön ja tukemiseen.
• Sisällöntekijät ja sisällön omistajat: Käyttäjät, jotka luovat sisältöä, jonka he haluavat julkaista Fabric-portaalissa muiden kanssa jaettavaksi. Nämä henkilöt ovat vastuussa luomansa Power BI -sisällön elinkaaren hallinnasta.

Elinkaaren hallinta on prosesseja ja käytäntöjä, joiden avulla käsittelet sisältöä sen luomisesta eläkkeelle jäämiseen. Elinkaaren hallinnan ensimmäisessä vaiheessa suunnittelet ja suunnittelet sisältöä, johon liittyy ratkaisun suunnittelu ja sellaisten tärkeiden päätösten tekeminen, jotka vaikuttavat lähestymistapaasi elinkaaren hallintaan. Toisessa vaiheessa kehität sisältöä ja hallitset muutoksia.

Sisällön muutosten hallinta sen elinkaaren aikana on tärkeää, jotta sisällöntuottajat voivat tehdä tehokasta yhteistyötä sekä saada sisältöä kuluttajille vakaasti ja johdonmukaisesti.

Seuraavassa kuvassa esitetään Power BI -sisällön elinkaari ja korostetaan vaihetta 2, jossa kehität sisältöä ja hallitset muutoksia.

Muistiinpano

Katso yleiskatsaus sisällön elinkaaren hallinnasta tämän sarjan ensimmäisestä artikkelista.

Vihje

Tässä artikkelissa keskitytään keskeisiin päätöksiin ja huomioita, joiden avulla voit kehittää sisältöä ja hallita muutoksia koko sen elinkaaren ajan. Saat lisätietoja sisällön kehittämisestä ja muutosten hallinnasta seuraavasta ohjeartikkelista:

• Mikä on Microsoft Fabricin elinkaaren hallinta?: Tämä artikkeli sisältää teknisen esittelyn ja opetusohjelman Fabric Gatin integrointi- ja käyttöönottoputkista.
• Elinkaaren hallinnan parhaat käytännöt: Tämä artikkeli sisältää käytännön vinkkejä ja ohjeita Fabricin ja Power BI:n elinkaaren hallintaominaisuuksien käyttöön sisällön kehittämiseen ja muutosten hallintaan.
• Power BI Desktopin OneDriven ja SharePointin integrointi: Tässä artikkelissa on yleiskatsaus asetuksista käyttää ja tallentaa OneDrive for Workiin ja Schooliin tai SharePointiin tallennettuja tiedostoja, kun suoritat versionhallintaa .pbix-tiedostoille.
• Aloita Gitin käyttö Azure Reposissa: Tämä artikkelisarja sisältää käytännön vinkkejä, opetusohjelmia ja ohjeita lähteen hallinnan suorittamiseen Azure Reposissa olevan Git-säilön avulla.

Sisällöntekijöiden ja omistajien tulee hallita sisällön muutoksia versionhallinnan avulla. Versionhallinta on käytäntö hallita tiedostojen tai koodin muutoksia keskitetyssä säilössä. Tämä käytäntö helpottaa yhteistyön ja sisällön hallinnan tehostamista.

Muita versionhallinnan etuja ovat muun muassa mahdollisuus:

• Yhdistä useiden sisällöntekijöiden muutokset ja käsittele yhdistämisristiriitoja.
• Määritä, mikä sisältö on muuttunut ja mikä siinä on muuttunut.
• Linkitä sisällön muutokset tiettyihin työkohteisiin.
• Ryhmittele muutokset erillisiin versioihin versiohistorian avulla.
• Sisällön muutokset tai kokonaiset versiot.

Vihje

Suosittelemme, että käytät versionhallintaa kaikessa luomassasi sisällössä mahdollisuuksien mukaan. Versionhallinnan käytöllä on merkittäviä etuja sekä sisällöntekijöille että kuluttajille, ja se vähentää häiriöiden riskiä tiedostojen menettämisen tai kyvyttömyyden peruuttaa muutokset.

Ensimmäinen vaihe versionhallinnan määrittämisessä on päättää, miten kehität sisältöä.

Päätä, miten kehität sisältöä

Riippuen siitä, miten luot sisältöä, teet erilaisia päätöksiä sen hallinnasta. Esimerkiksi Power BI -raporteissa ja semanttisissa malleissa Power BI Desktop (.pbix) -tiedostossa on vähemmän versionhallintavaihtoehtoja kuin Power BI Desktop -projekti (.pbip) -muodossa. Tämä johtuu siitä, että .pbix-tiedosto on binaarimuoto, kun taas .pbip-muoto sisältää tekstipohjaista, ihmisen luettavaa sisältöä ja metatietoja. Ihmisen luettava sisältö ja metatiedot helpottavat mallin ja raportin muutosten seurantaa lähteen hallinnan avulla. Lähdeohjausobjekti on, kun tarkastelet ja hallitset sisällön muutoksia sen koodiin ja metatietoihin.

Vihje

Kun kehität semanttisia malleja ja raportteja Power BI Desktopin avulla, suosittelemme, että käytät .pbip-tiedostoja .pbix-tiedostojen sijaan. Kun kehität semanttisia malleja XMLA-työkaluilla, suosittelemme, että käytät .bim-tiedostojen sijaan TMDL (Tabular Model Definition Language) -muotoa.

.pbip- ja TMDL-muodot tukevat objektitason muutosten helpompaa seurantaa ja yhdistämistä. Tämä tarkoittaa sitä, että voit tarkastella ja hallita yksittäisiin objekteihin, kuten DAX-mittareihin tai -taulukoihin, tehtyjä muutoksia.

Power BI Desktop

Power BI Desktopin avulla voit luoda semanttisia malleja tai raportteja, jotka voit tallentaa joko .pbix- tai .pbip-tiedostoina. Voit käyttää myös muita mukautettuja sisältötiedostoja, kun käytät Power BI Desktopia. Kun käytät Power BI Desktopia sisällön luomiseen, sinun kannattaa tehdä muun muassa seuraavat keskeiset päätökset:

• Käytettävä tiedostomuoto: Voit tallentaa sisältöä joko .pbix- tai .pbip-tiedostoina. Esimerkiksi Git-integrointi edellyttää, että käytät .pbip-tiedostoja, itsepalvelukehittäjät saattavat pitää .pbix-tiedostoja yksinkertaisempina hallita ja ylläpitää Teamsissa, SharePointissa tai OneDrivessa.
• Mukautetun sisällön hallinta: Voit lisätä teemoja, mukautettuja visualisointeja tai kuvia Power BI Desktop -tiedostoihin, mikä saattaa vaatia elinkaaren hallintaan erillisiä huomioon otettavia seikkoja. Kun sisällöntuottajat esimerkiksi tekevät omia mukautettuja visualisointejaan, heidän tulee tallentaa visualisoinnin määritykset ja hallita niitä erillisessä tiedostossa.
• Esiversiotoimintojen hallinta: Voit halutessasi esikatsella Power BI Desktopin ominaisuuksia tai asetuksia, mikä muuttaa sisältöä ja miten sitä käytetään. Voit esimerkiksi suorittaa lisätoimia vahvistaaksesi sisältöä, joka käyttää esikatselutoimintoja.

Web-sisällön tuottaminen

Tiettyjä sisältöjä, kuten tietovoita, koontinäyttöjä ja tuloskortteja, voi luoda vain Fabric-portaalissa. Voit myös luoda tai muokata joitakin sisältöjä, kuten semanttisia malleja, raportteja ja sivutettuja raportteja, Fabric-portaalissa tai käyttämällä paikallisia työkaluja. Kun luot sisältöä verkon luomisen avulla, sinun kannattaa tehdä joitakin keskeisiä päätöksiä, kuten seuraavat:

• Muutosten hallinta: Voit tehdä muutoksia moniin kohdetyyppeihin käyttämällä verkko tuottamista, mutta nämä muutokset voidaan tallentaa välittömästi, ja aiemmat versiot korvaavat ne. Jos esimerkiksi teet yhteistyötä muiden kanssa, haluat ehkä välttää verkon luomista jaetuissa kohteissa, toimimalla sen sijaan omassa kopiossasi.
• Sisällön varmuuskopioiden noutaminen: Voit luoda sisältöä, kuten raportteja tai semanttisia malleja, käyttämällä verkon luomista, mutta näitä kohteita ei voida ladata paikallisiin .pbix-tiedostoihin. Voit esimerkiksi varmuuskopioida tämän sisällön noutamalla ja tallentamalla sen metatiedot.

Vihje

Kun kehität tietovoita ja tuloskortteja, suosittelemme, että noudat kohteen määritykset, jotta voit hallita muutoksia ja tallentaa varmuuskopion. Voit automatisoida tietovuon ja tuloskortin noutamisen Fabric REST -ohjelmointirajapintojen avulla. Voit erityisesti käyttää Nouda tietovuo - ja Nouda tuloskortit -päätepisteitä.

Varoitus

Jossain sisällössä, kuten koontinäytöissä, ei ole mahdollisuutta noutaa määritelmää. Tässä sisällössä et voi helposti seurata muutoksia tai noutaa varmuuskopiota.

Muut työkalut

Voit muiden työkalujen avulla luoda tai hallita tietyntyyppisiä sisältöjä. Nämä työkalut voivat tarjota lisäetuja, jotka sopivat paremmin työnkulkuun tai joita tarvitaan tiettyjen ominaisuuksien tai sisältötyyppien hallintaan. Voit luoda ja hallita sisältöä sekä muiden Microsoftin työkalujen että kolmannen osapuolen työkalujen avulla. Muita työkaluja, joilla voit luoda tai hallita sisältöä, ovat seuraavat.

• Visual Studio tai Visual Studio Code: Kehittäjille tarkoitettu integroitu kehitysympäristö semanttisten mallien tai Fabric-muistikirjojen luomiseen ja hallintaan. Sekä Visual Studion että Visual Studio Coden avulla kehittäjät voivat myös suorittaa lähteen hallinnan (SCM) vahvistamalla ja lähettämällä paikalliset muutokset etäsäilöön.
• Tabular Editor: Kolmannen osapuolen työkalu semanttisten mallien kehittämiseen ja hallintaan.
• Excel: asiakastyökalu semanttisen mallin kanssa toimivia pivot-taulukoita ja reaaliaikaisia yhdistettyjä taulukoita varten.
• Power BI Raportin muodostin: työpöytäsovellus sivutettujen raporttitiedostojen (.rdl) luomiseen.

Kun luot sisältöä muilla työkaluilla, sinun kannattaa tehdä myös seuraavat keskeiset päätökset:

• Käyttöoikeuksien hallinta: Muut työkalut saattavat vaatia lisälisenssejä, joita sinun tulee hallita.
• Sisällön julkaiseminen: Muut työkalut saattavat vaatia lisävaiheita sisällön julkaisemiseen, esimerkiksi XMLA-päätepisteiden tai Power BI REST -ohjelmointirajapintojen avulla.

Kun olet päättänyt, miten luot sisältöä, sinun on seuraavaksi valittava, missä julkaiset ja testaat sisältöä kehittäessäsi sitä.

Päätä, miten määrität ja käytät työtiloja

Kun kehität sisältöä, käytä useita työtiloja (tai vaiheita) erottaaksesi organisaation käyttämän tuotantosisällön kehitettävästä tai vahvistettavasta sisällöstä. Erillisten työtilojen käytöllä sisällöllesi on monia etuja:

• Voit kehittää ja testata sisältöä vaikuttamatta parhaillaan käytössä olevaa sisältöön. Näin vältetään muutokset, jotka voivat aiheuttaa tahattomia häiriöitä tuotantosisältöön.
• Voit käyttää erillisiä resursseja sisällön kehittämiseen ja testaamiseen, kuten erillisten tietoyhdyskäytäviä tai Fabric-kapasiteetteja. Näin vältetään se, että kehittämiseen ja testaukseen käytetyt resurssit häiritsevät tuotannon kuormituksia aiheuttaen hitaita tietojen päivityksiä tai raportteja.
• Voit luoda jäsennellymmän prosessin sisällön kehittämiseksi, testaamiseksi ja julkaisemiseksi käyttämällä erillisiä ympäristöjä kuhunkin näistä vaiheista. Tämä auttaa parantamaan tuottavuutta.

Fabricissa ja Power BI:ssä suosittelemme, että käytät erillisiä Fabric-työtiloja vuokraajatason ja työtilatason suunnitteluartikkeleissa kuvatulla tavalla.

Tärkeä

Erillisten ympäristöjen käyttäminen on olennainen vaihe sisällön elinkaaren hallintamenetelmän onnistumisen varmistamiseksi.

Fabric-työtilojen avulla voit erottaa ympäristöt useilla tavoilla. Paikallisen ympäristön lisäksi sisältöä hallitaan yleensä kahden tai useamman työtilan avulla sen elinkaaren aikana.

Vastaa seuraaviin kysymyksiin, kun suunnittelet, miten käytät erillisiä työtiloja koko tämän sisällön elinkaaren ajan:

• Kuinka monta työtilaa tarvitset?
• Erotatko työtilat kohdetyypin mukaan?
• Ken voi käyttää kutakin työtilaa?
• Kuuluvatko työtilat Fabric-käyttöönottoputkeen vai järjestätkö käyttöönoton muilla tavoilla, kuten Käyttämällä Azure-putkia?
• Miten voit hallita työtilojen välistä julkaisemista? Täytyykö sinun esimerkiksi varmistaa, että raporttien testityötilan raportit muodostavat yhteyden semanttisiin malleihin erillisessä tietokohteiden testityötilassa?
• Onko sinun myös käytettävä erillisiä tukiresursseja tuotantotyötilojen kohteille, kuten erillistä paikallista tietoyhdyskäytäväklusteria?

Seuraavissa osioissa on korkean tason yleiskatsaus eri lähestymistavoista, joita voit käyttää eri työtiloissa elinkaaren hallinnan helpottamiseksi.

Muistiinpano

Seuraavissa osioissa keskitytään siihen, miten voit määrittää ja käyttää erillisiä työtiloja. Voit ottaa sisällön käyttöön näissä työtiloissa käyttämällä jotakin seuraavista neljästä menetelmästä:

• Julkaistaan Power BI Desktopista.
• Sisällön käyttöönotto toisesta työtilasta käyttämällä Fabric-käyttöönottoputkia.
• Sisällön synkronointi git-etäsäilöstä Git-integroinnin avulla.
• Sisällön käyttöönotto ohjelmallisesti Fabric REST -ohjelmointirajapintojen, Power BI REST -ohjelmointirajapintojen tai XMLA-päätepisteiden avulla.

Katso lisätietoja näistä tavoista ottaa sisältöä käyttöön kohdassa Vaihe 4: Sisällön käyttöönotto myöhemmin tässä sarjassa.

Testi- ja tuotantotyötilat

Kun tarjoat yksinkertaisempaa sisältöä, joka ei ole tärkeää organisaatiolle, kaksi työtilaa riittää usein. Tässä skenaariossa sisällöntekijöillä on yleensä rajallinen yhteistyö samojen kohteiden kanssa ja he kehittävät sisältöä paikallisesti.

Seuraavassa kaaviossa esitetään korkean tason esimerkki siitä, miten voit käyttää erillisiä ympäristöjä, joissa on vain testi- ja tuotantotyötila.

Kaaviossa kuvataan seuraavat prosessit ja komponentit, jotka erottavat työtilat tässä lähestymistavassa.

Kohde	Kuvaus
	Sisällöntekijät kehittävät sisältöä paikallisessa ympäristössään.
	Kun sisältö on valmis, sisällön luojat julkaisevat sisältöä testityötilaan. Sisällöntekijät voivat kehittää sisältöä, joka voidaan tuottaa vain verkon tuottamisen avulla, ja suorittaa sisällön vahvistuksen testityötilassa.
	Kun olet valmis, sisällön luojat ottavat sisällön käyttöön tuotantotyötilassa. Tuotantotyötilassa sisällön luojat jakavat sisältöä julkaisemalla Power BI -sovelluksen tai jakamalla sisältöä työtilasta.

Muistiinpano

Erillisiä työtiloja voi määrittää ja käyttää monella eri tavalla ja ottaa sisältöä käyttöön näiden työtilojen välillä. Suosittelemme kuitenkin, ettet suorita paikallista kehitystä, ja julkaise sitten sisältöä suoraan tuotantotyötilaan. Tämä voi johtaa ehkäistävissä oleviin häiriöihin ja virheisiin.

Kehitys-, testi- ja tuotantotyötilat

Kun toimitat liiketoiminnan kannalta tärkeää sisältöä, käytät yleensä kolmea tai useampaa erillistä työtilaa. Tässä skenaariossa sisällöntekijät tekevät usein yhteistyötä toisessa kehitystyötilassa, joka sisältää ratkaisun uusimman version.

Seuraavassa kaaviossa esitetään korkean tason esimerkki siitä, miten voit käyttää erillisiä ympäristöjä kehitys-, testi- ja tuotantotyötilassa.

Kaaviossa kuvataan seuraavat prosessit ja komponentit, jotka erottavat työtilat tässä lähestymistavassa.

Kohde	Kuvaus
	Sisällöntekijät kehittävät sisältöä paikallisessa ympäristössään.
	Kun sisältö on valmis, sisällön luojat julkaisevat sisältöä kehitystyötilaan. Kehitystyötilassa sisällöntekijät voivat kehittää sisältöä, jota voidaan tuottaa vain verkkosisällön tuottamisen avulla. Sisällön luojat voivat myös vahvistaa kehitystyötilan sisällön.
	Kun sisältö on valmis, sisällön luojat ottavat sisällön käyttöön testityötilassa. Testityötilassa käyttäjät vahvistavat sisältöä joko työtilassa tai sovelluksessa.
	Kun olet valmis, sisällön luojat ottavat sisällön käyttöön tuotantotyötilassa. Tuotantotyötilassa sisällön luojat jakavat sisältöä julkaisemalla Power BI -sovelluksen tai jakamalla sisältöä työtilasta.

Muistiinpano

Voit käyttää käyttöönottoputkien kanssa enintään 10 eri ympäristöä. Saatat esimerkiksi haluta testin ja tuotannon välille esituotantoympäristön, joka on tarkoitettu erityisesti tietyntyyppisille vahvistuksille, kuten suorituskykytestaukselle.

Yksityinen työtila Git-integroinnin avulla

Kun liiketoimintakriittistä sisältöä toimitetaan, kukin kehittäjä voi käyttää kehityksessä myös omaa yksityistä työtilaansa. Tässä skenaariossa yksityisen työtilan avulla sisällöntuottajat voivat testata sisältöä Fabric-portaalissa tai käyttää ajoitetun päivityksen kaltaisia toimintoja häiriöittä muille kehitystiimin käyttäjille. Sisällöntekijät voivat myös kehittää Fabric-portaalissa täällä sisältöä, kuten tietovoita. Yksityiset työtilat voivat olla hyvä valinta, kun hallitset sisällön muutoksia käyttämällä Git-integrointia yhdessä Azure DevOpsin kanssa.

Muistiinpano

Azure DevOps on palvelupaketti, joka integroituu Power BI:hin ja Fabriciin ja jonka avulla voit suunnitella ja järjestää sisällön elinkaaren hallinnan. Kun käytät Azure DevOpsia tällä tavalla, hyödynnät yleensä seuraavia palveluita:

• Azure-säilöt: Voit sen avulla luoda ja käyttää Git-etäsäilöä, joka on etäsäilösijainti, jolla voit seurata ja hallita sisällön muutoksia.
• Azure-putket: Voit luoda ja käyttää automatisoituja tehtäviä, joiden avulla voit käsitellä, testata ja ottaa käyttöön sisältöä etäsäilöstä työtilaan.
• Azure Test Plans: Voit suunnitella testejä ratkaisun vahvistamiseksi ja laadunhallinnan automatisoimiseksi yhdessä Azure-putkien kanssa.
• Azure Boards: Voit taulujen avulla seurata tehtäviä ja palvelupaketteja työnimikkeinä sekä linkittää tai viitata muiden Azure DevOps -palveluiden työkohteisiin.
• Azure Wiki: Voit näin jakaa tietoja tiimisi kanssa sisällön ymmärtämiseksi ja osallistumiseksi.

Seuraavassa kaaviossa esitetään korkean tason esimerkki siitä, miten voit käyttää erillisiä ympäristöjä käyttämällä yksityistä työtilaa Git-integroinnin avulla.

Muistiinpano

Kaaviossa esitetään erilliset kehittäjät, jotka työskentelevät ratkaisun erillisten haarojen (haara 1 ja haara 2) parissa ennen muutosten yhdistämistä päähaaraan. Tämä on yksinkertaistettu kuvaus Git-haarautumisstrategiasta, jonka avulla kehittäjät voivat integroida tekemänsä muutokset etäsäilöön ja hyötyä Fabricin Git-integroinnista.

Kaaviossa kuvataan seuraavat prosessit ja komponentit, jotka erottavat työtilat tässä lähestymistavassa.

Kohde	Kuvaus
	Jokainen sisällöntekijä kehittää sisältöä omassa paikallisessa ympäristössään.
	Kun sisältö on valmis, sisällöntuottajat voivat lähettää muutokset etäsäilöön, kuten Azure Repos Git -säilöön.
	Sisällön luojat jäljittävät ja hallitsevat sisällönmuutoksia Git-etäsäilössä lähdekoodin hallinnan avulla sekä haaraamalla ja yhdistämällä sisältöä yhteistyön helpottamiseksi.
	Sisällöntekijät synkronoivat etäsäilön haaran yksityisen työtilan kanssa. Synkronoinnin jälkeen uusimmat muutokset, jotka luoja vahvistaa ja lähettää haaraan, näkyvät kyseisessä yksityisessä työtilassa. Eri sisällöntekijät työskentelevät yksinään erillisiä haaroja tehtyjen muutosten tekemiseen.
	Yksityisissä työtiloissa sisällön luojat voivat kehittää sisältöä käyttämällä verkon luomista ja vahvistaa omat muutoksensa. Verkon tuottamisen tekemän sisällön muutokset voidaan synkronoida Git-säilön haaraan, kun sisällön tekijä vahvistaa ja lähettää nämä muutokset työtilasta. Eri sisällöntekijät työskentelevät omissa, erillisissä yksityisissä työtiloissaan.
	Kun sisällöntuottajat ovat valmiita, he suorittavat pull-pyynnön muutostensa yhdistämiseksi ratkaisun päähaaraan.
	Kun muutokset on yhdistetty, päähaara synkronoituu kehitystyötilan kanssa.
	Kehitystyötilassa sisällöntuottajat voivat kehittää sisältöä, jota Fabric Git -integrointi ei tue, kuten koontinäyttöjä. Sisällöntekijät vahvistavat myös integroidun ratkaisun, joka sisältää kaikki uusimmat muutokset.
	Kun sisältö on valmis, sisällön luojat ottavat sisällön käyttöön testityötilassa. Testityötilassa käyttäjät suorittavat käyttäjän hyväksyntätestauksen sisällölle.
	Kun olet valmis, sisällön luojat ottavat sisällön käyttöön tuotantotyötilassa. Tuotantotyötilassa sisällön luojat jakavat sisältöä julkaisemalla Power BI -sovelluksen tai jakamalla sisältöä työtilasta.

Työtilojen resurssien tuki

Kun käytät erillisiä ympäristöjä, ota huomioon myös se, miten tämä vaikuttaa eri tukiresursseihin, joita käytät näissä ympäristöissä. Mieti näiden tukiresurssien osalta, pitääkö ne myös erottaa samaan vaihemäärään vai miten niiden käyttöä koordinoidaan näissä ympäristöissä.

• Yhdyskäytävät: Harkitse erillisten paikallisten tietoyhdyskäytäväklustereiden ja VNet-yhdyskäytäviä tuotantokuormitusten kanssa. Tämä auttaa estämään häiriöitä, mutta myös varmistamaan käytettävyysajan, kun näitä yhdyskäytäviä on päivitettävä.
• Sovellukset: Harkitse erillisiä sovelluksia testi- ja tuotantotyötiloja varten. Sovelluksia ei voi ottaa käyttöön tai kopioida vaiheiden välillä. Testityötilan sovellusten tarkoituksena on auttaa testaamaan sisältöä ja sovelluksen käyttökokemusta ennen muutosten käyttöönottoa tuotantotyötilassa. Tuotantotyötilan sovellusten tarkoituksena on tarjota sisältöä käyttäjille jäsennellyssä ja tietyssä käyttökokemuksessa.
• Azure DevOps: Jos aiot käyttää Azure DevOpsia lähdekoodin hallinnan ja käyttöönoton yhteistyöhön ja järjestämiseen, harkitse, miten käytät haaroja ja Azure-putkia sisällön käyttöönottoon näiden ympäristöjen välillä. Lisätietoja sisällön käyttöönotosta Azure-putkien avulla on kohdassa Vaihe 4: Sisällön käyttöönotto.

Kun olet päättänyt, miten määrität ja käytät työtiloja, seuraava vaihe on päättää, miten suoritat versionhallinnan sisällön muutosten seuraamista ja hallintaa varten.

Päätä, miten käytät versionhallintaa

Power BI:ssä voit suorittaa versionhallinnan joko Käyttämällä SharePointia/OneDrivea tai käyttämällä Git-etäsäilöä, kuten Azure Reposia, joka on Azure DevOpsin osa. Molemmissa menettelytavoissa lisäät paikallisia sisältötiedostoja etätallennussijaintiin, jotta voit seurata ja hallita muutoksia. Suosittelemme, että käytät SharePointia tai OneDrivea vain pienempiin ja yksinkertaisempiin projekteihin, sillä siinä ei ole ominaisuuksia ja luotettavuutta suurempien tai monimutkaisempien skenaarioiden tukemiseksi.

Seuraavassa on joitakin yleisiä huomioon otettavia seikkoja, joiden avulla voit määrittää ja käyttää versionhallintaa.

• Ilmoitukset: Sinun tulee määrittää hälytyksiä, kun muut lisäävät, poistavat tai muokkaavat kriittisiä tiedostoja.
• Laajuus: Määritä selkeästi etätallennussijainnin laajuus. Ihannetapauksessa etätallennussijainnin laajuus on sama kuin jatkotason työtilat ja sovellukset, joita käytät sisällön toimittamiseen kuluttajille.
• Käyttö: Sinun tulee määrittää käyttöoikeus etätallennussijaintiin käyttämällä samankaltaista käyttöoikeusmallia kuin olet määrittänyt käyttöönottojakson käyttöoikeuksille ja työtilarooleille. Sisällöntekijöiden on päästävä etätallennussijaintiin.
• Dokumentaatio: Lisää etätallennussijaintiin tekstitiedostoja, jotka kuvaavat etäsäilön sijaintia ja tarkoitusta, omistajuutta, käyttöä ja määritettyjä prosesseja.

Seuraavissa osioissa kuvataan jokainen menetelmä ja tärkeä huomioitava seikka päättää, mitä niistä kannattaa käyttää.

Versionhallinta SharePointin tai OneDrive for Workin ja Schoolin avulla

SharePointissa on sisäinen versionhallinta tiedostoja varten. Sisällöntekijät voivat kehittää semanttisia malleja tai raportteja paikallisesti ja heidän tekemänsä muutokset synkronoidaan SharePoint- tai OneDrive for Work- ja School-tiedostokirjastoihin.

Vihje

Käytä SharePointia tai OneDrivea vain versionhallintaan yksinkertaisempissa ja pienemmissä skenaarioissa, kuten itsepalvelusisällön julkaisemisessa. Suurempien tai monimutkaisempien skenaarioiden tapauksessa sinun kannattaa harkita lähteen hallinnan suorittamista etä git-säilön avulla.

Seuraavassa kaaviossa esitetään korkean tason yleiskatsaus siitä, miten versionhallinta suoritetaan SharePointin tai OneDriven avulla.

Kaaviossa kuvataan seuraavat prosessit ja osat.

Kohde	Kuvaus
	Sisällöntekijät kehittävät semanttisia malleja ja raportteja paikallisessa ympäristössään ja tallentavat nämä mallit ja raportit .pbix-tiedostoina.
	Kun sisältö on valmis, sisällöntuottajat tallentavat tekemänsä muutokset, jotka he synkronoivat SharePoint- tai OneDrive for Work- ja School-etäkirjastoon.
	Etäkirjastossa sisällöntuottajat seuraavat tiedostotason muutoksia, jotka helpottavat versionhallintaa.
	Sisällöntekijät voivat linkittää julkaistun semanttisen mallin tai raportin .pbix-tiedostoon OneDrive-päivityksen helpottamiseksi. OneDrive-päivitys julkaisee sisällön muutokset automaattisesti tunnin välein.
	Fabric-työtilassa sisällöntekijät näkevät Power BI -sisällön muutokset, kun OneDrive-päivitys on valmis.

Tärkeä

Voit suorittaa versionhallintaa vain käyttämällä SharePointin tai OneDrive for Power BI Desktopin tiedostoja, jotka sisältävät semanttisia malleja tai raportteja. Et voi helposti hallita versionhallintaa käyttämällä SharePointia tai OneDrivea muissa Power BI -kohdetyypeissä, kuten tietovoissa, tai Fabric-kohdetyypeissä, kuten muistikirjoissa. Näiden muiden kohdetyyppien versionhallinta kannattaa suorittaa käyttämällä Git-etäsäilöä, kuten Azure-säilöä.

Yhteenvetona sisällön luojat voivat linkittää julkaistun semanttisen mallin tai raportin .pbix-tiedostoon, joka on tallennettu SharePoint- tai OneDrive for Work- ja School-kirjastoihin. Tämän lähestymistavan ansiosta sisällöntuottajien ei enää tarvitse julkaista semanttista mallia nähdäkseen muutoksia. Muutokset näkyvät sen sijaan automaattisen OneDrive-päivityksen jälkeen, joka tapahtuu tunneittain. Vaikka tämä lähestymistapa on kätevä, siihen liittyy joitakin huomioon otettavia seikkoja, eikä sitä voi helposti kääntää.

Vaikka sen määrittäminen ja hallinta on helppoa, SharePointin tai OneDriven versionhallinnassa on enemmän rajoituksia. Et voi esimerkiksi tarkastella sisällössä olevia muutoksia, eikä versioiden vertaileminen ole mahdollista. Lisäksi ei ole mahdollista määrittää kehittyneempiä prosesseja näiden muutosten hallitsemiseksi (kuten haarautumis- tai pull-pyynnöt, jotka kuvataan myöhemmin tässä artikkelissa).

Harkitse SharePointin tai OneDriven käyttöä muutosten seuraamiseen ja hallintaan seuraavissa tilanteissa:

• Sisältö koostuu vain semanttisista malleista tai raporteista, jotka on tallennettu .pbix-tiedostoina.
• Omatoimiset käyttäjät luovat ja hallitsevat sisältöä.
• Sisällöntekijät voivat tehdä yhteistyötä Microsoft Teamsin avulla.
• Sisällöntekijöille ei ole kokemusta Gitistä ja lähdekoodin hallinnasta.
• Sisällöntekijät hallitsevat yhtä kohdetta, jonka monimutkaisuus ja yhteistyö ovat rajoitettua.
• .pbix-tiedostoissa on käytössä luottamuksellisuustunniste, joka salaa niiden sisällön.

Muistiinpano

OneDrive ja SharePoint tukevat sisältöä, jossa on käytössä luottamuksellisuustunnisteita joitakin rajoitettuja tilanteita lukuun ottamatta. Fabric Git -integrointi ei sitä vastoin tue luottamuksellisuustunnisteita.

Vältä SharePointin tai OneDriven käyttöä muutosten seuraamiseen ja hallintaan seuraavissa skenaarioissa:

• Sisältö koostuu muista kohdetyypeistä kuin semanttisista malleista ja raporteista.
• Sisältö on monimutkaista tai laajaa.
• Sisällöntuottajien on työstää samaa kohdetta yhteistyössä yhtä aikaa.

Seuraavissa osissa kuvataan muita huomioon otettavia seikkoja, kun versionhallintaa käytetään tehokkaasti SharePointin tai OneDriven ja Power BI:n avulla.

Microsoft Teams -integrointi

Voit käyttää Microsoft Teamsin tiedostokirjastoja, jos sisällöntuottajat käyttävät sitä yhteistyöhön. Tiedostokirjastot ovat SharePoint-sivustoja. Tiedostojen ja yhteistyö on keskitetty erillisen SharePoint-sivuston tai OneDrive-kansion sijaan.

Sisäänkirjautumis- ja uloskuittautumistiedostot

Sinun kannattaa kuitata ulos tiedostot, joita käsittelet, jotta vältät mahdolliset muutosristiriidat. Kun muutokset on tehty, kuittaa tiedostot sisään kommenteilla, jotka kuvaavat muutosta. Tiedostojen tarkistusten ja uloskuittaustiedostojen avulla voit parantaa sisällöntekijöiden välistä yhteistyötä, kun käytät SharePointia tai OneDrive for Workia ja Schoolia versionhallintaa varten. Jos kirjaudut sisään ja kuittaat ulos tiedostoja, joilla on useita sisällöntekijöille, voit muokata SharePoint-sivuston kirjastoa, jotta näet viimeisimmän sisäänkirjautumisen viimeisimmän päivityksen ja kommentit.

Versiohistoria

Varmista, että varmuuskopioit sisällön erilliseen sijaintiin, jos SharePoint-sivuston tiedostokirjastoon osuu odottamattomia häiriöitä. Aseta myös rajat SharePoint-sivustossa säilytetyille versioille ja poista vanhat versiot. Näin varmistetaan, että versiohistoria pysyy merkityksellisenä eikä vie liikaa tilaa.

Jos haluat hienostuneemman versionhallinnan, voit tallentaa tiedostoja etäsäilöön, kuten Azure Reposiin, ja hallita muutoksia lähteen hallinnan avulla.

Lähteen hallinta etä git-säilön avulla

Etäsäilö Git helpottaa tiedostojen lähdehallintaa, jolloin sisällöntekijöille on enemmän vaihtoehtoja muutosten seurantaan ja hallintaan. Lyhyesti sanottuna sisällöntuottajat voivat kehittää sisältöä joko paikallisesti tai Power BI -palvelu ja sitoa ja siirtää muutokset etäsäilöön, kuten Azure Repos -säilöön.

Muistiinpano

Voit myös hallita sisältöäsi lähteen kautta ilman Git-integrointia. Tässä skenaariossa seurataan ja hallitaan edelleen sisällön muutoksia git-etäsäilössä, mutta sisältöä otetaan käyttöön joko REST-ohjelmointirajapintojen tai XMLA-luku- ja kirjoituspäätepisteiden avulla. Lisätietoja näistä menetelmistä sisällön käyttöönottamiseksi on kohdassa Vaihe 4: Sisällön käyttöönotto.

Seuraavassa kaaviossa esitetään korkean tason yleiskatsaus siitä, miten lähteen hallintaa suoritetaan

Kaaviossa kuvataan seuraavat prosessit ja osat.

Kohde	Kuvaus
	Sisällöntekijät kehittävät semanttisia malleja ja raportteja paikallisessa ympäristössään ja tallentavat nämä mallit ja raportit .pbip-tiedostoina. Sisällöntekijät voivat myös kehittää semanttisia malleja ja tallentaa mallin metatietoja.
	Kun sisällöntuottajat ovat valmiita, he tallentavat tekemänsä muutokset ja siirtävät ne säännöllisesti git-etäsäilöön.
	Sisällön luojat seuraavat git-etäsäilössä objektitason muutoksia, jotka helpottavat versionhallintaa. Sisällöntekijät voivat myös luoda haaroja, jotka työstävät sisältöä, ja yhdistää muutokset yksittäiseen haaraan pull-pyyntöjen avulla.
	Sisällöntekijät voivat synkronoida sisällön etäsäilöstä Git-integroinnin avulla. He voivat myös ottaa sisältöä käyttöön muilla tavoilla, kuten Azure-putkissa yhdessä REST-ohjelmointirajapintojen kanssa.
	Fabric-työtilassa sisällöntekijät näkevät Power BI -sisällön muutokset, kun synkronointi tai käyttöönotto on valmis. Sisällöntekijät voivat luoda sisältöä, kuten tietovoita tai muistikirjoja, työtilassa. Jos he käyttävät Git-integrointia, sisällön luojat linkittävät tämän työtilan etäsäilön tiettyyn haaraan.
	Sisällöntekijät voivat sitoa ja siirtää muutoksia työtilasta etäsäilöön Git-integroinnin avulla. Nämä muutokset voivat tuoda kohdemääritelmiä työtilassa laaditulle tuetulle sisällölle, kuten tietovuot ja muistikirjat.

Yhteenvetona sisällöntekijät tallentavat .pbip-tiedostoja, metatietotiedostoja ja ohjeita Azure Reposin keskitettyyn etäsäilöön. Tekninen omistaja koostaa nämä tiedostot. Samalla kun sisällöntekijä kehittää ratkaisua, tekninen omistaja on vastuussa ratkaisun hallinnasta ja muutosten tarkistamisesta ja niiden yhdistämisestä yhdeksi ratkaisuksi. Azure Repos tarjoaa kehittyneempiä vaihtoehtoja muutosten seurantaan ja hallintaan SharePointiin ja OneDriveen verrattuna. Hyvin valvotun ja dokumentoidun säilön ylläpitäminen on välttämätöntä, koska se on kaiken sisällön ja yhteistyön perusta.

Harkitse lähdeohjausobjektin käyttämistä muutosten seuraamiseen ja hallintaan seuraavissa skenaarioissa:

• Keskitetyt tai hajautetut tiimit luovat ja hallitsevat sisältöä.
• Sisällöntekijät voivat tehdä yhteistyötä Azure DevOpsin avulla.
• Sisällöntekijät tuntevat Gatin, lähteen hallinnan ja DataOps-periaatteet.
• Sisällöntekijät hallitsevat monimutkaista tai tärkeää sisältöä tai odottavat sisällön skaalautuvan ja kasvavan monimutkaisuuden ja tärkeyden mukaan.

Seuraavassa on joitakin ennakkoohjeita ja huomioitavia seikkoja, joiden avulla voit käyttää lähdekoodin hallintaa tehokkaasti Azure DevOpsissa.

• Git: Jos haluat lähettää muutoksia etäsäilöön, sisällöntuottajien on ladattava ja asennettava Git, jotta he voivat lähettää muutoksia etäsäilöön. Git on hajautettu versiontarkistusjärjestelmä, joka seuraa tiedostojesi muutoksia. Jos haluat oppia Gitin perusteet, katso Mikä on Git?.
• Työkalut: Jos haluat käyttää Gitiä, sisällöntuottajien on joko käytettävä komentorivikäyttöliittymää (CLI) tai graafista käyttöliittymäasiakasohjelmaa (GUI) SCM:lle, kuten Visual Studiota tai Visual Studio Codea.
• Käyttöoikeudet ja käyttöoikeudet: Jotta Azure Repos Git -säilö voidaan luoda ja käyttää, sisällöntekijöillä on oltava seuraavat:
  • Käyttöoikeustasoksi määritetty Perus (toisin kuin sidosryhmä).
  • Kuulu organisaatiolle ja projektille.
  • Asianmukaiset säilön käyttöoikeudet.
• Fabric Git -integrointi: Jos haluat synkronoida sisällön etäsäilössä Microsoft Fabric -työtilan kanssa, sisällöntuottajat käyttävät Fabric Git -integrointia. Tämä on tärkeää, kun seurataan ja hallitaan Fabric-portaalissa luodun sisällön muutoksia, kuten tietovoita.

Vihje

Jos haluat helpottaa lähdekoodin hallintaa paikallisen kehityksen avulla, suosittelemme käyttämään asiakassovellusta, kuten Visual Studio Codea. Jos käytät Power BI Desktopia sisällön kehittämiseen, voit visual Studio Coden avulla hallita kyseisen sisällön lähdekoodia valmistelulla, vahvistamalla ja työntämällä muutoksia etäsäilöön.

Varoitus

Fabric Git -integroinnissa on joitakin rajoituksia tuettujen kohteiden ja skenaarioiden kanssa. Varmista ensin, että varmistat ensin, sopiiko Fabric Git -integrointi parhaiten tiettyyn skenaarioosi vai tuleeko lähdehallinnan käyttöön ottaa erilainen lähestymistapa.

Lisäksi luottamuksellisuustunnisteita ei tueta Fabric Git -integroinnissa, ja luottamuksellisuustunnisteita sisältävien kohteiden vienti saattaa olla poistettu käytöstä. Jos sisällössäsi on luottamuksellisuustunnisteita, suunnittele, miten voit saavuttaa versionhallinnan noudattamalla samalla tietojen menetyksen estämiskäytäntöjäsi.

Keskeisin etu lähdekoodin hallinnan käytössä Azure Reposissa on sisällöntekijöiden yhteistyön parantaminen sekä sisällön muutoksiin ja käyttöönottoon liittyvän mukauttamisen ja valvonnan lisääminen.

Seuraavassa kaaviossa esitetään korkean tason yleiskatsaus siitä, miten Azure DevOps mahdollistaa yhteistyön lähdekoodien hallinnan kanssa.

Muistiinpano

Edellisessä kaaviossa on yksi esimerkki siitä, miten voit tehdä yhteistyötä Azure DevOpsin avulla. Valitse toimintatapa, joka sopii parhaiten tiimisi tarpeisiin ja työskentelytapaan.

Kaaviossa esitetään seuraavat käyttäjän toiminnot, prosessit ja ominaisuudet.

Kohde	Kuvaus
	Sisällöntekijä tekee uuden lyhytikäisen haaran kloonaamalla päähaaran, joka sisältää sisällön uusimman version. Uutta haaraa kutsutaan usein ominaisuushaaraksi, koska sitä käytetään tietyn ominaisuuden kehittämiseen tai tietyn ongelman korjaamiseen.
	Sisällöntekijä sitoo muutokset paikalliseen säilöön kehityksen aikana.
	Sisällöntekijä linkittää muutoksensa työkohteisiin, joita hallitaan Azure Boardsissa. Työkohteet kuvaavat tietyn kehityksen, parannukset tai niiden haaraan kuuluvat virheenkorjaukset.
	Sisällöntekijä tekee muutokset säännöllisesti. Kun sisältö on valmis, sisällön tekijä julkaisee haaransa etäsäilöön.
	Testatakseen muutoksiaan sisällön tekijä ottaa ratkaisunsa käyttöön eristetyssä työtilassa kehitystyötään varten (ei näytetä tässä kaaviossa). Sisällöntekijä voi myös synkronoida ominaisuushaaran työtilaan Fabric Git -integroinnin avulla.
	Sisällöntuottajat ja sisällön omistajat dokumentoivat ratkaisun ja sen prosessit Azure Wikissä, joka on koko kehitystiimin käytettävissä.
	Kun sisältö on valmis, sisällön tekijä avaa pull-pyynnön, joka yhdistää ominaisuushaaran päähaaraan.
	Tekninen omistaja on vastuussa pull-pyynnön tarkistamisesta ja muutosten yhdistämisestä. Kun käyttäjä hyväksyy pull-pyynnön, hän yhdistää ominaisuushaaran päähaaraan.
	Onnistunut yhdistäminen käynnistää ratkaisun käyttöönoton kehitystyötilassa Azure-putken avulla (ei näytetä tässä kaaviossa). Kun käytät Fabric Git -integrointia, päähaara synkronoituu kehitystyötilaan.
	Julkaisupäällikkö suorittaa ratkaisun lopullisen tarkistuksen ja hyväksynnän. Tämä julkaisuhyväksyntä estää ratkaisun julkaisun, ennen kuin se on valmis. Yrityssisällön julkaisemisessa julkaisupäällikkö suunnittelee ja koordinoi yleensä sisällön julkaisua testi- ja tuotantotyötiloissa. Ne koordinoivat ja viestivät sisällöntuottajien, sidosryhmien ja käyttäjien kanssa.
	Kun julkaisupäällikkö hyväksyy julkaisun, Azure Pipelines valmistelee ratkaisun käyttöönottoa varten automaattisesti. Vaihtoehtoisesti Azure-putki voi myös käynnistää käyttöönottoputken sisällön ylentämiseksi työtilojen välillä.
	Käyttäjät testaavat ja vahvistavat testityötilan sisältöä. Kun käytät Git-integrointia Azure Pipelinesin kanssa käyttöönottoa varten, testityötila ei synkronoidu minkään haaran kanssa.
	Kun käyttäjät ovat hyväksyneet ja vahvistaneet muutokset, julkaisupäällikkö tarkistaa ja hyväksyy ratkaisun lopullisesti, jotta se voidaan ottaa käyttöön tuotantotyötilassa.
	Käyttäjät tarkastelevat sisältöä, joka on julkaistu tuotantotyötilassa. Kun käytät Git-integrointia Azure Pipelinesin kanssa käyttöönottoa varten, tuotantotyötila ei synkronoidu minkään haaran kanssa.

Seuraavissa osissa kuvataan muita huomioon otettavia seikkoja, kun lähdekoodin hallintaa käytetään tehokkaasti Azure DevOpsin ja Power BI:n avulla.

Tärkeä

Haarautumisen, vahvistusten, pull-pyyntöjen ja yhdistämisten tehokas käyttö on oleellista, jotta lähdekoodin hallinta on erittäin hyödyllistä, kun hallitset Power BI -sisältösi elinkaarta.

Haarojen käyttö

Sisällöntekijät voivat tehdä yhteistyötä haaraamisstrategian avulla. Haarastrategian avulla yksittäiset sisällöntuottajat voivat työskennellä erillään paikallisessa säilössään. Kun ne ovat valmiita, ne yhdistävät muutoksensa yhtenä ratkaisuna etäsäilössä. Sisällöntekijöiden tulee rajata työ haaraan linkittämällä heidät tietyn kehityksen, parannuksien tai ohjelmavirhekorjausten työkohteisiin. Jokainen sisällöntekijä luo etäsäilön oman haaran oman haaransa oman toimialaansa varten. Paikallisen ratkaisun työ on varattu ja lähetetty etäsäilön haaran versioon, joka sisältää kuvaavan vahvistusviestin. Vahvistusviesti kuvaa vahvistukseen tehtyjä muutoksia.

Kun käytät haarastrategiaa Fabric-sisällön hallintaan, ota huomioon seuraavat tekijät.

• Mitä haarasisällön tekijöiden tulee kloonata omaa työtään varten. Jos nämä haarat ovat esimerkiksi päähaaran klooni (runkopohjainen kehitys) tai jos ne ovat muita haaroja, kuten sisällön tiettyjä suunniteltuja versioita varten, julkaisuhaarat.
• Määrittää, käytätkö tietyn työn erillisiä sisältöjulkaisuja julkaisuhaarojen avulla.
• Mitkä haarat yhdistävät mihinkin työtilaan, kun käytät Fabric Git -integrointia.

Vihje

Katso Git-haarautumisstrategian käyttöönotto, joka opastaa ja antaa suosituksia siitä, miten voit käyttää haarautumisstrategiaa yhteistyön mahdollistamiseksi tehokkaasti.

Erän muutokset vahvistuksissa

Sisällön kehittämisen aikana sisällöntuottajien tulisi säännöllisesti vaiheistaa muutokset eriksi (tai ryhmiksi). Näiden muutosten tulee koskea tiettyä ratkaisun työkohdetta (kuten ominaisuutta tai ongelmaa). Kun olet valmis, sisällön luojat voivat tehdä nämä vaiheitetut muutokset.

Erämuutokset tällä tavalla tuovat monia etuja.

• Se auttaa jäsennyksessä kehityksessä ja antaa sisällöntekijöille mahdollisuuden tarkastella ja dokumentoida ryhmittelemänsä muutokset.
• Se parantaa suunnittelun ja kehityksen tasausta, jolloin on helpompi linkittää ominaisuuksia ja ongelmia ja saada läpinäkyvyyttä siitä, miten työ etenee.
• Tekniset omistajat voivat helpommin tarkastella sisällöntekijöiden pull-pyyntöjä, jos muutokset eritetään asianmukaisesti ja heillä on selkeät vahvistusviestit.

Kun teet vaiheita ja vahvistat muutoksia Power BI -sisältöön, ota huomioon seuraavat tekijät.

• Määritätpa sitten muutokset paikallisesta säilöstä tai Fabric-työtilasta.
• Sijoita .pbip-tiedostot ylimmän tason kansioihin, kun tallennat useita malleja tai raportteja yhteen säilöön. Tämä helpottaa tekemiesi muutosten tunnistamista ja ryhmittelyä.
• Ohita tahattomat tai hyödyttömät metatietomuutokset gitignore-tiedoston tai .gitattributes-tiedoston avulla. Näin varmistat, että kaikki tekemäsi muutokset ovat merkityksellisiä.

Vihje

Lisätietoja työn järjestämisestä ja vahvistamisesta Git-säilöön on kohdassa Työsi tallentaminen vahvistusten avulla.

Luo pull-pyyntöjä muutosten yhdistämiseksi

Jos haluat yhdistää muutokset, sisällön luoja avaa pull-pyynnön. Pull-pyyntö on vertaisarviointia varten lähettävä pyyntö, joka voi johtaa tehdyn työn yhdistämiseen yhdeksi ratkaisuksi. Yhdistäminen voi aiheuttaa ristiriitoja, jotka on ratkaistava ennen kuin haara voidaan yhdistää. Pull-pyyntöjen tarkistaminen on tärkeää sen varmistamiseksi, että luojat noudattavat organisaation standardeja ja kehitys-, laatu- ja vaatimustenmukaisuusstandardeja.

Kun käytät pull-pyyntöjä Power BI -sisältöön tehtyjen muutosten yhdistämiseen, ota huomioon seuraavat seikat.

• Mitä standardeja ja käytäntöjä käytät mahdollisten tarkistusten suorittamiseen. Voit esimerkiksi käyttää semanttisille malleille parhaita käytäntöjä analysoinnin sääntöjä.
• Lue ohjeet raportin metatietojen muutoksiin. Tätä ei ole helppo lukea ja ymmärtää ilman kolmannen osapuolen työkaluja.
• Yhdistämisristiriitojen korjaaminen ja ratkaiseminen.

Vihje

Lisätietoja pull-pyynnöistä ja yhdistämisstrategioista ja squash-yhdistämisestä saat tarkempia ohjeita ja suosituksia siitä, miten voit helpottaa yhteistyötä parhaiten yhdistämällä muutoksia sisältöön.

Tarkistusluettelo – Kun suunnittelet tiedostojen tallennussijainteja, tärkeimpiä päätöksiä ja toimintoja ovat muun muassa seuraavat:

• Valitse kehitystyökalut: Varmista, että lähestymistapasi kehittää sisältöä vastaa tapaa, jolla teet yhteistyötä muiden sisällöntuottajien kanssa, ja käytä versionhallintaa.
• Valitse mallien ja raporttien .pbip- ja .pbix-muodoista parempi vaihtoehto: Yleensä .pbip-muoto on hyödyllisempi lähdekoodin hallinnan kannalta, mutta itsepalvelukäyttäjät löytävät .pbix-tiedostot helpommin käytettäviksi.
• Erillinen semanttinen malli ja raportin kehitys: Versionhallinta on tehokkainta, kun hallitset eri kohdetyyppien muutoksia erikseen. Mallin ja raportin kehittämisen erottamista pidetään hyvänä käytäntönä.
• Päätä, kuinka monta työtilaa tarvitset: Erillisten ympäristöjen käyttäminen on erittäin tärkeää sisällön elinkaaren hallinnan onnistumisen kannalta. Varmista, että olet selventänyt, kuinka monta työtilaa tarvitset, ja suorita asianmukainen työtilatason suunnittelu.
• Päätä, miten otat käyttöön versionhallinnan: Päätä yksinkertaisemman tavan välillä käyttämällä SharePointia tai OneDrive for Businessia tai käyttämällä Azure DevOpsia lähteen hallinnan helpottamiseksi.
• Etäsäilön määrittäminen: Luo Jäsennetty tila OneDrive-kansioon tai Git Repo -säilöön, johon tallennat sisältöä muutosten seuraamista ja hallintaa varten.
• Jos käytät lähdeohjausobjektia, määritä .gitignore- ja .gitattributes-tiedostot: Varmista, että olet määrittänyt säilön niin, että seuraat vain merkityksellisiä muutoksia.
• Jos käytät lähdeohjausobjektia, määritä haarautuminen ja yhdistämisstrategiat: Varmista, että määrität selkeät prosessit sille, miten määrität lähdeohjausobjektin ja käytät sitä, jotta voit tukea kehitystä parhaiten. Vältä prosessisi liioittelemista. Yritä sen sijaan täydentää nykyistä tapaa työskennellä kehitystiimeissäsi.

Liittyvä sisältö

Tämän sarjan seuraavassa artikkelissa opit vahvistamaan sisällön osana sisällön elinkaaren hallintaa.