Jaa

Valitse sinulle paras Fabric CI/CD -työnkulkuvaihtoehto

  • Artikkeli

Tämän artikkelin tavoitteena on antaa Fabric-kehittäjille erilaisia vaihtoehtoja CI/CD-prosessien rakentamiseen Fabricissa yleisten asiakasskenaarioiden perusteella. Tässä artikkelissa keskitytään tarkemmin CI/CD-prosessin jatkuvaan käyttöönottoon (CD). Jos haluat keskustella jatkuvan integraation (CI) osasta, katso Git-haarojen hallinta.

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

Edellytykset

Jotta voit käyttää käyttöönottoputkia, sinun on täytettävä seuraavat ehdot:

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 erilaisista huomioitavista asioista kehitysprosessissa kohdasta Git-haarojen hallinta

Kaavio, joka näyttää kehitysprosessin toiminnan.

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.

Vaihtoehto 1 – Git-pohjaiset käyttöönotot

Kaavio, joka näyttää Git-perustaisen käyttöönoton toiminnan.

Tässä vaihtoehdossa kaikki käyttöönotot ovat peräisin Git-säilöstä. Jokaisella julkaisuputken vaiheella on erillinen ensisijainen haara (kaaviossa nämä vaiheet ovat Dev, Test ja Prod), joka syöttää sopivaa työtilaa Fabricissa.

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

  1. Kehitystyötilan sisällön päivittäminen käynnistetään julkaisuputkella. Tämä prosessi voi sisältää myös koontijakson yksikkötestien suorittamiseksi, mutta tiedostojen todellinen lataus tehdään suoraan säilöstä työtilaan Fabric Git -ohjelmointirajapintojen avulla. Sinun on ehkä kutsuttava muita Fabric-ohjelmointirajapintoja käyttöönoton jälkeisiä toimintoja varten, jotka määrittävät tämän työtilan tietyt määritykset tai joissa käytetään tietoja.
  2. Tämän jälkeen pull-pyyntö luodaan Testi-haaraan. Useimmissa tapauksissa PULL-pyyntö luodaan julkaisuhaaralla, joka voi kirsikkavalita sisällön seuraavaan vaiheeseen siirtymistä varten. PULL-pyyntöön tulisi sisältyä sama tarkistus- ja hyväksyntäprosessi kuin kaikkien muidenkin ryhmäsi tai organisaatiosi jäsenten.
  3. Testityötilan päivittäminen käynnistää toisen koontiversio- ja julkaisuputken käyttämällä ensimmäisessä vaiheessa kuvattua prosessia.
  4. Pull-pyyntö luodaan Prod-haaraan käyttämällä samankaltaista prosessia kuin vaiheessa 2 kuvattu prosessi.
  5. Toinen koontiversio ja julkaisuputki käynnistetään Prod-työtilan päivittämiseksi. Prosessi on samankaltainen kuin ensimmäisessä vaiheessa kuvattiin.

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 tiimisi noudattaa Gitflow'n haarautumisstrategiaa, mukaan lukien useita päähaaroja.
  • Säilöstä lataaminen lähetetään suoraan työtilaan, koska emme tarvitse koontiympäristöjä tiedostojen muuttamiseksi ennen käyttöönottoa. Voit muuttaa tätä kutsumalla ohjelmointirajapintoja tai suorittamalla kohteita työtilassa käyttöönoton jälkeen.

Vaihtoehto 2 – Git-pohjaiset käyttöönotot koontiympäristöjä käyttämällä

Kaavio, joka näyttää Git-pohjaisen käyttöönoton kulun koontiympäristöjä käyttämällä.

