Valitse sinulle paras Fabric CI/CD -työnkulkuvaihtoehto

Tässä artikkelissa esitellään Fabric-kehittäjille erilaisia vaihtoehtoja CI/CD-prosessien rakentamiseen Fabric-ohjelmassa yleisten asiakastilanteiden perusteella. Tässä artikkelissa keskitytään tarkemmin CI/CD-prosessin jatkuvaan käyttöönottoon (CD). Jatkuvan integraation (CI) osalta keskustelua varten katso Development process in Microsoft Fabric.

Tässä artikkelissa esitellään useita eri vaihtoehtoja, mutta monet organisaatiot omaksuvat yhdistelmämenetelmän.

Edellytykset

CI/CD-prosessin rakentamiseen tämän artikkelin vaihtoehtojen avulla tarvitset:

• Microsoft Fabric -tilaus

• Fabric-työtila (sinun täytyy olla työtilan ylläpitäjä käyttöönoton konfigurointiin)

• Git-pohjaisissa vaihtoehdoissa (1, 2 ja 4) tuettu Git-palveluntarjoaja (Azure DevOps tai GitHub) yhdistetään Git-integraation kautta

Kehitysprosessi

Kehitysprosessi on sama kaikissa käyttöönottoskenaarioitassa. Se on riippumaton siitä, miten uusia päivityksiä julkaistaan tuotantoon. Kun kehittäjät työskentelevät lähteen hallinnan parissa, heidän on työskenneltävä eristetyssä ympäristössä. Fabricissa tämä ympäristö voi olla joko integroitu kehitysympäristö paikallisessa koneessa (kuten Power BI Desktop tai VS Code) tai eri työtila Fabricissa. Löydät tietoa kehitysprosessin eri näkökohdista Development Process -osiossa Microsoft Fabric.

Git Sync tukee sekä työtilan muutosten tekemistä Gitille että työtilan päivittämistä Gitistä. PR-nuoli näyttää suunnan, johon yhdistät ominaisuusmuutokset jaettuun kehityshaaraan, ei kaksisuuntaista synkronointitoimintoa.

Julkaisukäsittely

Julkaisuprosessi käynnistyy, kun uudet päivitykset on valmis ja pull-pyyntö (PR) yhdistetään tiimin jaettuun haaraan (kuten Pää, Kehitys jne.). Tässä vaiheessa Fabric-julkaisuprosessin luomiseen on erilaisia vaihtoehtoja.

Seuraava taulukko tiivistää vaihtoehdot, jotka auttavat sinua valitsemaan. Monet joukkueet yhdistävät useamman kuin yhden joukkueen.

¹ Vaihtoehdossa 2 vain Dev-työtila on yhdistetty Gitiin. Test- ja Prod-työtilat eivät ole yhteydessä Gitiin. Julkaisutunnisteen painaminen päätasolla laukaisee putken, joka ottaa kyseisen version käyttöön Testissä. Onnistuneen validoinnin ja hyväksynnän jälkeen putki ottaa käyttöön saman tagin ja sitoutuu SHA:han Prodiin.

Nämä vaihtoehdot eivät vaadi erityistä haarautumisstrategiaa, kuten Gitflow'ta tai trunk-pohjaista kehitystä. Tärkeintä on, että jokainen vaihe julkaisee tunnetun, versioidun commitin, ja että Prod saa saman sisällön kuin testasit.

Vaihtoehdot 1 ja 2 eroavat siinä, miten järjestät ja mainostat julkaisuja, ei pelkästään työkalujen valinnassa. Molemmat vaihtoehdot voivat käyttää fabric-cicd- tai Fabric Items -rajapintoja sekä ympäristökohtaista parametrisointia. Vaihtoehto 1 edistää muutoksia eri vaiheiden haarojen kautta. Vaihtoehto 2 käyttää julkaisutunnistetta pääjärjestelmässä käynnistääkseen saman commingin käyttöönoton Testissä ja validoinnin ja hyväksynnän jälkeen Prodiin.

