Ανάπτυξη και ανάπτυξη εξαρτήσεων μεταξύ αποθηκών

Σε αυτό το άρθρο, θα μάθετε πώς μπορείτε να μοντελοποιήσετε και να αναπτύξετε εξαρτήσεις μεταξύ αποθηκών χρησιμοποιώντας έργα βάσης δεδομένων SQL στον κώδικα του Visual Studio. Ξεκινάτε από δύο υπάρχοντα έργα αποθήκης και διαμορφώνετε μονόδρομες εξαρτήσεις μεταξύ τους χρησιμοποιώντας αναφορές βάσης δεδομένων και, όπου είναι απαραίτητο, δέσμες ενεργειών πριν και μετά την ανάπτυξη.

Αυτό το άρθρο βασίζεται στις έννοιες της ενότητας Ανάπτυξη έργων αποθήκης στο Visual Studio Code και υποθέτει ότι είστε ήδη εξοικειωμένοι με τη δημιουργία και τη δημοσίευση ενός έργου αποθήκης.

Prerequisites

Πριν ξεκινήσετε, βεβαιωθείτε ότι:

• Δημιουργήστε δύο αποθήκες Fabric στον ίδιο χώρο εργασίας.
  • Για να δημιουργήσετε ένα νέο δείγμα αποθήκης, ανατρέξτε στο θέμα Δημιουργία δείγματος αποθήκης στο Microsoft Fabric.
• Δημιουργήστε ή εξαγάγετε ένα έργο βάσης δεδομένων για κάθε αποθήκη στον κώδικα του Visual Studio.
  • Για να δημιουργήσετε ένα έργο βάσης δεδομένων για την υπάρχουσα αποθήκη σας ή μια νέα αποθήκη, ανατρέξτε στο θέμα Ανάπτυξη έργων αποθήκης στον κώδικα του Visual Studio.
• Εγκαταστήστε το Visual Studio Code στο σταθμό εργασίας σας.
• Εγκαταστήστε το .NET SDK για να δημιουργήσετε και να δημοσιεύσετε έργα βάσης δεδομένων.
• Εγκαταστήστε δύο επεκτάσεις κώδικα του Visual Studio: SQL Database Projects και SQL Server (mssql).
  • Μπορείτε να εγκαταστήσετε τις απαιτούμενες επεκτάσεις απευθείας από την αγορά κώδικα του Visual Studio αναζητώντας "SQL Database Projects" ή "SQL Server (mssql)".
• Τα έργα αποθήκης επικυρώνουν, δημιουργούν και μπορούν να δημοσιευτούν στον κώδικα του Visual Studio.

Σημείωμα

Αυτό το άρθρο εστιάζει στα έργα αποθήκης στον κώδικα του Visual Studio και στον τρόπο με τον οποίο τα εκδίδετε στο Git ως κανονικά έργα κώδικα. Η ενοποίηση Fabric Git για χώρους εργασίας και είδη αποθήκης καλύπτεται ξεχωριστά στο στοιχείο ελέγχου προέλευσης με έγγραφα ενοποίησης Fabric Data Warehouse και Git. Το άρθρο υποθέτει ότι ο χώρος εργασίας Fabric είναι ο προορισμός ανάπτυξης και το σχήμα T-SQL βρίσκεται σε ένα ή περισσότερα έργα κώδικα του Visual Studio που ελέγχετε την έκδοση στο Git.

Αυτό το άρθρο δεν καλύπτει την ανάπτυξη μεταξύ αποθηκών για το τελικό σημείο ανάλυσης SQL ενός Lakehouse. Οι πίνακες Lakehouse και τα αντικείμενα τελικού σημείου SQL δεν παρακολουθούνται αντικείμενα στο στοιχείο ελέγχου προέλευσης με τον ίδιο τρόπο που παρακολουθούνται τα έργα αποθήκης. Χρησιμοποιήστε στοιχεία αποθήκης με έργα βάσης δεδομένων για πλήρη ενοποίηση git και υποστήριξη ανάπτυξης σε εγγενείς εμπειρίες Fabric και εργαλεία προγράμματος-πελάτη.

Σενάριο: Αποθήκες μεταξύ τομέων Zava Analytics

Το Zava Analytics χρησιμοποιεί δύο επιχειρηματικούς τομείς:

• Πωλήσεις – παραγγελίες πελατών, έσοδα και μετρήσεις αγωγών.
• Μάρκετινγκ – καμπάνιες, κανάλια και μετρήσεις αφοσίωσης.

