Vorige

Volgende

Continue integratie en implementatie

Voltooid

Continue integratie is de praktijk van het automatisch en zo vroeg mogelijk testen van elke wijziging in uw codebase. 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 van Azure Resource Manager-sjablonen voor het opslaan van de configuratie van uw verschillende Azure Data Factory-entiteiten (pijplijnen, gegevenssets, gegevensstromen, enzovoort). Er zijn twee voorgestelde methoden om een data factory te promoveren naar een andere omgeving:

• Geautomatiseerde implementatie met behulp van de integratie van Data Factory met Azure Pipelines.
• Upload handmatig een Resource Manager-sjabloon met behulp van Data Factory UX-integratie met Azure Resource Manager.

Continue integratie/continue leveringslevenscyclus

Hieronder ziet u een voorbeeldoverzicht van de CI/CD-levenscyclus in een Azure-gegevensfactory die is geconfigureerd met Azure Repos Git.

1. Er wordt een ontwikkelingsdata factory gemaakt en geconfigureerd met Azure Repos Git. Alle ontwikkelaars moeten gemachtigd zijn om Data Factory-resources te ontwerpen, zoals pijplijnen en gegevenssets.

2. Een ontwikkelaar maakt een functiebranch om een wijziging aan te brengen. Ze opsporen fouten in hun pijplijnuitvoeringen met de meest recente wijzigingen.

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

4. Nadat een pull-aanvraag is goedgekeurd en wijzigingen zijn samengevoegd in de hoofdvertakking, worden de wijzigingen gepubliceerd naar de ontwikkelingsfactory.

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

6. Nadat de wijzigingen in de testfactory zijn geverifieerd, implementeert u deze in de productiefactory met behulp van de volgende taak van de release van de pijplijnen.

Notitie

Alleen de ontwikkelingsfactory is gekoppeld aan een Git-opslagplaats. Aan de test- en productiefabrieken mag geen Git-opslagplaats zijn gekoppeld en moet alleen worden bijgewerkt via een Azure DevOps-pijplijn of via een Resource Management-sjabloon.

In de onderstaande afbeelding ziet u de verschillende stappen van deze levenscyclus.

Continue integratie automatiseren met behulp van Azure Pipelines-releases

Hier volgt een handleiding voor het instellen van een Azure Pipelines-release waarmee de implementatie van een data factory in meerdere omgevingen wordt geautomatiseerd.

Vereisten

• Een Azure-abonnement dat is gekoppeld aan Visual Studio Team Foundation Server of Azure-opslagplaatsen die gebruikmaken van het Azure Resource Manager-service-eindpunt

• Een data factory die is geconfigureerd met Git-integratie met Azure-opslagplaatsen.

• Een Azure-sleutelkluis die de geheimen voor elke omgeving bevat.

Een Azure Pipelines-release instellen

1. Open in Azure DevOps het project dat is geconfigureerd met uw data factory.

2. Selecteer pijplijnen aan de linkerkant van de pagina en selecteer Vervolgens Releases.

   

3. Selecteer Nieuwe pijplijn, of als u bestaande pijplijnen hebt, selecteert u Nieuw en vervolgens Nieuwe release-pijplijn.

4. Selecteer de sjabloon Lege taak .

   

5. Voer in het vak Fasenaam de naam van uw omgeving in.

6. Selecteer Artefact toevoegen en selecteer vervolgens de Git-opslagplaats die is geconfigureerd met uw ontwikkelingsdata factory. Selecteer de publicatiebranch van de opslagplaats voor de standaardbranch. Deze publicatiebranch is adf_publishstandaard. Voor de standaardversie selecteert u Nieuwste in de standaardbranch.

   