Käyttöönottosuunnitelma ei ole erillinen työnkulkuvaihtoehto. Voit käyttää suunnitelmaa, jossa on tuettuja Git-toimintoja vaihtoehdossa 1, käyttöönottoputkia vaihtoehdossa 3, tai kutsumalla Bulk Import Item Definitions API :n suoraan vaihtoehdoista 1, 2 ja 4. Kirjasto fabric-cicd ei tue käyttöönottosuunnitelmia, edes kun käytät massatuontitilaa. Suunnitelma ohjaa käyttöönottojärjestystä, riippuvuuksia ja toimintoja, kun taas valittu työnkulku määrittelee totuuden lähteen, mitä kukin vaihe ottaa käyttöön ja vaiheen konfiguraatiota.

Vaihtoehto 1 – Määritelmäpohjaiset käyttöönotot vaihekohtaisista Git-haaroista

Tämän vaihtoehdon myötä kaikki käyttöönotot tulevat Gitistä. Jokaisella tasolla on oma päähaara: Dev, Testja Prod tässä esimerkissä. PR:t edistävät muutoksia näiden haarojen välillä, ja jokainen työtila saa määritelmät oman vaiheensa haarasta. Voit ottaa käyttöön Git-integraation, fabric-cicd- tai Fabric Items -rajapintojen avulla. Kun käytät fabric-cicd:tä tai Items API:ta, kohdetyötila ei tarvitse Git-yhteyttä. Määrittävä ominaisuus on eri haara kullekin vaiheelle, ei käyttöönottotyökalu.

Kun kehityshaaran PULL-pyyntö on hyväksytty ja yhdistetty:

1. Päivitä Dev-työtila Dev-haarasta, esimerkiksi Git-integraation avulla. Suorita yksikkötestit ja tarvittavat jälkitoiminnot.
2. Luo PR testihaaralle niistä muutoksista, joita haluat edistää. Voit käyttää vapautushaarukkaa poimiaksesi nuo muutokset. Sovella tiimisi tarkastus- ja hyväksymisprosesseja.
3. Ota tietty commit Test-haarasta Test-työtilaan käyttämällä Git-integraatiota, fabric-cicd- tai Fabric Items -rajapintoja. Käytä vaihekohtaista konfiguraatiota ja suorita automatisoituja tai manuaalisia testejä.
4. Luo PR Prod-haaralle , joka edistää validoituja muutoksia. Tarkista syntyneet määritelmät varmistaaksesi, että ne vastaavat testattua julkaisua, paitsi tarkoituksellisessa vaihekohtaisessa kokoonpanossa. Jos lisäät muita muutoksia, vahvista ne Testissä ennen ylennystä.
5. Hyväksynnän jälkeen ota Prod-haara käyttöön Prod-työtilassa valitsemallasi käyttöönottotyökalulla. Suorita tarvittavat käyttöönoton jälkeiset tarkistukset ja tiedon vastaanottotoiminnot.

Jotkut esineriippuvuudet sitoutuvat automaattisesti loogisten tunnisteiden kautta. Toiset tarvitsevat parametrisointia tai jälkiasennuspäivityksiä. Lisätietoja löytyy kohdasta Understanding dependent binding in cross-workspace deployment.

Mitä komponentteja voidaan käyttää vaihtoehdon #1 toteuttamiseen?

• Git-integraatio: Yhdistä jokainen työtila sen vaihehaaraan. Päivitä se Fabric UI:n kautta tai automatisoi päivitykset Fabric Git -rajapintojen avulla.
• fabric-cicd: Tutustu vaiheen haaraan ja julkaise sen tuotemääritelmät ympäristökohtaisilla parametreilla. Kohdetyötila ei tarvitse Git-yhteyttä.
• Fabric Items API:t: Ota määritelmät käyttöön vaiheen haarasta kutsumalla Create item ja Päivitä item definition, tai Bulk Import Item Definitions API:ta. Kun kutsut API:t suoraan, automaatio valmistaa määritelmät ja vaihekohtaiset konfiguraatiot.

Toteutusesimerkkejä löytyy fabric-cicd- ja Azure DevOps -opetusohjeesta tai Fabric CI/CD:stä Bulk Import Item Definitions API:lla.

