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 suunnittelua artikkelisarjaa. Tässä sarjassa keskitytään ensisijaisesti Power BI -kokemukseen Microsoft Fabric. Johdanto sarjaan on artikkelissa Power BI:n käyttöönoton suunnittelun.

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 Excellencen (COE) ja BI-tiimien: Tiimejä, 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öille ja sisällön omistajille: Käyttäjät, jotka luovat sisältöä, jonka he haluavat julkaista Fabric-portaalissa ja jakaa muiden kanssa. 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 hallinnanensimmä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

Yleiskatsaus sisällön elinkaaren hallinnasta on tämän sarjan ensimmäisessä artikkelissa.

Juomaraha

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 Git -integrointi- ja käyttöönottoputkien.
• elinkaaren hallinnan parhaat käytännöt: Tässä artikkelissa on 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 OneDrive- ja SharePoint-integrointi: Tässä artikkelissa on yleiskatsaus niistä vaihtoehdoista, joilla OneDrive for Workiin ja Schooliin tai SharePointiin tallennettuja tiedostoja voidaan käyttää ja tallentaa, kun versionhallinta suoritetaan .pbix-tiedostoille.
• Aloita Gitin käyttö Azure Repos: Tämä artikkelisarja sisältää käytännön vinkkejä, opetusohjelmia ja ohjeita lähteen hallinnan suorittamiseen Git-säilön avulla Azure Reposissa.

Sisällöntekijöiden ja omistajien tulee hallita sisällön muutoksia käyttämällä versionhallintaa. 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.

