Continue integratie en levering in Azure Data Factory

VAN TOEPASSING OP: Azure Data Factory Azure Synapse Analytics

Continue integratie is het testen van elke wijziging die in uw codebasis wordt aangebracht, automatisch en zo vroeg mogelijk. Continue levering volgt de tests die tijdens continue integratie worden uitgevoerd en pusht wijzigingen naar een faserings- of productiesysteem.

In Azure Data Factory wordt onder continue integratie en levering (CI/CD) de mogelijkheid verstaan dat Data Factory-pijplijnen van de ene omgeving (ontwikkeling, test, productie) naar de andere worden verplaatst. Azure Data Factory maakt gebruik Azure Resource Manager sjablonen voor het opslaan van de configuratie van uw verschillende ADF-entiteiten (pijplijnen, gegevenssets, gegevensstromen, etc.). Er zijn twee voorgestelde methoden om een data factory naar een andere omgeving te promoveren:

• Geautomatiseerde implementatie met Data Factory integratie van azure-pijplijnen
• Upload handmatig een Resource Manager sjabloon met Data Factory UX-integratie met Azure Resource Manager.

CI/CD-levenscyclus

Hieronder vindt u een voorbeeldoverzicht van de CI/CD-levenscyclus in een Azure data factory die is geconfigureerd met Azure Repos Git. Zie Broncodebeheer in Azure Data Factory voor meer informatie over het configureren van een Git Azure Data Factory.

1. Er wordt data factory ontwikkelingsproces gemaakt en geconfigureerd met Azure Repos Git. Alle ontwikkelaars moeten machtigingen hebben om Data Factory maken, zoals pijplijnen en gegevenssets.

2. Een ontwikkelaar maakt een functie branch om een wijziging aan te brengen. Ze kunnen fouten opsporen in hun pijplijn-runs met hun meest recente wijzigingen. Zie Iteratieve ontwikkeling en foutopsporing met Azure Data Factory voor meer informatie over het opsporen van fouten in een pijplijn Azure Data Factory.

3. Nadat een ontwikkelaar tevreden is met de wijzigingen, maakt hij een pull-aanvraag van de functievertakking naar de hoofdvertakking of samenwerkingsvertakking om de wijzigingen door peers te laten beoordeeld.

4. Nadat een pull-aanvraag is goedgekeurd en wijzigingen zijn samengevoegd in de main branch, worden de wijzigingen gepubliceerd naar de ontwikkelingsfabriek.

5. Wanneer het team klaar is om de wijzigingen te implementeren in een test- of UAT-factory (User Acceptance Testing), gaat het team naar hun Azure Pipelines-release en implementeert het de gewenste versie van de ontwikkelings factory in UAT. Deze implementatie vindt plaats als onderdeel van een Azure Pipelines-taak en maakt gebruik van Resource Manager sjabloonparameters om de juiste configuratie toe te passen.

6. Nadat de wijzigingen in de test factory zijn geverifieerd, implementeert u deze in de productie factory met behulp van de volgende taak van de release van de pijplijnen.

In de onderstaande afbeelding worden de verschillende stappen van deze levenscyclus beschreven.

Best practices voor CI/CD

Als u Git-integratie met uw data factory gebruikt en een CI/CD-pijplijn hebt die uw wijzigingen verplaatst van ontwikkeling naar test en vervolgens naar productie, raden we de volgende best practices aan:

• Git-integratie. Configureer alleen uw data factory met Git-integratie. Wijzigingen in testen en productie worden geïmplementeerd via CI/CD en hebben geen Git-integratie nodig.

• Pre- en post-implementatiescript. Voordat u Resource Manager implementatiestap in CI/CD uitvoert, moet u bepaalde taken uitvoeren, zoals het stoppen en opnieuw starten van triggers en het uitvoeren van opschoning. U wordt aangeraden PowerShell-scripts te gebruiken vóór en na de implementatietaak. Zie Actieve triggers bijwerken voor meer informatie. Het data factory team heeft onder aan deze pagina een script opgegeven dat moet worden gebruikt.

• Integratieruntimes en delen. Integratieruntimes veranderen niet vaak en zijn vergelijkbaar in alle fasen in uw CI/CD. Daarom Data Factory verwacht dat u dezelfde naam en hetzelfde type integratieruntime hebt in alle fasen van CI/CD. Als u integratieruntimes in alle fasen wilt delen, kunt u een ternaire factory gebruiken om alleen de gedeelde integratieruntimes te bevatten. U kunt deze gedeelde factory in al uw omgevingen gebruiken als een gekoppeld type integratieruntime.