Κάθε τομέας έχει:

• Μια αποθήκη υφασμάτων στον ίδιο χώρο εργασίας:

  • ZavaSalesWarehouse
  • ZavaMarketingWarehouse

• Ένα έργο βάσης δεδομένων στον κώδικα του Visual Studio:

  • Zava.Sales.Warehouse
  • Zava.Marketing.Warehouse

Για τη δημιουργία ELT και αναφορών από άκρο σε άκρο, κάθε τομέας χρειάζεται προβολές μόνο για ανάγνωση για πρόσβαση σε δεδομένα από τον άλλο τομέα:

• Sales χρειάζεται δέσμευση μάρκετινγκ από τον πελάτη.
• Marketing χρειάζεται απόδοση πωλήσεων ανά καμπάνια.

Πρέπει να κάνετε τα εξής:

• Δημιουργήστε μονόδρομες εξαρτήσεις μεταξύ αποθηκών μέσω αναφορών βάσης δεδομένων.
• Αποφύγετε τις κυκλικές εξαρτήσεις.
• Χρησιμοποιήστε δέσμες ενεργειών πριν και μετά την ανάπτυξη για περιπτώσεις όπου τα αντικείμενα και στις δύο αποθήκες εξαρτώνται το ένα από το άλλο.

Βεβαιωθείτε ότι οι εξαρτήσεις μεταξύ των αποθηκών είναι μονόδρομες

Για κάθε ζεύγος αποθηκών, επιλέξτε μία κατεύθυνση για λογική εξάρτηση:

Παράδειγμα:

• Sales Marketing εξαρτάται από τα δεδομένα αφοσίωσης.
• Marketing Δεν εξαρτάται από Sales αντικείμενα που χρειάζονται κατά το χρόνο ανάπτυξης.

Στην πράξη:

Zava.Sales.Warehouse έχει μια αναφορά βάσης δεδομένων στο Zava.Marketing.Warehouse.

• Η T-SQL στην Sales αποθήκη μπορεί να χρησιμοποιήσει ονόματα τριών μερών όπως:

  SELECT * FROM ZavaMarketingWarehouse.Marketing.CampaignEngagement
  

• Zava.Marketing.Warehouse δεν αναφέρεταιSales σε αντικείμενα που θα ανάγκαζαν έναν κύκλο εξάρτησης κατά το χρόνο ανάπτυξης.

Φιλοδώρημα

Για κάθε ζεύγος αποθηκών, σχεδιάστε ένα απλό διάγραμμα βέλους (Sales → Marketing). Εάν βρείτε βέλη που δείχνουν και προς τις δύο κατευθύνσεις για τον ίδιο τύπο αντικειμένου, πιθανότατα πρέπει να αναδιαμορφώσετε ή να μετακινήσετε κάποια λογική σε σενάρια πριν και μετά την ανάπτυξη.

Αποφύγετε τις κυκλικές εξαρτήσεις

Μια κυκλική εξάρτηση συμβαίνει όταν η Αποθήκη Α και η Αποθήκη Β εξαρτώνται η μία από την άλλη με τρόπο που η μηχανή δεν μπορεί να επιλύσει σε μία μόνο ανάπτυξη.

Παράδειγμα προβλήματος (μην το κάνετε αυτό):

• ZavaSalesWarehouse.dbo.CustomerRollup άποψη:

  CREATE VIEW dbo.CustomerRollup AS
  SELECT  c.CustomerId,
          c.TotalRevenue,
          m.LastCampaignId
  FROM    dbo.CustomerRevenue AS c
  LEFT OUTER JOIN   
          ZavaMarketingWarehouse.dbo.CustomerEngagement AS m
          ON c.CustomerId = m.CustomerId;
  

• ZavaMarketingWarehouse.dbo.CampaignAttribution άποψη:

  CREATE VIEW dbo.CampaignAttribution AS
  SELECT  m.CampaignId,
          SUM(s.TotalRevenue) AS RevenueAttributed
  FROM    dbo.Campaigns AS m
  LEFT OUTER JOIN    
          ZavaSalesWarehouse.dbo.CustomerRollup AS s
          ON m.CampaignId = s.LastCampaignId
  GROUP BY m.CampaignId;
  

Σε αυτό το αντι-μοτίβο:

• CustomerRollup στις πωλήσεις εξαρτάται από CustomerEngagement το μάρκετινγκ.
• CampaignAttribution στο μάρκετινγκ εξαρτάται από CustomerRollup τις πωλήσεις.