7. Een Azure Resource Manager-implementatietaak toevoegen:

   a. Selecteer fasetaken weergeven in de faseweergave.

   

   b. Maak een nieuwe taak. Zoek naar ARM-sjabloonimplementatie en selecteer vervolgens Toevoegen.

   c. Selecteer in de implementatietaak het abonnement, de resourcegroep en de locatie voor de doelgegevensfactory. Geef indien nodig referenties op.

   d. Selecteer in de lijst Actie de optie Resourcegroep maken of bijwerken.

   e. Selecteer de knop met het beletselteken (...) naast het vak Sjabloon . Blader naar de Azure Resource Manager-sjabloon die wordt gegenereerd in uw publicatiebranch van de geconfigureerde Git-opslagplaats. Zoek het bestand ARMTemplateForFactory.json in de <FactoryName> map van de adf_publish vertakking.

   f. Selecteer ... naast het vak Sjabloonparameters om het parameterbestand te kiezen. Zoek het bestand ARMTemplateParametersForFactory.json in de <FactoryName> map van de adf_publish vertakking.

   g. Selecteer ... naast het vak Sjabloonparameters overschrijven en voer de gewenste parameterwaarden in voor de doeldata factory. Voer de naam van het geheim tussen dubbele aanhalingstekens in voor referenties die afkomstig zijn van Azure Key Vault. Als de naam van het geheim bijvoorbeeld cred1 is, voert u '$(cred1)' in voor deze waarde.

   h. Selecteer Incrementeel voor de implementatiemodus.

   Waarschuwing

   In de volledige implementatiemodus worden resources die aanwezig zijn in de resourcegroep, maar die niet zijn opgegeven in de nieuwe Resource Manager-sjabloon verwijderd.

   

8. Sla de release-pijplijn op.

9. Als u een release wilt activeren, selecteert u Release maken. In Azure DevOps kan dit worden geautomatiseerd.

   

Belangrijk

In CI/CD-scenario's moet het type Integration Runtime (IR) in verschillende omgevingen hetzelfde zijn. Als u bijvoorbeeld een zelf-hostende IR in de ontwikkelomgeving hebt, moet dezelfde IR ook van het type zelf-hosten in andere omgevingen zijn, zoals testen en productie. Als u integratieruntimes in meerdere fasen deelt, moet u ook de integratieruntimes configureren als gekoppeld zelf-hostend in alle omgevingen, zoals ontwikkeling, testen en productie.

Geheimen ophalen uit Azure Key Vault

Als u geheimen hebt om een Azure Resource Manager-sjabloon door te geven, raden we u aan Azure Key Vault te gebruiken met de release van Azure Pipelines.

Er zijn twee manieren om geheimen te verwerken:

1. Voeg de geheimen toe aan het parameterbestand.

   Maak een kopie van het parameterbestand dat is geüpload naar de publicatiebranch. Stel de waarden in van de parameters die u wilt ophalen uit Key Vault met behulp van deze indeling:

   {
       "parameters": {
           "azureSqlReportingDbPassword": {
               "reference": {
                   "keyVault": {
                       "id": "/subscriptions/<subId>/resourceGroups/<resourcegroupId> /providers/Microsoft.KeyVault/vaults/<vault-name> "
                   },
                   "secretName": " < secret - name > "
               }
           }
       }
   }
   

   Wanneer u deze methode gebruikt, wordt het geheim automatisch opgehaald uit de sleutelkluis.

   Het parameterbestand moet zich ook in de publicatiebranch bevinden.

2. Voeg een Azure Key Vault-taak toe vóór de Azure Resource Manager-implementatietaak die in de vorige sectie wordt beschreven:

   1. Maak een nieuwe taak op het tabblad Taken . Zoek naar Azure Key Vault en voeg deze toe.

   2. Selecteer in de Key Vault-taak het abonnement waarin u de sleutelkluis hebt gemaakt. Geef indien nodig referenties op en selecteer vervolgens de sleutelkluis.

   

Machtigingen verlenen aan de Azure Pipelines-agent

De Azure Key Vault-taak kan mislukken met de fout Toegang geweigerd als de juiste machtigingen niet zijn ingesteld. Download de logboeken voor de release en zoek het PS1-bestand met de opdracht om machtigingen te verlenen aan de Azure Pipelines-agent. U kunt de opdracht rechtstreeks uitvoeren. U kunt ook de principal-id uit het bestand kopiëren en het toegangsbeleid handmatig toevoegen in Azure Portal. Get en List zijn de minimale machtigingen vereist.

Actieve triggers bijwerken