• Implementatie van beheerd privé-eindpunt. Als er al een privé-eindpunt in een factory bestaat en u probeert een ARM-sjabloon te implementeren die een privé-eindpunt met dezelfde naam bevat, maar met gewijzigde eigenschappen, mislukt de implementatie. Met andere woorden, u kunt een privé-eindpunt implementeren zolang het dezelfde eigenschappen heeft als het eindpunt dat al in de factory bestaat. Als een eigenschap verschilt tussen omgevingen, kunt u deze overschrijven door die eigenschap te parameteriseren en de respectieve waarde op te geven tijdens de implementatie.

• Key Vault. Wanneer u gekoppelde services gebruikt waarvan de verbindingsgegevens worden opgeslagen in Azure Key Vault, is het raadzaam om afzonderlijke sleutelkluizen voor verschillende omgevingen te bewaren. U kunt ook afzonderlijke machtigingsniveaus configureren voor elke sleutelkluis. U wilt bijvoorbeeld niet dat uw teamleden machtigingen hebben voor productiegeheimen. Als u deze methode volgt, raden we u aan om dezelfde geheime namen in alle fasen te bewaren. Als u dezelfde geheime namen gebruikt, hoeft u niet elke connection string te parameteriseren in CI/CD-omgevingen, omdat het enige dat verandert de naam van de sleutelkluis is, wat een afzonderlijke parameter is.

• Resourcenaamgeving. Vanwege arm-sjabloonbeperkingen kunnen er problemen optreden in de implementatie als uw resources spaties in de naam bevatten. Het Azure Data Factory team raadt aan om '_' of '-' tekens te gebruiken in plaats van spaties voor resources. 'Pipeline_1' heeft bijvoorbeeld de voorkeur boven Pijplijn 1.

• Besturingselement voor blootstelling en functievlaggen. Wanneer u in een team werkt, zijn er gevallen waarin u wijzigingen kunt samenvoegen, maar niet wilt dat ze worden uitgevoerd in omgevingen met verhoogde niveaus, zoals PROD en QA. Voor het afhandelen van dit scenario raadt het ADF-team het DevOps-concept aan om functievlaggen te gebruiken. In ADF kunt u globale parameters en de if condition-activiteit combineren om logicasets te verbergen op basis van deze omgevingsvlaggen.

  Zie de onderstaande videozelfstudie voor meer informatie over het instellen van een functievlag:

Niet-ondersteunde functies

• Dit is Data Factory selectief kiezen van commits of het selectief publiceren van resources is niet toegestaan. Publiceren omvat alle wijzigingen die zijn aangebracht in de data factory.

  • Data Factory-entiteiten zijn afhankelijk van elkaar. Triggers zijn bijvoorbeeld afhankelijk van pijplijnen en pijplijnen zijn afhankelijk van gegevenssets en andere pijplijnen. Selectief publiceren van een subset resources kan leiden tot onverwacht gedrag en fouten.
  • In zeldzame gevallen wanneer u selectief publiceren nodig hebt, kunt u overwegen een hotfix te gebruiken. Zie Hotfix-productieomgeving voor meer informatie.

• Het Azure Data Factory-team raadt niet aan om Azure RBAC-besturingselementen toe te wijzen aan afzonderlijke entiteiten (pijplijnen, gegevenssets, enzovoort) in een data factory. Als een ontwikkelaar bijvoorbeeld toegang heeft tot een pijplijn of gegevensset, heeft deze toegang tot alle pijplijnen en gegevenssets in de data factory. Als u denkt dat u veel Azure-rollen moet implementeren binnen een data factory, bekijkt u het implementeren van een tweede data factory.

• U kunt niet publiceren vanuit privé-vertakkingen.

• U kunt momenteel geen projecten hosten op Bitbucket.

• U kunt momenteel geen waarschuwingen en matrices exporteren en importeren als parameters.

• In de codeopslagplaats onder de adf_publish-vertakking wordt momenteel een map met de naam PartialArmTemplates toegevoegd naast de map linkedTemplates, ARMTemplateForFactory.json en ARMTemplateParametersForFactory.json, als onderdeel van het publiceren met broncodebeheer.

  

  Vanaf 1 november 2021 publiceren we geen PartialArmTemplates meer naar de adf_publish vertakking.

  Er is geen actie vereist, tenzij u 'PartialArmTemplates' gebruikt. Schakel anders over naar een ondersteund mechanisme voor implementaties met behulp van de bestanden ARMTemplateForFactory.json of linkedTemplates.

Volgende stappen

• Continue integratie automatiseren met behulp van Azure Pipelines-releases
• Handmatig een sjabloon Resource Manager naar elke omgeving
• Aangepaste parameters gebruiken met een Resource Manager sjabloon
• Gekoppelde Resource Manager sjablonen
• Een hotfix-productieomgeving gebruiken
• Voorbeeldscript vóór en na de implementatie