Juomaraha

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 -projektissa (.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 käyttämällä lähdekoodin hallinnan. Lähteen hallinta tapahtuu, kun tarkastelet ja hallitset muutoksia, sisällössä sen koodiin ja metatietoihin.

Juomaraha

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:

• Mikä tiedostomuotokäytetään: 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.
• Miten voit hallita mukautettua sisältöä: Voit lisätä teemoja, mukautettuja visualisointeja tai kuvia Power BI Desktop -tiedostoihin, mikä saattaa vaatia erillisiä huomioon otettavia seikkoja elinkaaren hallinnassa. Kun sisällöntuottajat esimerkiksi tekevät omia mukautettuja visualisointejaan, heidän tulee tallentaa visualisoinnin määritykset ja hallita niitä erillisessä tiedostossa.
• Esiversio-ominaisuuksien hallinta: Voit halutessasi ottaa käyttöön esikatselutoimintoja tai -asetuksia Power BI Desktopissa, 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, kun korvaat aiemmat versiot. 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 ladata paikallisiin .pbix-tiedostoihin. Voit esimerkiksi varmuuskopioida tämän sisällön noutamalla ja tallentamalla sen metatiedot.

Juomaraha

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 käyttämällä Fabric REST -ohjelmointirajapintoja. Tarkemmin sanottuna voit käyttää Nouda tietovuo - ja Hae tuloskortit päätepisteet.

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 Studiota tai Visual Studio Code: Kehittäjille tarkoitettu integroitu kehitysympäristö semanttisten mallien tai Fabric-muistikirjojen luomiseen ja hallintaan. Sekä Visual Studio että Visual Studio Code 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:n raportin muodostimessa: 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:

• Miten käyttöoikeuksia hallitaan: Muut työkalut saattavat vaatia lisää käyttöoikeuksia, joita sinun tulee hallita.
• Sisällön julkaiseminen: Muut työkalut voivat vaatia lisätoimia 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, esimerkiksi käyttämällä erillisiä -tietoyhdyskäytäviä tai Fabric-kapasiteettia. 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, jotka on kuvattu vuokraajatason ja työtilatason suunnitteluartikkeleissa.

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?
• Haluatko erilliset työtilat kohdetyypinmukaan?
• Kenellä on käyttöoikeus kuhunkin työtilaan?
• Kuuluvatko työtilat Fabric -käyttöönottoputkeenvai järjestätkö käyttöönoton muilla tavoilla, esimerkiksi käyttämällä Azure Pipelines?
• Miten voit hallita työtilojen välillä julkaisemista? Täytyykö sinun esimerkiksi varmistaa, että raporttien testityötilan raportit muodostavat yhteyden semanttisiin malleihin erillisessä tietokohteiden testityötilassa?
• Onko myös tarpeen käyttää erillisiä tukiresursseja tuotantotyötilojen kohteille, kuten erilliselle paikallisen tietoyhdyskäytäväklusterin?

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.

Jos haluat lisätietoja näistä tavoista ottaa sisältöä käyttöön, katso 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.

Item	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.

Item	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

Toimittaessaan liiketoiminnan kannalta tärkeää sisältöä kukin kehittäjä voi käyttää myös omaa, yksityistä työtilaa kehityksen. 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 Power BI:n ja Fabricin kanssa integroitu palvelupaketti, 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 Repos: Tämän avulla voit luoda ja käyttää Git-etäsäilöä, joka on sisällön muutosten seuraamiseen ja hallintaan käytettävä etäsäilö.
• Azure Pipelines -: Sen avulla voit luoda ja käyttää automatisoituja tehtäviä, joiden avulla voit käsitellä, testata ja ottaa käyttöön etäsäilön sisältöä työtilassa.
• Azure Test Plans: Voit sen avulla suunnitella testejä ratkaisun vahvistamiseksi ja laadunhallinnan automatisoimiseksi yhdessä Azure-putkien kanssa.
• Azure Boards: Mahdollistaa taulujen avulla tehtävien ja palvelupakettien seuraamisen työnimikkeinä sekä työkohteiden linkittämisen tai viittaamisen muista Azure DevOps -palveluista.
• Azure Wiki: Voit 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 jolla kuvataan, miten kehittäjät voivat integroida muutoksensa etä-Git-säilöön ja hyötyä Fabricin Git-integroinnista.

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

Item	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ä.

• Gateways: Harkitse erillisten paikallisten tietoyhdyskäytäväklustereiden - ja VNet-yhdyskäytäviä tuotannon kuormituksia varten. 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ä.
• Apps: 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 yhteistyöhön ja järjestää lähdekoodin hallinnan ja käyttöönoton, harkitse, miten käytät haaroja ja Azure-putkia sisällön käyttöönottoon näiden ympäristöjen välillä. Jos haluat lisätietoja sisällön käyttöönotosta Azure-putkien avulla, katso 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 versionhallintaa joko Käyttämällä SharePointia/OneDrivea tai käyttämällä Git-etäsäilöä, kuten Azure Repos, joka on osa Azure DevOps. 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.
• Vaikutusalue-: Määritä etätallennussijainnin laajuus selkeästi. Ihannetapauksessa etätallennussijainnin laajuus on sama kuin jatkotason työtilat ja sovellukset, joita käytät sisällön toimittamiseen kuluttajille.
• Access: Määritä etätallennussijainnin käyttöoikeus käyttämällä samankaltaista käyttöoikeusmallia kuin olet määrittänyt käyttöönottoputken käyttöoikeudet ja työtilarooleille. Sisällöntekijöiden on päästävä etätallennussijaintiin.
• Dokumentaation: Lisää tekstitiedostoja etätallennussijaintiin kuvaamaan etätallennussijaintia ja sen 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.

Juomaraha

Käytä SharePointia tai OneDrivea vain versionhallintaan yksinkertaisemmilla ja pienemmillä skenaarioilla, kuten omatoimista sisällön julkaisua. Suurempien tai monimutkaisempien skenaarioiden tapauksessa sinun kannattaa harkita lähdehallinnan suorittamista etäsäilön.

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

Kaaviossa kuvataan seuraavat prosessit ja osat.

Item	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 linkin julkaistuun semanttiseen malliin tai raporttiin .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, kun automaattinen OneDrive -päivitys, 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 esimerkiksi voi tarkastella muutoksia, sisällä sisältöä, eikä versioita voi myöskään vertailla. Lisäksi ei ole mahdollista määrittää kehittyneempiä prosesseja näiden muutosten hallitsemiseksi (kuten haarautumis- tai pull-pyynnöt, 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 lukuun ottamatta joitakin rajoitettuja skenaarioita. 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 tulee uloskuittausta tiedostoista, 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ön luojat voivat kehittää sisältöä joko paikallisesti tai Power BI -palvelussa ja sitten sitoa ja siirtää muutokset Etä-Git-säilöön, kuten Azure Repossiin

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ä sisällön käyttöönottotavoista 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.

Item	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. 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 sitouttaa ja siirtää muutoksia etäsäilöön, sisällöntuottajien on ladattava ja asennettava Git. Git on hajautettu versiontarkistusjärjestelmä, joka seuraa tiedostojesi muutoksia. Jos haluat oppia Gitin perusteet, katso Mikä Git on?.
• Tools: Jos haluat käyttää Gitiä, sisällöntuottajien on käytettävä joko komentorivikäyttöliittymää (CLI) tai GRAafista käyttöliittymän (GUI) asiakasta SCM:lle, kuten Visual Studio tai Visual Studio Code.
• käyttöoikeuksia ja käyttöoikeuksia: Jos haluat luoda Azure Repos Git -säilön ja käyttää sitä, sisällöntekijöillä on oltava seuraavat:
  • käyttöoikeustason määritetty perustasoksi (sidosryhmän jäseniin verrattuna).
  • Kuulu organisaation ja -projektin.
  • Asianmukaiset säilön käyttöoikeudet.
• Fabric Git -integroinnin: Jos haluat synkronoida etäsäilön sisällön Microsoft Fabric -työtilassa, 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.

Juomaraha

Jos haluat helpottaa lähdekoodin hallintaa paikallisen kehityksen avulla, suosittelemme käyttämään asiakassovellusta, kuten Visual Studio Code. 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 voidaan poistaa 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.

Item	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ä käyttämällä haarastrategiaa. 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 (eli runkopohjainen kehitys) tai jos ne ovat muita haaroja, kuten sisällön suunniteltujen erikoisversioiden julkaisuhaaroja.
• Määrittää, käytätkö tietyn työn erillisiä sisältöjulkaisuja julkaisuhaarojen.
• Mitkä haarat yhdistävät mihinkin työtilaan, kun käytät Fabric Git -integrointia.

Juomaraha

Artikkelissa Git-haarautumisstrategian käyttöönotto on erityisiä ohjeita ja suosituksia siitä, miten voit parhaiten käyttää haarautumisstrategiaa yhteistyön tehostamiseksi.

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 käyttämällä Gitignore-tiedostoa tai .gitattributes-tiedostoa. Näin varmistat, että kaikki tekemäsi muutokset ovat merkityksellisiä.

Juomaraha

Artikkelissa Työsi tallentaminen vahvistusten on erityisiä ohjeita ja suosituksia siitä, miten voit vaiheistaa ja sitoa työsi Git-säilöön.

Luo pull-pyyntöjä muutosten yhdistämiseksi

Jos haluat yhdistää muutokset, sisällön tekijä 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ää semanttisten mallien parhaita käytäntöjä analysoivan sääntöjä.
• Lue ohjeet raportin metatietojen muutoksiin. Tätä ei ole helppo lukea ja ymmärtää ilman kolmannen osapuolen työkaluja.
• Miten osoitteen ja ratkaista yhdistämisristiriidat.

Juomaraha

Katso Tietoja pull-pyynnöistä ja Yhdistä strategiat ja squash merge saadaksesi erityisiä ohjeita ja suosituksia siitä, miten yhteistyön helpottamiseen pull-pyyntöjä kannattaa käyttää sisällön muutoksia yhdistämällä.

tarkistusluettelon – Kun suunnittelet tiedostojen tallennussijainteja, tärkeimmät päätökset ja toiminnot ovat seuraavat:

• Valitse kehitystyökalut: Varmista, että lähestymistapasi kehittää sisältöä vastaa sitä, miten teet yhteistyötä muiden sisällöntuottajien kanssa ja käytät versionhallintaa.
• Valitse mallien ja raporttien .pbix-muotojen ja .pbix-muotojen välillä: Yleensä .pbip-muoto on entistä hyödyllisempi lähdehallinnan kannalta, mutta itsepalvelukäyttäjät voivat pitää .pbix-tiedostoja helppokäyttöisempinä.
• Erillisen semanttisen mallin ja raportin kehitys: Versionhallinta on tehokkain, 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 suoritat asianmukaiset työtilatason suunnittelun.
• Päätä, miten otat versionhallinnan käyttöön: Päätä yksinkertaisemman lähestymistavan 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 OneDrive-kansioon tai Git Repoan jäsennetty tila, johon tallennat sisältöä muutosten seuraamista ja hallintaa varten.
• Jos käytät lähdekoodin hallintaa, määritä .gitignore- ja .gitattributes-tiedostot: Varmista, että määrität säilön niin, että seuraat vain merkityksellisiä muutoksia.
• Jos käytät lähdekoodin hallintaa, määritä haarat ja yhdistämisstrategiat: Varmista, että määrität selkeät prosessit sille, miten määrität ja käytät lähteen hallintaa kehityksen parasta tukea varten. Vältä prosessisi liioittelemista. Yritä sen sijaan täydentää nykyistä tapaa työskennellä kehitystiimeissäsi.

Aiheeseen liittyvä sisältö

Tämän sarjan seuraavan artikkelissaopi vahvistamaan sisältö osana sisällön elinkaaren hallintaa.