Megosztás a következőn keresztül:

Válassza ki a legjobb Fabric CI/CD munkafolyamatot

  • Cikk

A cikk célja, hogy bemutassuk a Fabric-fejlesztőknek a CI/CD-folyamatok Fabricben való készítésének különböző lehetőségeit, a gyakori ügyfélforgatókönyvek alapján. Ez a cikk a CI/CD folyamat folyamatos üzembe helyezésére (CD) összpontosít. A folyamatos integrációs (CI) részről a Git-ágak kezelése című témakörben olvashat.

Bár ez a cikk számos különböző lehetőséget ismertet, számos szervezet hibrid megközelítést alkalmaz.

Előfeltételek

Az üzembehelyezési folyamatok funkció eléréséhez meg kell felelnie a következő feltételeknek:

Fejlesztési folyamat

A fejlesztési folyamat minden üzembe helyezési forgatókönyvben ugyanaz, és független attól, hogyan lehet új frissítéseket éles környezetben kiadni. Amikor a fejlesztők a forrásvezérléssel dolgoznak, elszigetelt környezetben kell dolgozniuk. A Fabricben ez a környezet lehet IDE a helyi gépen (például a Power BI Desktopban vagy a VS Code-ban), vagy egy másik munkaterület a Fabricben. A Git-ágak kezelése című témakör a fejlesztési folyamat különböző szempontjairól tartalmaz információkat

A fejlesztési folyamat működését bemutató ábra.

Kiadási folyamat

A kiadási folyamat az új frissítések befejeződése után kezdődik, és a lekéréses kérelem (PR) egyesül a csapat megosztott ágával (például Main, Dev stb.). Ettől a ponttól kezdve különböző lehetőségek állnak rendelkezésre egy kiadási folyamat létrehozásához a Fabricben.

1. lehetőség – Git-alapú üzemelő példányok

A Git-alapú üzembe helyezés működését bemutató ábra.

Ezzel a beállítással az összes üzembe helyezés a Git-adattárból származik. A kiadási folyamat minden szakasza rendelkezik egy dedikált elsődleges ágkal (a diagramon ezek a fázisok a Dev, a Test és a Prod), amely a Fabric megfelelő munkaterületét táplálja.

Miután jóváhagyták és egyesítették a Dev-ágra vonatkozó lekéréses kérelmet:

  1. Egy kiadási folyamat aktiválódik a Dev-munkaterület tartalmának frissítéséhez. Ez a folyamat egy buildelési folyamatot is tartalmazhat az egységtesztek futtatásához, de a fájlok tényleges feltöltése közvetlenül az adattárból történik a munkaterületre a Fabric Git API-k használatával. Előfordulhat, hogy más Fabric API-kat kell meghívnia az üzembe helyezés utáni műveletekhez, amelyek adott konfigurációkat adnak meg ehhez a munkaterülethez, vagy adatokat kell betöltenie.
  2. Ezután létrejön egy lekéréses kérelem a Teszt ágban. A legtöbb esetben a lekéréses kérelem egy kiadási ág használatával jön létre, amely kiválaszthatja a tartalmat a következő fázisba lépéshez. A kérelemnek ugyanazokat a felülvizsgálati és jóváhagyási folyamatokat kell tartalmaznia, mint a csapat vagy a szervezet bármely más tagja.
  3. Egy másik buildelési és kiadási folyamat aktiválódik a Teszt munkaterület frissítéséhez az első lépésben ismertetett folyamathoz hasonló folyamat használatával.
  4. A prod ágban a 2. lépésben leírthoz hasonló folyamattal jön létre egy lekéréses kérelem.
  5. Egy másik buildelési és kiadási folyamat aktiválódik a Prod-munkaterület frissítéséhez az első lépésben ismertetett folyamathoz hasonló folyamat használatával.

Mikor érdemes az 1. lehetőséget használni?

  • Ha a Git-adattárat szeretné használni az igazság egyetlen forrásaként, és az összes üzembe helyezés eredetét.
  • Ha a csapat a Gitflow-t követi elágaztatási stratégiaként, beleértve több elsődleges ágat is.
  • Az adattárból történő feltöltés közvetlenül a munkaterületre kerül, mivel nincs szükség buildkörnyezetekre a fájlok üzembe helyezése előtti módosításához. Ezt úgy módosíthatja, hogy meghívja az API-kat, vagy futtatja a munkaterület elemeit az üzembe helyezés után.

2. lehetőség – Git-alapú üzembe helyezés buildkörnyezetek használatával

Diagram a Git-alapú üzembe helyezés folyamatáról buildkörnyezetek használatával.

Ezzel a beállítással az összes üzembe helyezés a Git-adattár (Main) ugyanazon ágából származik. A kiadási folyamat minden szakasza dedikált buildelési és kiadási folyamatokkal rendelkezik. Ezek a folyamatok buildkörnyezetet használhatnak olyan egységtesztek és szkriptek futtatásához, amelyek módosítják az elemek definícióit, mielőtt feltöltené őket a munkaterületre. Előfordulhat például, hogy módosítani szeretné az adatforrás-kapcsolatot, a munkaterület elemei közötti kapcsolatokat, vagy a paraméterek értékeit a megfelelő szakasz konfigurációjának módosításához.