Αυτό το αντι-μοτίβο δημιουργεί έναν κύκλο: Προβολή Πωλήσεις → Προβολή μάρκετινγκ → Προβολή Πωλήσεις ξανά.

Καθοδήγηση:

Μην μοντελοποιείτε αμοιβαίες εξαρτήσεις μεταξύ αποθηκών ως κανονικά αντικείμενα σε επίπεδο σχήματος. Εάν χρειάζεστε πραγματικά αυτό το είδος λογικής, μετακινήστε τη μία πλευρά της εξάρτησης σε:

• Ένα σενάριο μετά την ανάπτυξη, ή
• Ένα κατάντη σημασιολογικό μοντέλο ή αναφορά που ενώνει τις δύο αποθήκες κατά τον χρόνο ερωτήματος.

Χρησιμοποιήστε δέσμες ενεργειών πριν και μετά την ανάπτυξη για λογική μεταξύ αποθηκών ευαίσθητων στην ανάπτυξη

Επειδή οι αναπτύξεις αποθήκης είναι πλήρεις λειτουργίες διαφοράς σχήματος (όχι μερικές αναπτύξεις ανά αντικείμενο), αντιμετωπίστε προσεκτικά τα στοιχεία μεταξύ αποθηκών:

Εάν η Αποθήκη Α και η Αποθήκη Β χρειάζονται και οι δύο αντικείμενα που εξαρτώνται το ένα από το άλλο:

• Διατηρήστε τους βασικούς πίνακες και τις βασικές προβολές σε κάθε έργο αποθήκης.
• Μετακινήστε τις προβολές γέφυρας ή τα βοηθητικά αντικείμενα που δημιουργούν κύκλους σε δέσμες ενεργειών πριν ή μετά την ανάπτυξη σε ένα έργο.
• Βεβαιωθείτε ότι αυτά τα σενάρια είναι ανίσχυρα και ασφαλή για επανεκτέλεση.

Παραδείγματα μοτίβων:

• Δέσμη ενεργειών πριν από την ανάπτυξη: αποθέστε προσωρινά μια προβολή μεταξύ αποθηκών πριν εφαρμόσετε αλλαγές σχήματος που θα την έσπασαν.
• Δέσμη ενεργειών μετά την ανάπτυξη: δημιουργήστε ξανά ή ενημερώστε την προβολή μεταξύ αποθηκών μετά την ανάπτυξη και των δύο αποθηκών.

Μοτίβο 1: Άμεσες αναφορές μεταξύ αποθηκών μέσω αναφορών βάσης δεδομένων

Σε αυτό το μοτίβο, μοντελοποιείτε μονόδρομες εξαρτήσεις απευθείας στα έργα βάσης δεδομένων χρησιμοποιώντας αναφορές βάσεων δεδομένων.

Βήμα 1: Ξεκινήστε από δύο υπάρχοντα έργα αποθήκης

Θα πρέπει να έχετε ήδη:

• Zava.Sales.Warehouse → αναπτύχθηκε για να ZavaSalesWarehouse
• Zava.Marketing.Warehouse → αναπτύχθηκε για να ZavaMarketingWarehouse

Κάθε έργο δημιουργήθηκε ή εξήχθη χρησιμοποιώντας τα βήματα στην ενότητα Ανάπτυξη έργων αποθήκης στον κώδικα του Visual Studio.

Βήμα 2: Προσθήκη αναφοράς βάσης δεδομένων από τις Πωλήσεις στο Μάρκετινγκ

• Στον κώδικα του Visual Studio, ανοίξτε την προβολή Έργα βάσης δεδομένων .
• Κάντε δεξί κλικ στο Zava.Sales.Warehouse έργο.
• Επιλέξτε Προσθήκη αναφοράς βάσης δεδομένων....
• Επιλέξτε ένα από τα εξής:
  • Έργο βάσης δεδομένων στον τρέχοντα χώρο εργασίας (Ένα έργο βάσης δεδομένων που αναφέρεται με αυτόν τον τρόπο πρέπει επίσης να είναι ανοιχτό στον κώδικα του Visual Studio) ή
  • Εφαρμογή επιπέδου δεδομένων (.dacpac) (Υποθέτει ότι έχετε δημιουργήσει εάν έχετε κατασκευάσει μια για .dacpac την Marketing αποθήκη).