Implementatie kan mislukken als u actieve triggers probeert bij te werken. Als u actieve triggers wilt bijwerken, moet u ze handmatig stoppen en opnieuw opstarten na de implementatie. U kunt dit doen met behulp van een Azure PowerShell-taak:

1. Voeg op het tabblad Taken van de release een Azure PowerShell-taak toe. Kies taakversie 4.*.

2. Selecteer het abonnement waarin uw factory zich bevindt.

3. Selecteer Scriptbestandspad als het scripttype. Hiervoor moet u uw PowerShell-script opslaan in uw opslagplaats. Het volgende PowerShell-script kan worden gebruikt om triggers te stoppen:

   $triggersADF = Get-AzDataFactoryV2Trigger -DataFactoryName $DataFactoryName -ResourceGroupName $ResourceGroupName
   
   $triggersADF | ForEach-Object { Stop-AzDataFactoryV2Trigger -ResourceGroupName $ResourceGroupName -DataFactoryName $DataFactoryName -Name $_.name -Force }
   

U kunt vergelijkbare stappen (met de Start-AzDataFactoryV2Trigger functie) uitvoeren om de triggers na de implementatie opnieuw op te starten.

Notitie

Deze stappen zijn al opgenomen in de pre- en post-implementatiescripts van het Azure Data Factory-team

Een Resource Manager-sjabloon handmatig promoveren voor elke omgeving

Als u Azure DevOps of een ander hulpprogramma voor releasebeheer niet kunt gebruiken, kunt u handmatig een data factory promoveren met behulp van een ARM-sjabloon.

1. Selecteer ARM-sjabloon exporteren in de lijst met ARM-sjablonen om de Resource Manager-sjabloon voor uw data factory in de ontwikkelomgeving te exporteren.

   

2. Selecteer ARM-sjabloon importeren in uw test- en productiegegevensfactory's. Met deze actie gaat u naar Azure Portal, waar u de geëxporteerde sjabloon kunt importeren. Selecteer Uw eigen sjabloon maken in de editor om de Resource Manager-sjablooneditor te openen.

   

3. Selecteer Bestand laden en selecteer vervolgens de gegenereerde Resource Manager-sjabloon. Dit is het bestand arm_template.json dat zich bevindt in het ZIP-bestand dat in stap 1 is geëxporteerd.

   

4. Voer in de sectie Instellingen de configuratiewaarden in, zoals gekoppelde servicereferenties. Wanneer u klaar bent, selecteert u Kopen om de Resource Manager-sjabloon te implementeren.

   

Azure Resource Manager-sjabloonparameters aanpassen

Als uw ontwikkelingsfactory een gekoppelde Git-opslagplaats heeft, kunt u de standaardparameters van de Resource Manager-sjabloon overschrijven die zijn gegenereerd door het publiceren of exporteren van de sjabloon. In deze scenario's kunt u de standaardparametersjabloon overschrijven:

• U gebruikt geautomatiseerde CI/CD en u wilt bepaalde eigenschappen wijzigen tijdens de Implementatie van Resource Manager, maar de eigenschappen worden niet standaard geparameteriseerd.
• Uw fabriek is zo groot dat de standaard Resource Manager-sjabloon ongeldig is omdat deze meer dan de maximaal toegestane parameters (256) heeft.

Als u de standaardparametersjabloon wilt overschrijven, gaat u naar de beheerhub en selecteert u Parameterisatiesjabloon in de sectie broncodebeheer. Selecteer Sjabloon bewerken om de code-editor voor parameteriseringssjablonen te openen.

Als u een aangepaste parameteriseringssjabloon maakt, maakt u een bestand met de naam arm-template-parameters-definition.json in de hoofdmap van uw Git-vertakking. U moet die exacte bestandsnaam gebruiken.

Bij publicatie vanuit de samenwerkingsbranch leest Data Factory dit bestand en gebruikt data factory de configuratie om te genereren welke eigenschappen worden geparameteriseerd. Als er geen bestand wordt gevonden, wordt de standaardsjabloon gebruikt.