Tässä vaihtoehdossa kaikki käyttöönotot ovat peräisin Git-säilön samasta haarasta (Pää). Kullakin julkaisuputken vaiheella on oma koontiversio ja julkaisuputki . Nämä jaksot saattavat käyttää Muodosta-ympäristöä yksikkötestien ja komentosarjojen suorittamiseen, jotka muuttavat kohteiden joitain määritelmiä ennen niiden lataamista työtilaan. Saatat esimerkiksi haluta muuttaa tietolähdeyhteyttä, työtilan kohteiden välisiä yhteyksiä tai parametrien arvoja, jotta voit säätää määritystä oikeaa vaihetta varten.

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

  1. Koontiputki käynnistetään uuden koontiympäristön pyöristämiseksi ja yksikkötestien suorittamiseksi kehitysvaiheelle. Tämän jälkeen julkaisuputki käynnistyy sisällön lataamiseksi koontiympäristöön, komentosarjojen suorittamiseksi joidenkin määritysten muuttamiseksi, määritysten muuttamiseksi kehitysvaiheeksi ja Fabricin päivityskohdemääritelmä-ohjelmointirajapintojen avulla tiedostojen lataamiseksi työtilaan.
  2. Kun tämä prosessi on valmis, mukaan lukien tietojen käyttö ja hyväksyntä julkaisupäälliköiltä, voidaan luoda testivaiheen seuraavat koonti- ja julkaisuputket. Nämä vaiheet luodaan prosessissa, joka on samanlainen kuin ensimmäisessä vaiheessa kuvattiin. Testivaiheessa käyttöönoton jälkeen saatetaan vaatia muita automaattisia tai manuaalisia testejä sen vahvistamiseksi, että muutokset ovat valmiita julkaistavaksi Prod-vaiheeseen.
  3. Kun kaikki automaattiset ja manuaaliset testit on suoritettu, julkaisupäällikkö voi hyväksyä ja käynnistää koonti - ja julkaisuputket Prod-vaiheeseen . Koska Prod-vaiheessa on yleensä eri kokoonpanot kuin testi-/kehitysvaiheissa, on tärkeää testata muutokset myös käyttöönoton jälkeen. Käyttöönoton pitäisi myös käynnistää tietojen käsittely muutoksen perusteella, jotta mahdollinen ei-saatavuus voidaan minimoida kuluttajille.

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

  • Kun haluat käyttää Gitiä ainoana totuuden lähteenä ja kaikkien käyttöönottojen alkuperänä.
  • Kun tiimisi noudattaa haarautumisstrategianaan trunk-pohjaista työnkulkua.
  • Tarvitset koontiympäristön (mukautetulla komentosarjalla) työtilaan liittyvien määritteiden, kuten connectionId :n ja LakehouseId:n, muuttamiseen ennen käyttöönottoa.
  • Tarvitset julkaisuputken (mukautetun komentosarjan), jotta voit noutaa kohteen sisällön Gitistä ja kutsua vastaavaa Fabric Item -ohjelmointirajapintaa muokattujen Fabric-kohteiden luomiseen, päivittämiseen tai poistamiseen.

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

Kaavio, joka näyttää Git-perustaisen käyttöönoton työnkulun käyttöönottoputkia käyttämällä.

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. Vaikka itse työkalu on Fabricin sisäinen, kehittäjät voivat käyttöönottoputkien ohjelmointirajapintojen avulla järjestää käyttöönoton osana Azure-julkaisuputkea 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 pull-pyyntö päähaaraan on hyväksytty ja yhdistetty:

  1. Käynnistyy koontiputki, joka lataa muutokset kehitysvaiheeseen Fabric Git -ohjelmointirajapintojen avulla. Tarvittaessa putki voi käynnistää muita ohjelmointirajapintoja käyttöönoton jälkeisten toimintojen/testien aloittamiseksi kehitysvaiheessa .
  2. Kun kehityskäyttöönotto on valmis, julkaisuputki käynnistyy, jotta muutokset otetaan käyttöön kehitysvaiheesta testivaiheeseen. Käyttöönoton jälkeen tulee tehdä automatisoituja ja manuaalisia testejä, joilla varmistetaan, että muutokset testataan hyvin ennen tuotannon saavuttamista.
  3. Kun testit on suoritettu ja julkaisupäällikkö on hyväksynyt käyttöönoton Prod-vaiheeseen, julkaisu Prodiin käynnistyy ja viimeistelee käyttöönoton.

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

  • 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)

Kaavio, joka näyttää Git-pohjaisen isv-käyttöönoton työnkulun.

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. Kun pääasiallinen pull-pyyntö on hyväksytty ja yhdistetty:

  1. Koontiputki käynnistetään uuden koontiympäristön pyöristämiseksi ja yksikkötestien suorittamiseksi kehitysvaiheelle. Kun testit ovat valmiita, julkaisuputki käynnistyy. Tämä jakso voi ladata sisällön muodostamisympäristöön, suorittaa komentosarjoja joidenkin määritysten muuttamiseksi, muokata määritystä kehitysvaiheeksi ja käyttää sitten Fabricin Update item definition -ohjelmointirajapintoja tiedostojen lataamiseen työtilaan.
  2. Kun tämä prosessi on valmis, mukaan lukien tietojen käyttö ja hyväksyntä julkaisupäälliköiltä, testivaiheen seuraavat koonti- ja julkaisuputket voivat käynnistyä. Tämä prosessi on samankaltainen kuin ensimmäisessä vaiheessa kuvattu. Testivaiheessa käyttöönoton jälkeen saatetaan vaatia muita automaattisia tai manuaalisia testejä sen vahvistamiseksi, että muutokset ovat valmiita julkaistavaksi Prod-vaiheeseen laadukkaasti.
  3. Kun kaikki testit on hyväksytty ja hyväksyntäprosessi on valmis, käyttöönotto Prod-asiakkaille voidaan aloittaa. Kullakin asiakkaalla on oma julkaisuversio, jossa on omat parametrinsa, jotta niiden konfigurointi ja tietoyhteys voidaan suorittaa asianomaisen asiakkaan työtilassa. Määrityksen muutos voi tapahtua koontiympäristön komentosarjojen tai käyttöönoton jälkeisessä ohjelmointirajapinnoilla. Kaikki julkaisut voidaan tehdä rinnakkain, koska ne eivät liity toisiinsa eivätkä ole riippuvaisia toisistaan.

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ö