A fejlesztői ághoz való lekérés jóváhagyása és egyesítése után:

  1. Egy buildelési folyamat aktiválódik egy új buildkörnyezet üzembe helyezéséhez és a fejlesztői fázis egységtesztjeinek futtatásához. Ezután egy kiadási folyamat aktiválódik, amely feltölti a tartalmat egy buildkörnyezetbe, szkripteket futtat a konfiguráció egy részének módosításához, a konfiguráció fejlesztési fázisra állításához, és a Fabric Update elemdefiníció API-jaival feltölti a fájlokat a munkaterületre.
  2. Ha ez a folyamat befejeződött, beleértve az adatok betöltését és a kiadáskezelők jóváhagyását, létre lehet hozni a következő buildelési és kiadási folyamatokat a tesztelési fázishoz. Ezek a szakaszok az első lépésben leírthoz hasonló folyamat során jönnek létre. A tesztelési fázishoz az üzembe helyezés után más automatizált vagy manuális tesztekre is szükség lehet, amelyek ellenőrzik, hogy a módosítások készen állnak-e a Prod-fázisban való kiadásra.
  3. Ha minden automatizált és manuális teszt befejeződött, a kiadáskezelő jóváhagyhatja és elindíthatja a buildelési és kiadási folyamatokat a Prod fázisban. Mivel a Prod-fázis általában más konfigurációkkal rendelkezik, mint a tesztelési/fejlesztői fázisok, fontos, hogy az üzembe helyezés után is tesztelje a módosításokat. Emellett az üzembe helyezésnek a változás alapján minden további adatbetöltést meg kell indítania, hogy a lehető legkisebb legyen a fogyasztók számára való nem rendelkezésre állás.

Mikor érdemes a 2. lehetőséget használni?

  • Ha a Gitet szeretné használni az igazság egyetlen forrásaként, és az összes üzembe helyezés eredetét.
  • Amikor a csapat a Trunk-alapú munkafolyamatot követi elágaztatási stratégiájaként.
  • Az üzembe helyezés előtt szükség van egy buildkörnyezetre (egyéni szkripttel) a munkaterület-specifikus attribútumok, például a connectionId és a lakehouseId módosításához.
  • Egy kiadási folyamatra (egyéni szkriptre) van szüksége, amely lekéri az elem tartalmát a Gitből, és meghívja a megfelelő Fabric Item API-t a módosított hálóelemek létrehozásához, frissítéséhez vagy törléséhez.

3. lehetőség – Üzembe helyezés Fabric üzembehelyezési folyamatokkal

A Git-alapú üzembe helyezés folyamatát bemutató ábra üzembehelyezési folyamatokkal.

Ezzel a beállítással a Git csak a fejlesztői fázisig csatlakozik. A fejlesztői fázistól kezdve az üzembe helyezések közvetlenül a Dev/Test/Prod munkaterületei között történnek Fabric üzembehelyezési folyamatokkal. Bár maga az eszköz a Fabric belső eszköze, a fejlesztők az üzembe helyezési folyamatok API-jaival vezényelhetik az üzembe helyezést az Azure-beli kiadási folyamat részeként vagy egy GitHub-munkafolyamat részeként. Ezek az API-k lehetővé teszik a csapat számára, hogy hasonló buildelési és kiadási folyamatot építsenek ki, mint más lehetőségek esetén, automatizált tesztek használatával (amelyek elvégezhetők a munkaterületen, vagy a fejlesztői fázis előtt), jóváhagyásokkal stb.

A főághoz való lekérés jóváhagyása és egyesítése után:

  1. Egy buildelési folyamat aktiválódik, amely a Fabric Git API-k használatával tölti fel a módosításokat a fejlesztői fázisba. Szükség esetén a folyamat más API-kat is aktiválhat az üzembe helyezés utáni műveletek/tesztek fejlesztői fázisban való elindításához.
  2. A fejlesztői üzembe helyezés befejezése után egy kiadási folyamat indul el, amely üzembe helyezi a módosításokat a fejlesztői fázistól a tesztelési fázisig. Az üzembe helyezés után automatizált és manuális teszteket kell végezni, hogy a módosítások megfelelően tesztelve legyenek az éles környezet elérése előtt.
  3. Miután a tesztek befejeződtek, és a kiadáskezelő jóváhagyja az üzembe helyezést a Prod fázisban, a Prod-ra való kiadás elindul és befejezi az üzembe helyezést.