• Ορίστε τις επιλογές αναφοράς:
  • Τύπος αναφοράς: Ίδιος διακομιστής, διαφορετική βάση δεδομένων.
  • Όνομα ή μεταβλητή βάσης δεδομένων: Χρησιμοποιήστε μια μεταβλητή SQLCMD, για παράδειγμα [$(MarketingWarehouseName)].
• Αποθηκεύστε και δημιουργήστε ξανά το έργο Sales.

Στο .sqlproj αρχείο, θα πρέπει να δείτε μια καταχώρηση παρόμοια με:

<ItemGroup>
  <ArtifactReference Include="..\Zava.Marketing.Warehouse\bin\Debug\Zava.Marketing.Warehouse.dacpac">
    <DatabaseVariableLiteralValue>$(MarketingWarehouseName)</DatabaseVariableLiteralValue>
  </ArtifactReference>
</ItemGroup>
<ItemGroup>
  <SqlCmdVariable Include="MarketingWarehouseName">
    <DefaultValue>ZavaMarketingWarehouse</DefaultValue>
  </SqlCmdVariable>
</ItemGroup>

Φιλοδώρημα

Η χρήση μιας μεταβλητής SQLCMD για το όνομα της απομακρυσμένης αποθήκης σάς επιτρέπει να επαναχρησιμοποιήσετε το ίδιο έργο σε όλα τα περιβάλλοντά σας, όπως το Dev/Test/Prod, όπου τα ονόματα των αποθηκών ενδέχεται να διαφέρουν.

Βήμα 3: Δημιουργία προβολής μεταξύ αποθηκών στο Sales

Στο Sales έργο, προσθέστε μια προβολή που διαβάζει από την Marketing αποθήκη:

-- schema/Views/dbo.CustomerEngagementFact.sql
CREATE VIEW [dbo].[CustomerEngagementFact] AS
SELECT
    s.CustomerId,
    s.TotalRevenue,
    m.LatestChannel,
    m.LastEngagementDate
FROM dbo.CustomerRevenue AS s
JOIN [$(MarketingWarehouseName)].[dbo].[CustomerEngagement] AS m
    ON s.CustomerId = m.CustomerId;

Κύρια σημεία:

• Το όνομα [$(MarketingWarehouseName)].[dbo].[CustomerEngagement] τριών τμημάτων ταιριάζει με το μοτίβο T-SQL που χρησιμοποιείται για ερωτήματα μεταξύ αποθηκών στο πρόγραμμα επεξεργασίας SQL Fabric.
• Το DacFx επιλύει την εξωτερική βάση δεδομένων μέσω της αναφοράς βάσης δεδομένων.

Δημιουργήστε το έργο για να βεβαιωθείτε ότι δεν υπάρχουν SQL71501 ανεπίλυτα σφάλματα αναφοράς .

Βήμα 4: Δημοσιεύστε την αποθήκη μάρκετινγκ και, στη συνέχεια, τις Πωλήσεις

Για να αποφύγετε προβλήματα ανάπτυξης:

• Δημιουργία και δημοσίευσηZava.Marketing.Warehouse πρώτος:
  • Κάντε δεξί κλικ στο έργο → Δημιουργία.
  • Κάντε δεξί κλικ στο έργο → Δημοσίευση → επιλέξτε ZavaMarketingWarehouse.
• Μόλις Marketing ολοκληρωθεί με επιτυχία η ανάπτυξη, δημιουργήστε και δημοσιεύστεZava.Sales.Warehouse:
  • Κάντε δεξί κλικ στο έργο → Δημιουργία.
  • Κάντε δεξί κλικ στο έργο → Δημοσίευση → επιλέξτε ZavaSalesWarehouse.

Η ροή ανάπτυξης που προκύπτει είναι:

Zava.Marketing.Warehouse (χωρίς εξωτερικές εξαρτήσεις) → Zava.Sales.Warehouse (εξαρτάται από Marketing)

Τώρα, οποιοδήποτε ερώτημα T-SQL στο ZavaSalesWarehouse μπορεί να χρησιμοποιήσει την προβολή, η dbo.CustomerEngagementFact οποία διαβάζεται εσωτερικά από την Marketing αποθήκη χρησιμοποιώντας T-SQL μεταξύ αποθηκών.

Μοτίβο 2: Διαχείριση εξαρτήσεων μεταξύ αποθηκών μέσω σεναρίων πριν και μετά την ανάπτυξη