Wanneer u een Resource Manager-sjabloon exporteert, leest Data Factory dit bestand uit de vertakking waaraan u momenteel werkt, niet de samenwerkingsvertakking. U kunt het bestand maken of bewerken vanuit een privévertakking, waar u uw wijzigingen kunt testen door ARM-sjabloon exporteren te selecteren in de gebruikersinterface. Vervolgens kunt u het bestand samenvoegen in de samenwerkingsbranch.

Notitie

Met een aangepaste parameteriseringssjabloon wordt de limiet van de ARM-sjabloonparameter van 256 niet gewijzigd. Hiermee kunt u het aantal geparameteriseerde eigenschappen kiezen en verkleinen.

Aangepaste parametersyntaxis

Hier volgen enkele richtlijnen die u moet volgen wanneer u het aangepaste parameterbestand arm-template-parameters-definition.json maakt. Het bestand bestaat uit een sectie voor elk entiteitstype: trigger, pijplijn, gekoppelde service, gegevensset, integratieruntime en gegevensstroom.

• Voer het eigenschapspad in onder het relevante entiteitstype.
• Als u een eigenschapsnaam instelt om aan te * geven dat u alle eigenschappen eronder wilt parameteriseren (alleen op het eerste niveau, niet recursief). U kunt ook uitzonderingen opgeven voor deze configuratie.
• Als u de waarde van een eigenschap instelt als een tekenreeks, geeft u aan dat u de eigenschap wilt parameteriseren. Gebruik de indeling <action>:<name>:<stype>.
  • <action> kan een van deze tekens zijn:
    • = betekent dat de huidige waarde behouden blijft als de standaardwaarde voor de parameter.
    • - betekent dat de standaardwaarde voor de parameter niet behouden blijft.
    • |is een speciaal geval voor geheimen uit Azure Key Vault voor verbindingsreeks s of sleutels.
  • <name> is de naam van de parameter. Als deze leeg is, wordt de naam van de eigenschap gebruikt. Als de waarde begint met een - teken, wordt de naam ingekort. Zou bijvoorbeeld AzureStorage1_properties_typeProperties_connectionString worden ingekort tot AzureStorage1_connectionString.
  • <stype> is het type parameter. Als <stype> dit leeg is, is stringhet standaardtype . Ondersteunde waarden: string, bool, number, en objectsecurestring.
• Het opgeven van een matrix in het definitiebestand geeft aan dat de overeenkomende eigenschap in de sjabloon een matrix is. Data Factory doorloopt alle objecten in de matrix met behulp van de definitie die is opgegeven in het integration runtime-object van de matrix. Het tweede object, een tekenreeks, wordt de naam van de eigenschap, die wordt gebruikt als de naam voor de parameter voor elke iteratie.
• Een definitie kan niet specifiek zijn voor een resource-exemplaar. Elke definitie is van toepassing op alle resources van dat type.
• Standaard worden alle beveiligde tekenreeksen, zoals Key Vault-geheimen en beveiligde tekenreeksen, zoals verbindingsreeks s, sleutels en tokens, geparameteriseerd.

Gekoppelde sjablonen

Als u CI/CD hebt ingesteld voor uw gegevensfactory's, kunt u de limieten van de Azure Resource Manager-sjabloon overschrijden naarmate uw fabriek groter wordt. Eén limiet is bijvoorbeeld het maximum aantal resources in een Resource Manager-sjabloon. Voor grote factory's tijdens het genereren van de volledige Resource Manager-sjabloon voor een fabriek genereert Data Factory nu gekoppelde Resource Manager-sjablonen. Met deze functie wordt de volledige nettolading van de fabriek opgesplitst in verschillende bestanden, zodat u niet wordt beperkt door de limieten.

Als u Git hebt geconfigureerd, worden de gekoppelde sjablonen gegenereerd en opgeslagen naast de volledige Resource Manager-sjablonen in de adf_publish vertakking in een nieuwe map met de naam linkedTemplates. De gekoppelde Resource Manager-sjablonen bestaan meestal uit een hoofdsjabloon en een set onderliggende sjablonen die aan het model zijn gekoppeld. De bovenliggende sjabloon wordt ArmTemplate_master.json genoemd en onderliggende sjablonen worden benoemd met het patroon ArmTemplate_0.json, ArmTemplate_1.json, enzovoort.