Milloin kannattaa harkita vaihtoehdon 1 käyttämistä?

• Kun haluat käyttää Git-säilöä ainoana totuuden lähteenä ja kaikkien käyttöönottojen alkuperänä.
• Kun haluat erillisen päähaaran jokaiselle vaiheelle, PR-pohjaisella tarkastelulla ja ylennysellä vaiheiden välillä.
• Kun haluat hallita vaihekohtaisia määritelmiä Gitissä tai soveltaa ympäristökohtaista konfiguraatiota valitsemallasi käyttöönottotyökalulla.

Vaihtoehto 2 - Määritelmäpohjaiset käyttöönotot jaetusta julkaisusitoutumisesta

Tämän vaihtoehdon avulla kehittäjät työskentelevät Dev-haaran parissa, joka on yhdistetty Dev-työtilaan. Päähaara on vapautushaara: se sisältää vain ne muutokset, jotka päätät julkaista. Test- ja Prod-työtilat eivät ole yhteydessä Gitiin. Julkaisutunnisteen painaminen Mainilla käynnistää GitHub Actions -työnkulun tai Azure DevOps -putken. Se ottaa merkityn version käyttöön Testissä, suorittaa validoinnin ja odottaa tuotantohyväksyntää ennen kuin ottaa saman tagin käyttöön ja sitoutuu SHA:n Prodiin. Putki voi käyttää rakennusympäristöä yksikkötestauksen suorittamiseen ja kohteiden määritelmien säätämiseen ennen niiden lataamista. Esimerkiksi voit muuttaa tietolähteiden yhteyksiä, viittauksia muihin kohteisiin tai parametrien arvoja kohdevaiheelle. Kaikki esineriippuvuudet eivät vaadi näitä muutoksia. Jotkut sitoutuvat automaattisesti loogisten tunnisteiden kautta, kun ne otetaan käyttöön uudessa työtilassa. Lisätietoja löytyy kohdasta Understanding dependent binding in cross-workspace deployment.

Vapautusprosessi etenee seuraavasti:

1. Kehittäjät yhdistävät hyväksytyt PR:t Dev-haaraan, ja Dev-työtila päivitetään Gitistä.
2. Valmistelessasi julkaisua, luo PR, joka poimii ne muutokset, jotka haluat julkaista DevistäMainiksi. PR:n tulisi sisältää samat tarkastus- ja hyväksymisprosessit kuin muidenkin tiimisi tai organisaatiosi PR-asiantuntijoiden.
3. Luo vapautustunniste valitulle commitille päätasolla, esimerkiksi v1.5.0. Paina tagia käynnistääksesi GitHub Actions -työnkulun tai Azure DevOps -putken, joka on konfiguroitu julkaisutunnisteille.
4. Putkisto ratkaisee tagin commit-SHA:ksi, tallentaa molemmat, tarkistaa commitin, suorittaa yksikkötestit ja säätää Testin konfiguraatiota. Se lataa nämä kohdemäärittelyt testityötilaan käyttämällä fabric-cicd: tä tai Bulk Import Item Definitions API:a. Lisätietoja löytyy kohdasta Mitkä komponentit voidaan käyttää vaihtoehdon #2 toteuttamiseen. Suorita automatisoituja tai manuaalisia testejä käyttöönoton jälkeen. Jos validointi epäonnistuu, lopeta ylennys tuotantoon.
5. Kun validointi on onnistunut, putkisto odottaa konfiguroidulla tuotantolupaportilla. Käytä GitHub-ympäristön hyväksyntää tai Azure DevOps -ympäristön hyväksyntätarkistusta.
6. Hyväksynnän jälkeen ota käyttöön sama julkaisutunniste ja tallennettu commit SHA Prodiin. Vain vaihekohtaiset konfiguraatiot, kuten Variable Library -arvojoukot tai parametritiedostot, eroavat Testistä. Suorita tuotantokohtaisia tarkistuksia ja käynnistä muutos vaatima tiedon vastaanotto minimoidaksesi kuluttajien saatavuuden.