Mikor érdemes a 3. lehetőséget használni?

  • Ha csak fejlesztési célokra használja a forrásvezérlést, és inkább közvetlenül a kiadási folyamat szakaszai között szeretné üzembe helyezni a módosításokat.
  • Üzembehelyezési szabályok esetén az automatikus kötés és az egyéb elérhető API-k elegendőek a kiadási folyamat szakaszai közötti konfigurációk kezeléséhez.
  • Ha a Fabric üzembe helyezési folyamatainak egyéb funkcióit szeretné használni, például a Fabric módosításainak megtekintését, az üzembe helyezési előzményeket stb.
  • Vegye figyelembe azt is, hogy a Fabric-alapú üzembehelyezési folyamatok üzembe helyezései lineáris struktúrával rendelkeznek, és más engedélyeket igényelnek a folyamat létrehozásához és kezeléséhez.

4. lehetőség – CI/CD az ISV-k számára a Fabricben (több ügyfél/megoldás kezelése)

Az ISV-k Git-alapú üzembe helyezésének folyamatát bemutató ábra.

Ez a beállítás eltér a többitől. Ez a leginkább releváns független szoftverszállítók (ISV) számára, akik SaaS-alkalmazásokat építenek ügyfeleik számára a Fabric tetejére. Az ISV-k általában minden ügyfél számára külön munkaterületet használnak, és akár több száz vagy több ezer munkaterületet is tartalmazhatnak. Ha az egyes ügyfeleknek nyújtott elemzések felépítése hasonló és nem beépített, javasoljuk, hogy legyen egy központosított fejlesztési és tesztelési folyamat, amely csak a Prod fázisban oszlik el az egyes ügyfelekre.

Ez a beállítás a 2. lehetőségen alapul. A fő lekéréses kérelem jóváhagyása és egyesítése után:

  1. A buildelési folyamat egy új buildkörnyezet üzembe helyezéséhez és a fejlesztői fázis egységtesztjeinek futtatásához aktiválódik. Amikor a tesztek befejeződnek, a rendszer elindít egy kiadási folyamatot. Ez a folyamat feltöltheti a tartalmat egy Build-környezetbe, szkripteket futtathat a konfiguráció módosításához, a konfigurációt fejlesztési fázisra módosíthatja, majd a Fabric Update elemdefiníciós API-jaival feltöltheti a fájlokat a munkaterületre.
  2. A folyamat befejezése után, beleértve az adatok betöltését és a kiadáskezelők jóváhagyását, elindulhatnak a következő buildelési és kiadási folyamatok a tesztelési fázishoz. Ez a folyamat az első lépésben leírthoz hasonló. A tesztelési szakaszban az üzembe helyezés után más automatizált vagy manuális tesztekre is szükség lehet, hogy a módosítások készen állnak a Prod-fázisban való magas minőségű kiadásra.
  3. Ha az összes teszt sikeres, és a jóváhagyási folyamat befejeződött, a Prod-ügyfelek számára történő üzembe helyezés elkezdhető. Minden ügyfél saját kiadással rendelkezik, saját paraméterekkel, hogy az adott konfigurációja és adatkapcsolata az adott ügyfél munkaterületén valósuljon meg. A konfiguráció módosítása egy buildkörnyezet szkriptjeivel vagy az üzembe helyezés utáni API-k használatával történhet. Minden kiadás párhuzamosan történhet, mivel nem kapcsolódnak egymáshoz, és nem függnek egymástól.

Mikor érdemes a 4. lehetőséget használni?

  • Ön isV-építő alkalmazás a Fabric tetején.
  • Különböző munkaterületeket használ az egyes ügyfelek számára az alkalmazás több-bérlősságának kezeléséhez
  • A nagyobb elkülönítés vagy a különböző ügyfelekre vonatkozó konkrét tesztek esetén érdemes lehet több bérlőt használni a fejlesztés vagy a tesztelés korábbi szakaszaiban. Ebben az esetben vegye figyelembe, hogy a több-bérlős munkaterületek száma jelentősen nő.

Összegzés

Ez a cikk összefoglalja azoknak a csapatoknak a ci/CD fő beállításait, akik automatizált CI/CD-folyamatot szeretnének létrehozni a Fabricben. Bár négy lehetőséget ismertetünk, a valós korlátozások és a megoldásarchitektúra hibrid vagy teljesen eltérő lehetőségeket kínálhat. Ez a cikk végigvezeti a különböző beállításokon és azok létrehozásának módján, de nem kell csak egyet választania a lehetőségek közül.

Előfordulhat, hogy egyes forgatókönyvek vagy adott elemek olyan korlátozásokkal rendelkeznek, amelyek miatt nem használhatja ezeket a forgatókönyveket.

Ugyanez vonatkozik az eszközhasználatra is. Bár itt különböző eszközöket említünk, más olyan eszközöket is választhat, amelyek azonos szintű funkcionalitást biztosítanak. Vegye figyelembe, hogy a Fabric jobban integrálást végez bizonyos eszközökkel, ezért a mások kiválasztása több korlátozást eredményez, amelyek különböző kerülő megoldásokat igényelnek.

Kapcsolódó tartalom