Σε ορισμένα σενάρια Zava Analytics, και οι δύο τομείς ενδέχεται να χρειάζονται συγκεντρωτικά αντικείμενα που εξαρτώνται το ένα από το άλλο. Για παράδειγμα:

• Οι πωλήσεις θέλουν μια αναλυτική προβολή που χρησιμοποιεί δεδομένα εκστρατείας μάρκετινγκ για την παροχή εσόδων από πωλήσεις ανά εκστρατεία μάρκετινγκ.
• Το μάρκετινγκ θέλει μια προβολή που χρησιμοποιεί δεδομένα εσόδων από πωλήσεις για να παρέχει αποτελεσματικότητα καμπάνιας μάρκετινγκ.

Δεν θέλετε και τα δύο αυτά αντικείμενα να είναι κανονικές προβολές που συμμετέχουν στην πλήρη ανάπτυξη του μοντέλου, επειδή αυτό ενέχει τον κίνδυνο κυκλικής εξάρτησης ή εύθραυστης εντολής ανάπτυξης.

Αντίθετα, εσείς:

• Διατηρήστε το βασικό μοντέλο κάθε αποθήκης ανεξάρτητο.
• Χρησιμοποιήστε δέσμες ενεργειών μετά την ανάπτυξη σε ένα έργο για να δημιουργήσετε περισσότερες προβολές μεταξύ αποθηκών μετά την εφαρμογή και των δύο σχημάτων.

Βήμα 1: Προσθήκη αναφορών βάσης δεδομένων για επικύρωση κατά το χρόνο μεταγλώττισης

Ρυθμίστε αναφορές παρόμοιες με το Μοτίβο 1, αλλά και για τα δύο έργα:

• Στο Zava.Sales.Warehouse, προσθέστε μια αναφορά στο Marketing μέσω [$(MarketingWarehouseName)].
• Στο Zava.Marketing.Warehouse, προσθέστε προαιρετικά μια αναφορά στις Πωλήσεις μέσω [$(SalesWarehouseName)] , εάν θέλετε επικύρωση κατά το χρόνο μεταγλώττισης των προβολών μεταξύ αποθηκών που χρησιμοποιούνται σε δέσμες ενεργειών.

Στα .sqlproj αρχεία, μπορείτε να ορίσετε:

<SqlCmdVariable Include="SalesWarehouseName">
  <DefaultValue>ZavaSalesWarehouse</DefaultValue>
</SqlCmdVariable>

Βήμα 2: Δημιουργήστε βασικά αντικείμενα ως κανονικά αντικείμενα έργου

Παράδειγμα:

• Sales έργο:

  • dbo.CustomerRevenue τραπέζι
  • dbo.SalesByCampaign προβολή (χρησιμοποιώντας μόνο τοπικούς πίνακες)

• Marketing έργο:

  • dbo.Campaigns τραπέζι
  • dbo.CampaignStats προβολή (χρησιμοποιώντας μόνο τοπικούς πίνακες)

Αυτά τα αντικείμενα δεν χρησιμοποιούν ερωτήματα μεταξύ αποθηκών. Στο επόμενο βήμα, θα εισαγάγουμε αναφορές μεταξύ αποθηκών.

Βήμα 3: Προσθήκη δέσμης ενεργειών μετά την ανάπτυξη για προβολές γέφυρας μεταξύ αποθηκών

Επιλέξτε μία αποθήκη για να φιλοξενήσει αντικείμενα γέφυρας. Συνήθως ο τομέας που καταναλώνει περισσότερο τη συνδυασμένη έξοδο. Ας υποθέσουμε Sales ότι είναι αυτός ο τομέας.

• Στο έργο: Κάντε δεξί κλικ στο έργο και, στη συνέχεια, Προσθήκη → δέσμη ενεργειών μετά τηνSales ανάπτυξη.
• Ονομάστε το σενάριο PostDeployment_CrossWarehouse.sql.
• Στο σενάριο, δημιουργήστε ή τροποποιήστε τις προβολές μεταξύ αποθηκών χρησιμοποιώντας IF EXISTS / / DROPCREATE μοτίβα για να τις διατηρήσετε ανίσχυρες.

Παράδειγμα δέσμης ενεργειών που θα αναφέρεται Marketing σε Sales αντικείμενα αποθήκης:

-- PostDeployment_CrossWarehouse.sql

-- Ensure object can be recreated safely
IF OBJECT_ID('dbo.CampaignRevenueBridge', 'V') IS NOT NULL
    DROP VIEW [dbo].[CampaignRevenueBridge];