Jos validointi epäonnistuu, tee korjaus ensin kehityksessä ja sitten valitse se päätasolle. Luo uusi julkaisutunniste ja toista putkisto, mukaan lukien testin validointi. Tämä lähestymistapa varmistaa myös, että tulevissa kehittäjäjulkaisuissa on korjaus.

Jäljitettävyyden vuoksi määritä käyttöönottotehtävät kohdistumaan vastaaviin GitHub- tai Azure DevOps -ympäristöihin. Sisällytä julkaisutunniste ja ratkaistu commit SHA jokaiseen käyttöönottotietueeseen, jotta voit tunnistaa, mikä versio saavutti testin ja tuotannon. Pelkkä Git-tunniste ei tallenna, missä versio on otettu käyttöön.

Mitä komponentteja voidaan käyttää vaihtoehdon #2 toteuttamiseen?

• Fabric-cicd – Python-kirjasto, joka on suunniteltu käytettäväksi Microsoft Fabricin työtilojen kanssa. Tämä kirjasto tukee koodilähtöisiä jatkuvan integraation / jatkuvan käyttöönoton (CI/CD) automaatioita, joiden avulla työtilat integroidaan saumattomasti käyttöönoton kehykseen. Täydellisen kokonaisen esimerkin löydät fabric-cicd- ja Azure DevOps -opetusohjeeltamme. Fabric-CICD tukee kahta julkaisutilaa:
  • Tuotemäärittely API:t (oletus): Julkaisee kohteet yksi kerrallaan käyttämällä Fabric Create item ja Update item definition API:t.
  • Bulk import (kokeellinen): Julkaisee kaikki kohteet yhdellä kutsulla käyttämällä Bulk Import Item Definitions API:a. Tämän tilan käyttämiseksi ota enable_experimental_features käyttöön ja enable_bulk_publish feature -liput. Lisätietoja löytyy katsosta fabric-cicd bulk publish.
• Bulk-Import-Item-Definitions-API – API tukee sekä uusien kohteiden luomista että olemassa olevien päivittämistä, samalla kun se luottaa Fabricin sisäänrakennettuun riippuvuuskäsittelyyn varmistaakseen, että kohteet otetaan käyttöön oikeassa järjestyksessä. Tämä mahdollistaa johdonmukaiset, toistettavat käyttöönotot testaus- ja tuotantoympäristöihin ilman manuaalista puuttumista. Esimerkkiopas löytyy Fabric CI/CD:stämme Bulk Import Item Definitions API:lla.

Milloin kannattaa harkita vaihtoehdon 2 käyttämistä?

• Kun tarvitset ympäristökohtaista parametrisointia kohteiden määrittelylle ennen käyttöönottoa. Fabric-cicd-parametrisointiominaisuus käyttää parameter.yml tiedostoa korvaamaan arvot jokaiselle kohdeympäristölle, mukaan lukien yhteys-ID:t ja järvitalo-ID:t, ilman erillisiä elementtimäärittelyjä jokaiselle vaiheelle. Se tukee etsi ja korvaa -toimintoja, JSON-poluilla valittujen arvojen korvaamista sekä kohdetyötilan tunnisteiden dynaamista ratkaisua. Tämä ominaisuus on saatavilla myös vaihtoehdossa 1, kun käytät fabric-cicd-menetelmää. Pelkkä Git-integraatio ei tarjoa tätä käyttöönottoaika-korvausta.
• Kun haluat käyttää Gitiä ainoana totuuden lähteenä ja kaikkien käyttöönottojen alkuperänä.
• Kun haluat valita, mitkä muutokset tulevat kuhunkin julkaisuun, ja otat käyttöön merkityn, testatun version Prodiin.

Vaihtoehto 3 – Käyttöönotto Fabric-käyttöönottoputkien avulla