Als u gekoppelde sjablonen wilt gebruiken in plaats van de volledige Resource Manager-sjabloon, werkt u uw CI/CD-taak bij zodat deze verwijst naar ArmTemplate_master.json in plaats van ArmTemplateForFactory.json (de volledige Resource Manager-sjabloon). Resource Manager vereist ook dat u de gekoppelde sjablonen uploadt naar een opslagaccount, zodat Azure deze tijdens de implementatie kan openen.

Hotfix-productieomgeving

Als u een fabriek implementeert in productie en u realiseert dat er een bug is die direct moet worden opgelost, maar u de huidige samenwerkingsvertakking niet kunt implementeren, moet u mogelijk een hotfix implementeren. Deze benadering wordt ook wel quick-fix engineering of QFE genoemd.

1. Ga in Azure DevOps naar de release die is geïmplementeerd in productie. Zoek de laatste doorvoering die is geïmplementeerd.

2. Haal in het doorvoerbericht de doorvoer-id van de samenwerkingsbranch op.

3. Maak een nieuwe hotfix-vertakking op basis van die doorvoering.

4. Ga naar de UX van Azure Data Factory en schakel over naar de hotfix-vertakking.

5. Los de fout op met behulp van de UX van Azure Data Factory. Test uw wijzigingen.

6. Nadat de oplossing is geverifieerd, selecteert u ARM-sjabloon exporteren om de hotfix Resource Manager-sjabloon op te halen.

7. Controleer deze build handmatig in de publicatiebranch.

8. Als u uw release-pijplijn zo hebt geconfigureerd dat deze automatisch wordt geactiveerd op basis van adf_publish check-ins, wordt er automatisch een nieuwe release gestart. Anders moet u handmatig een release in de wachtrij plaatsen.

9. Implementeer de hotfix-release in de test- en productiefabrieken. Deze release bevat de vorige nettolading van de productie plus de oplossing die u in stap 5 hebt gemaakt.

10. Voeg de wijzigingen van de hotfix toe aan de ontwikkelvertakking, zodat latere releases niet dezelfde fout bevatten.

Aanbevolen procedures voor continue integratie/continue levering

Als u Git-integratie met uw data factory gebruikt en een CI/CD-pijplijn hebt waarmee uw wijzigingen van de ontwikkeling naar de test worden verplaatst en vervolgens naar productie, raden we deze aanbevolen procedures aan:

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

• Script vóór en na de implementatie. Voordat de Resource Manager-implementatiestap in CI/CD wordt uitgevoerd, moet u bepaalde taken uitvoeren, zoals het stoppen en opnieuw starten van triggers en het uitvoeren van opschonen. U wordt aangeraden PowerShell-scripts vóór en na de implementatietaak te gebruiken. Het data factory-team heeft een script opgegeven dat u kunt gebruiken op de documentatiepagina van Azure Data Factory CI/CD.

• Integratieruntimes en delen. Integratieruntimes veranderen niet vaak en zijn vergelijkbaar in alle fasen in uw CI/CD. Data Factory verwacht dus 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 overwegen om een ternaire factory te gebruiken om alleen de gedeelde integratieruntimes te bevatten. U kunt deze gedeelde factory in al uw omgevingen gebruiken als een gekoppeld type Integration Runtime.

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

• Key Vault. Wanneer u gekoppelde services gebruikt waarvan de verbindingsgegevens zijn opgeslagen in Azure Key Vault, wordt u aangeraden 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 aanpak volgt, raden we u aan om dezelfde geheime namen in alle fasen te bewaren. Als u dezelfde geheime namen bewaart, hoeft u niet elke verbindingsreeks te parameteriseren in CI/CD-omgevingen, omdat het enige dat verandert de naam van de sleutelkluis is. Dit is een afzonderlijke parameter.

• Naamgeving van resources vanwege beperkingen van ARM-sjablonen kan optreden als uw resources spaties in de naam bevatten. Het Azure Data Factory-team raadt aan om tekens '_' of '-' te gebruiken in plaats van spaties voor resources. 'Pipeline_1' is bijvoorbeeld een voorkeursnaam boven 'Pijplijn 1'.

Doorgaan