GO

CREATE VIEW [dbo].[CampaignRevenueBridge] AS
SELECT
    c.CampaignId,
    c.CampaignName,
    m.Channel,
    SUM(s.TotalRevenue) AS Revenue
FROM [$(MarketingWarehouseName)].[dbo].[Campaigns] AS c
JOIN [$(MarketingWarehouseName)].[dbo].[CampaignEngagement] AS m
    ON c.CampaignId = m.CampaignId
JOIN dbo.SalesByCampaign AS s
    ON s.CampaignId = c.CampaignId
GROUP BY
    c.CampaignId,
    c.CampaignName,
    m.Channel;
GO

Εδώ:

• Τα έργα πυρήνα Sales και Marketing αποθήκης παραμένουν ανεξάρτητα και μπορούν να αναπτυχθούν από μόνα τους.
• Η προβολή γέφυρας δημιουργείται μετά την ανάπτυξη του σχήματος μέσω δέσμης ενεργειών μετά την ανάπτυξη.
• Εάν η ανάπτυξη εκτελείται πολλές φορές, είναι ανίκανη, καθώς η δέσμη ενεργειών απορρίπτεται με ασφάλεια και αναδημιουργεί την προβολή.

Βήμα 4: (Προαιρετικό) Χρησιμοποιήστε δέσμες ενεργειών πριν από την ανάπτυξη για την προστασία εύθραυστων εξαρτήσεων

Σε πιο σύνθετα σενάρια, μπορείτε να κάνετε τα εξής:

• Χρησιμοποιήστε μια δέσμη ενεργειών πριν από την ανάπτυξη για να αποθέσετε ή να απενεργοποιήσετε τις προβολές μεταξύ αποθηκών που θα μπορούσαν να αποκλείσουν τις αλλαγές σχήματος (για παράδειγμα, εάν μετονομάζετε στήλες).
• Αφήστε το DacFx να εφαρμόσει τη διαφορά σχήματος.
• Χρησιμοποιήστε τη δέσμη ενεργειών μετά την ανάπτυξη για να δημιουργήσετε εκ νέου ή να ενημερώσετε τις προβολές μεταξύ αποθηκών.

Σημαντικό

Οι δέσμες ενεργειών πριν και μετά την ανάπτυξη εκτελούνται ως μέρος του σχεδίου ανάπτυξης και πρέπει:

• Idempotent, που σημαίνει ότι είναι ασφαλές να τρέξουν πολλές φορές.
• Συμβατό με το τελικό σχήμα που παράγεται από το DacFx.
• Χωρίς καταστροφικές αλλαγές που έρχονται σε αντίθεση με την πολιτική σας BlockOnPossibleDataLoss .

Βήμα 5: Παραγγελία δημοσίευσης για εξαρτήσεις διαχειριζόμενες από δέσμες ενεργειών

Ένα κοινό μοτίβο για το Zava Analytics:

• Δημοσίευση βασικών έργων:
  • Zava.Marketing.Warehouse (σχήμα πυρήνα)
  • Zava.Sales.Warehouse (βασικό σχήμα + σενάριο μετά την ανάπτυξη μεταξύ αποθηκών)
• Αφήστε τη δέσμη ενεργειών μετά την ανάπτυξη πωλήσεων να δημιουργήσει τις προβολές γέφυρας μετά την ανάπτυξη του δικού της σχήματος και του σχήματος αναφοράς.Marketing

Εάν εισάγετε περισσότερες από δύο αποθήκες, επαναλάβετε αυτό το μοτίβο σε επίπεδα. Ποτέ μην δημιουργείτε κυκλικές εξαρτήσεις μέσω συνηθισμένων αντικειμένων έργου.

Συνέχιση εκμάθησης

• Συνδυάστε αυτά τα μοτίβα με το στοιχείο ελέγχου προέλευσης και την καθοδήγηση CI/CD στο στοιχείο ελέγχου προέλευσης με έγγραφα ενοποίησης Fabric Data Warehouse και Fabric git.
• Επεκτείνετε το σενάριο Zava Analytics για να συμπεριλάβετε περιβάλλοντα Dev/Test/Prod , χρησιμοποιώντας αγωγούς ανάπτυξης ή εξωτερικό CI/CD για να ενορχηστρώσετε την εντολή δημοσίευσης σε πολλές αποθήκες.

Σχετικό περιεχόμενο

• Ροές εργασιών ανάπτυξης και ανάπτυξης