Tämän asetuksen avulla Git on yhdistetty vain kehitysvaiheeseen asti. Kehitysvaiheessa käyttöönotot tapahtuvat suoraan Dev/Test/Prod-työtilojen välillä Fabric-käyttöönottoputkien avulla. Voit ottaa käyttöön vaiheiden välillä suoraan Fabric UI:sta tai käyttää käyttöönottoputkien rajapintoja orkestroidaksesi käyttöönoton osana Azure-julkaisun putkea tai GitHub-työnkulkua. Näiden ohjelmointirajapintojen avulla tiimi voi luoda samanlaisen koontiversio - ja julkaisuprosessin kuin muissa asetuksissa, käyttämällä automaattisia testejä (jotka voidaan tehdä itse työtilassa tai ennen kehitysvaihetta ), hyväksyntöjä jne.

Kun käyttöönotto vaatii tietyn järjestyksen, siihen liittyviä asioita tai toimintoja, voit liittää käyttöönottosuunnitelman vaiheiden väliseen käyttöönottoon. Käyttöönottosäännöt ja automaattisidonta hallitsevat edelleen vaihekohtaista konfiguraatiota.

Kun hyväksyt ja yhdistät PR:n Dev-työtilaan liitettyyn haaraan:

1. Päivitä Dev-työtila Gitistä käyttämällä Fabric UI:ta tai Fabric Git -rajapintoja. Suorita kaikki tarvittavat päivityksen jälkeiset toiminnot ja testit.
2. Ota muutokset käyttöön DevistäTestiin käyttämällä Fabric-käyttöönottoputkia, joko Fabric-käyttöliittymästä tai käyttöönoton putkien API-rajapintojen kautta. Suorita automatisoituja tai manuaalisia testejä Testissä ennen muutosten edistämistä Prodiin.
3. Kun testit läpäisevät ja julkaisupäällikkö on hyväksynyt, ota validoitu sisältö käyttöön TestistäProdiin. Älä päivitä valittua sisältöä Testissä validoinnin ja käyttöönoton välillä Prodiin testaamatta sitä uudelleen.

Voit suorittaa nämä vaiheet Fabric UI:sta tai automatisoida ne API:lla Azure Pipelines tai GitHub Actions. Et tarvitse ulkoisia build- ja release-putkia käyttöliittymäpohjaiseen työnkulkuun.

Milloin kannattaa harkita vaihtoehdon 3 käyttämistä?

• Kun tiimisi suosii Fabric:n sisäänrakennettua käyttöönottokokemusta ja sen kyvykkyyksiä, jotka vastaavat käyttöönottotarpeitasi. Voit ottaa käyttöön työtilojen välillä Fabric UI:n kautta ilman ulkoisten julkaisuputkien ylläpitoa, ja käyttää API-rajapintoja automaatioon tarvittaessa. Tämä lähestymistapa sopii myös tiimeille, joilla on rajallinen kokemus DevOps-työkaluista, kuten Azure Pipelines tai GitHub Actions.
• Kun käytät lähteen hallintaa vain kehitystarkoituksiin, ja haluat ottaa muutokset käyttöön suoraan julkaisuputken vaiheiden välillä.
• Kun käyttöönottosäännöt, automaattinen sidonta ja muut käytettävissä olevat ohjelmointirajapinnat riittävät hallitsemaan kokoonpanoja julkaisuputken vaiheiden välillä.
• Kun haluat käyttää muita Fabric-käyttöönottoputkien toimintoja, kuten Kankaan muutosten tarkastelemista, käyttöönottohistoriaa jne.
• Ota huomioon myös se, että Fabric-käyttöönottojaksojen käyttöönotoissa on lineaarinen rakenne ja että ne edellyttävät muita käyttöoikeuksia putken luomiseen ja hallintaan.

Vaihtoehto 4 – CI/CD ohjelmistotoimittajille Fabricissa (useiden asiakkaiden/ratkaisujen hallinta)

Tämä vaihtoehto on erilainen kuin muut. Se sopii parhaiten riippumattomille ohjelmistotoimittajille (ISV), jotka luovat SaaS-sovelluksia asiakkailleen Fabricin pohjalta. Ohjelmistotoimittajilla on yleensä erillinen työtila kullekin asiakkaalle, ja niillä voi olla jopa useita satoja tai tuhansia työtiloja. Kun kullekin asiakkaalle annettavan analyysin rakenne on samankaltainen ja valmis, suosittelemme keskitettyä kehitys- ja testausprosessia, joka jakautuu kuhunkin asiakkaaseen vain Prod-vaiheessa .

Tämä vaihtoehto perustuu vaihtoehtoon #2:

1. Kehittäjät työskentelevät Dev-haaran ja Dev-työtilan parissa ja valitsevat ne muutokset, jotka he haluavat julkaista DevistäMainiksi, kuten kuvataan vaihtoehdossa #2.
2. Luo ja työnnä vapautustunniste valitulle commitille päätasolla, esimerkiksi v1.5.0. Tagi käynnistää GitHub Actions -työnkulun tai Azure DevOps -putken.
3. Putkisto ratkaisee tagin commit SHA:ksi, tallentaa molemmat, suorittaa yksikkötestit ja säätää tunnistettuja määritelmiä jaetulle Testille. Se ottaa ne käyttöön fabric-cicd: llä tai Bulk Import Item Definitions API:lla, kuten kuvataan vaihtoehdossa #2. Suorita automatisoituja tai manuaalisia testejä käyttöönoton jälkeen. Jos validointi epäonnistuu, pysäytä markkinointi, korjaa ongelma Devissä, tuo korjaus päätasolle ja luo uusi tagi uudelle pelikierrokselle.
4. Kun validointi on onnistunut ja konfiguroitu tuotantohyväksyntä on myönnetty, ota sama tagi ja tallennettu commit SHA käyttöön jokaisen asiakkaan Prod-työtilassa . Sovella asiakaskohtaisia parametreja ja yhteyksiä ennen käyttöönottoa tai jälkikäyttörajapintojen kautta. Itsenäiset asiakaskäyttöönotot voivat toimia rinnakkain. Tallenna tagi, sitoutuva SHA ja asiakaskohde ympäristön käyttöönottohistoriaan, jotta jokaisen asiakkaan käyttöön otettu versio on jäljitettävissä.

Milloin kannattaa harkita vaihtoehdon 4 käyttämistä?

• Olet IsV-rakennussovellus Fabricin päällä.
• Käytät kullekin asiakkaalle eri työtiloja sovelluksen usean vuokraajan hallintaan
• Jos haluat enemmän irtisanoutumista tai erityistestejä eri asiakkaille, haluat ehkä käyttää usean vuokrauksen kehitys- tai testivaiheita aikaisemmissa vaiheissa. Tässä tapauksessa ota huomioon, että usean vuokrauksen yhteydessä vaadittujen työtilojen määrä kasvaa merkittävästi.

Yhteenveto

Tässä artikkelissa on yhteenveto tärkeimmistä CI/CD-vaihtoehdoista tiimille, joka haluaa luoda automatisoidun CI/CD-prosessin Fabricissa. Vaikka valitsemme neljä vaihtoehtoa, reaaliaikaiset rajoitteet ja ratkaisuarkkitehtuuri saattavat sopia hybridivaihtoehtoihin tai täysin erilaisiin vaihtoehtoihin. Tämän artikkelin avulla voit opastaa eri vaihtoehtojen ja niiden luomisen läpi, mutta et joudu valitsemaan vain yhtä vaihtoehdoista.

Joillakin skenaarioilla tai tietyillä kohteilla voi olla rajoituksia, jotka voivat estää sinua omaksumasta mitään näistä skenaarioista.

Sama koskee työkaluja. Vaikka mainitsemmekin tässä erilaisia työkaluja, voit ehkä valita muita työkaluja, jotka voivat tarjota saman toimintotason. Huomaa, että Fabric on integroitu paremmin joihinkin työkaluihin, joten muiden valitseminen lisää rajoituksia, jotka tarvitsevat erilaisia tapoja.

Liittyvä sisältö

• Kehitysprosessi Microsoft Fabric:ssa
• Automatisoi Git-integrointi käyttämällä ohjelmointirajapintoja ja Azure DevOpsia
• Automatisoi käyttöönottoputki Fabric-ohjelmointirajapintojen avulla
• Ymmärrä riippuvuussidonta työtilan välisessä käyttöönotossa
• Mikä on käyttöönottosuunnitelma Microsoft Fabric:ssa?