Uw pijplijnprojecten beheren met versiebeheer

U kunt versiebeheer gebruiken om de ontwikkeling van een pijplijnproject te beheren en om wijzigingen bij te houden.

Wanneer u met versiebeheer werkt, kunt u tijdens het ontwerpen versies van de projecten vastleggen (commit). Hierdoor kunt u wijzigingen tussen twee versies van het project zien. U kunt uw gegevensprojecten ook ontwikkelen met behulp van een vertakkingsstrategie (branching). Hiermee kunt u in elk werkgebied, of vertakking (branch), aan een geïsoleerde versie van het project werken. Het werkgebied kan door meerdere gebruikers worden gedeeld. U kunt vervolgens uw wijzigingen uit het werkgebied samenvoegen (mergen) naar een hoofdvertakking (main branch) voor implementatie naar productie.

GitHub wordt gebruikt als provider voor versiebeheer. De implementatie volgt het model van de gedeelde opslagplaats.

• GitHub Enterprise Cloud en GitHub Enterprise Server worden niet ondersteund.

• Voor meer informatie over het model van de gedeelde opslagplaats, raadpleegt u About collaborative development models.

• Voor meer informatie over Git en GitHub, raadpleegt u About GitHub and Git.

• Beveiligingsoverwegingen voor GitHub

  Qlik Talend Cloud ondersteunt het HTTPS-beveiligingsprotocol en Personal Access Tokens (PAT), wat de standaardverificatiemodus is voor GitHub. Voor meer informatie raadpleegt u About authentication to GitHub.

Aan de slag

• Maak een gebruiker aan in GitHub die de tenant kan gebruiken om toegang te krijgen tot GitHub. Deze is mogelijk al voor u aangemaakt door een beheerder.

  De gebruiker moet de volgende scopes hebben:

  • repo

  • read:org

  • read:user

  • read:project

• U hebt schrijftoegang nodig tot de opslagplaatsen die u wilt wijzigen.

• U moet een persoonlijk toegangstoken (klassiek) voor GitHub maken. Fijnmazige persoonlijke toegangstokens worden niet ondersteund.

  Voor meer informatie raadpleegt u de GitHub-documentatie: Managing your personal access tokens.

• Organisatie is verplicht in de GitHub-configuratie.

• U hebt de rol Kan bewerken nodig in de ruimte waar het project zich bevindt om versiebeheeracties uit te voeren.

• Voordat u versiebeheer kunt gaan gebruiken, moet u een configuratie instellen om verbinding te maken met GitHub met de GitHub-gebruiker die u hebt gemaakt.

  Configuratie voor GitHub instellen

• Wanneer u een verbinding met GitHub hebt ingesteld, kunt u een project verbinden met een opslagplaats.

  Een project verbinden met een opslagplaats

Configuratie voor GitHub instellen

Alle gebruikers die met versiebeheer willen werken, moeten een configuratie instellen om verbinding te maken met GitHub met behulp van een GitHub-gebruikersaccount.

U kunt GitHub configureren in Pijplijnprojecten of in uw gebruikersprofielinstellingen. Zorg ervoor dat u zich hebt voorbereid volgens Aan de slag.

Om GitHub te configureren in Pijplijnprojecten:

1. Klik op en vervolgens op GitHub-configuratie.

2. Stel verificatie in met behulp van uw organisatie en het persoonlijke toegangstoken voor GitHub zoals beschreven in Aan de slag.

3. Klik op OK.

U kunt nu uw projecten verbinden met een opslagplaats.

Een project verbinden met een opslagplaats

U moet een project verbinden met een opslagplaats voordat u versiebeheer kunt gaan gebruiken. Zorg ervoor dat u een verbinding met GitHub hebt ingesteld.

1. Klik in Pijplijnprojecten op ... bij een project en selecteer Verbinden met versiebeheer.

2. Selecteer aan welke opslagplaats u het project wilt koppelen.

3. Voeg een basismappad toe.

   Als u verbinding wilt maken met een bestaand project in GitHub, moet u hetzelfde pad gebruiken.

4. U kunt ervoor kiezen om het project vast te leggen (commit) en het project na de verbinding naar de externe opslagplaats te pushen. Voer een commit-bericht in.

   Als u niet commit en pusht, wordt er een hoofdvertakking (main branch) gemaakt in het werkgebied, maar niet in de externe opslagplaats.

5. Klik op Verbinden.

Het project is nu verbonden met de geselecteerde opslagplaats. Dit wordt onderaan de projectkaart aangegeven met , de naam van de opslagplaats en de huidige vertakking.

Wanneer u het project opent, bevat de titelrij nu een GitHub-menu met opties voor versiebeheer. De projectnaam wordt ook aangevuld met de naam van de huidige vertakking.

Een project ontwikkelen met versiebeheer

U kunt versiebeheer met verschillende benaderingen gebruiken:

• Rechtstreeks werken op de hoofdvertakking. Dit is voornamelijk geschikt voor een enkele ontwikkelaar op een project die wijzigingen wil bijhouden, maar kan ook worden gebruikt door een groep ontwikkelaars die synchroon werken.

• Werken met een vertakkingsstrategie, waaraan meerdere ontwikkelaars kunnen bijdragen. U kunt ook vertakkingen maken om nieuwe functies of wijzigingen van elkaar te isoleren.

Vereenvoudigde workflow voor een project met één ontwikkelaar

U kunt rechtstreeks op de hoofdvertakking van een project werken. Deze benadering is eenvoudiger en bevat minder bewerkingen, maar stelt u toch in staat om wijzigingen bij te houden. Als er meer dan één ontwikkelaar is, moeten ze oppassen dat ze synchroon blijven.

Wanneer u wijzigingen in het project hebt aangebracht die u wilt toepassen, voert u gewoon een Commit en push uit.

Workflow voor een project met meerdere ontwikkelaars

Deze workflow kan worden gebruikt als er meer dan één ontwikkelaar aan een project werkt, of als u wijzigingen wilt isoleren. Dit omvat het maken van een ontwikkelingsvertakking die u met andere gebruikers kunt delen. Met deze workflow kunnen de ontwikkelaars elkaars wijzigingen bijhouden en beslissen wanneer ze de wijzigingen in de hoofdvertakking willen samenvoegen.

1. Een nieuwe vertakking maken

   Maak een nieuwe ontwikkelingsvertakking vanuit de hoofdvertakking. U kunt de vertakking met meer gebruikers delen.

2. Ontwikkelen

   Breng alle vereiste wijzigingen aan in het project.

   InformatieDatabaseschema's en verbindingen worden niet bijgehouden in versiebeheer.

3. Externe wijzigingen toepassen

   Pas externe wijzigingen van een andere vertakking toe op uw werkgebied om ervoor te zorgen dat u up-to-date bent met wijzigingen van de andere vertakking. Dit is handig om conflicterende wijzigingen te voorkomen of te beperken.

   Als u twee vertakkingen hebt met wijzigingen die mogelijk conflicteren, is een tijdelijke oplossing om:

   1. Wijzigingen in beide werkgebieden vast te leggen (commit).

   2. Beide vertakkingen samen te voegen (merge) naar main.

   3. Externe wijzigingen opnieuw toe te passen.

4. Commit en push

   Commit en push uw wijzigingen naar de ontwikkelingsvertakking. Alle objecten worden gepusht, dus het is een goed idee om uw project te valideren voordat u het vastlegt.

5. Een pull-aanvraag maken en samenvoegen

   Wanneer u klaar bent met de ontwikkeling, is het tijd om de wijzigingen uit het werkgebied samen te voegen naar de hoofdvertakking.

   U kunt de pull-aanvraag maken in het versiebeheer van het project, maar het samenvoegen moet worden uitgevoerd in GitHub, waar u ook goedkeuringen kunt instellen. Voor meer informatie raadpleegt u de GitHub Pull requests documentation

Een nieuwe vertakking maken

1. Klik in het project op GitHub en selecteer Nieuwe vertakking maken.

   Het project moet verbonden zijn met versiebeheer. U moet ook toestemming hebben voor de ruimte waar de doelverbinding van het project zich bevindt.

2. Selecteer om een vertakking te maken vanuit de hoofdvertakking.

3. Voer een naam in voor de vertakking.

4. Stel een voorvoegsel in dat moet worden toegevoegd aan alle schema's in het project in Vertakkingsvoorvoegsel voor alle schema's. Hierdoor kunnen alle schema's een unieke naam krijgen om naamgevingsconflicten te voorkomen.

5. Klik op Maken

Er wordt een nieuwe vertakking gemaakt vanuit main en uitgecheckt uit de opslagplaats. De vertakking bevat een nieuwe versie van het project, met alle taken in de status Nieuw. Dat wil zeggen dat ze niet zijn voorbereid en geen gegevens bevatten.

Externe wijzigingen toepassen

U kunt wijzigingen uit de externe opslagplaats toepassen op uw werkgebied. Dit kunnen wijzigingen zijn die zijn gemaakt buiten het geïntegreerde versiebeheer van Qlik Cloud, bijvoorbeeld in GitHub of door andere tools. Dit helpt u conflicten te voorkomen wanneer u uw wijzigingen wilt vastleggen en pushen naar de vertakking.

1. Klik in het project op GitHub en selecteer Externe wijzigingen toepassen.

   Het dialoogvenster Externe wijzigingen toepassen op werkgebied wordt weergegeven als er wijzigingen zijn gevonden.

2. U kunt nu selecteren voor welke taken u wijzigingen wilt toepassen en de wijzigingen inspecteren. Voor elke wijziging kunt u selecteren welke versie u wilt gebruiken, de externe versie of de versie in uw werkgebied.

   Breng eventuele vereiste wijzigingen aan voor het toewijzen van verbindingen die verschillen tussen het project en het geïmporteerde project.

   Het geïmporteerde project kan bijvoorbeeld een bronverbinding gebruiken met de naam SQL1, terwijl dit project een vergelijkbare verbinding gebruikt met de naam SQL2. Wijs in dit geval de geïmporteerde verbinding toe aan SQL2 in Verbindingen instellen voor de taken die in de oorspronkelijke versie zijn toegevoegd.

   Als de wijzigingen projectoverschrijdende bronnen bevatten en het project waarnaar wordt verwezen onder versiebeheer valt, is er een Vertakking-selector beschikbaar voor elke projectoverschrijdende bron. Selecteer de vertakking die u wilt gebruiken. Als het project waarnaar wordt verwezen niet onder versiebeheer valt, wordt de vertakkingsselector niet weergegeven.

   InformatieWanneer u een verbinding selecteert om toe te wijzen, kunt u een nieuwe databaseverbinding maken, maar geen SaaS-applicatieverbinding.

3. Klik op Externe wijzigingen toepassen

U moet bronverbindingen en doelverbindingen toevoegen als de wijzigingen nieuwe gegevenstaken bevatten.

Committen en pushen

U kunt uw wijzigingen committen en pushen naar de vertakking. Aangezien externe wijzigingen die niet op uw werkgebied zijn toegepast, kunnen worden overschreven, moet u Externe wijzigingen toepassen uitvoeren voordat u commit en pusht.

1. Klik in het project op GitHub en selecteer Commit en push.

   Het dialoogvenster Commit en push wordt weergegeven als er wijzigingen zijn gevonden.

2. Voeg een commit-bericht toe dat u kan helpen bij te houden wat er is gewijzigd.

3. Klik op Commit en push

Een pull-aanvraag maken

Maak een pull-aanvraag (PR) om de wijzigingen uit het werkgebied samen te voegen naar de hoofdvertakking.

1. Klik in het project op GitHub bij een project en selecteer Pull-aanvraag maken.

   Het dialoogvenster Pull-aanvraag maken wordt weergegeven.

2. Voeg een titel en een beschrijving van de pull-aanvraag toe.

   U kunt er ook voor kiezen om de pull-aanvraag na het maken in GitHub te openen.

3. Klik op Pull-aanvraag maken.

U kunt nu goedkeuringen instellen voor de pull-aanvraag en de samenvoeging uitvoeren in GitHub.

Een vertakking verwijderen

U kunt een vertakking verwijderen wanneer u uw wijzigingen hebt samengevoegd naar de hoofdvertakking.

1. Klik in het project op de vertakking die u wilt verwijderen en selecteer Vertakking verwijderen.

   U kunt ervoor kiezen om ook de externe vertakking in versiebeheer te verwijderen.

   Als er niet-vastgelegde wijzigingen zijn, moet u bevestigen dat deze wijzigingen verloren gaan bij het verwijderen van de vertakking.

Versiebeheer voor een project verwijderen

U kunt de verbinding van uw project met versiebeheer verbreken. Als er bestaande vertakkingen zijn, moeten deze worden verwijderd voordat u de verbinding met het project kunt verbreken.

1. Klik in Pijplijnprojecten op ... bij het project waarvan u de verbinding wilt verbreken en selecteer Verbinding met GitHub verbreken.

Een project importeren uit versiebeheer

U kunt een project importeren uit versiebeheer, bijvoorbeeld als u het project van een andere ontwikkelaar wilt beoordelen of wilt samenwerken aan een project. Het importeren van een project uit versiebeheer maakt het ook mogelijk om een project te delen met andere ruimtes of tenants. U kunt een versie van een project delen met een andere ruimte op dezelfde tenant, of op een andere tenant. Dit is handig wanneer u twee omgevingen wilt maken, bijvoorbeeld één voor ontwikkeling en één voor productie."

Voordat u een project importeert

Voordat u begint met het importeren van een project:

• Maak alle nieuwe verbindingen die u nodig hebt als u importeert naar een nieuwe tenant of ruimte.

• Als het project SaaS-applicatieverbindingen gebruikt die nog niet bestaan op de tenant of ruimte, moet u de verbindingen maken en metagegevens genereren voordat u begint met importeren.

• Als u een projectoverschrijdende pijplijn importeert, moet u eerst de stroomopwaartse projecten importeren.

Een project importeren

Als het project taken uit andere projecten verbruikt, moet u projecten en taken toewijzen, tenzij de namen voor ruimtes en projecten identiek zijn.

1. Klik in Gegevensintegratie > Projecten op Nieuwe maken en selecteer Project importeren uit versiebeheer.

2. Selecteer de opslagplaats en selecteer vervolgens de vertakking.

   Selecteer indien nodig het basismappad en klik op Projecten weergeven.

   Selecteer het project dat u wilt importeren uit de lijst.

   Klik op Volgende.

3. Stel Projecteigenschappen in voor het nieuwe project.

   U moet selecteren aan welke ruimte u het project wilt toevoegen in Ruimte.

   In Gegevensplatform kunt u het gegevensplatform van het project en de verbinding met het gegevensplatform wijzigen.

   Het wijzigen van de Verbinding is vereist als u een project van een andere tenant hebt geïmporteerd, of als u het gegevensplatform in de vorige stap hebt gewijzigd.

   U kunt de verbinding met het staging-gebied wijzigen. Dit is vereist als u een project van een andere tenant hebt geïmporteerd, of in sommige gevallen als u het gegevensplatform in de vorige stap hebt gewijzigd.

   Klik op Volgende.

4. Stel Standaard projectinstellingen in voor het nieuwe project.

   U kunt een voorvoegsel toevoegen aan de gegevensschema's die in het project worden gemaakt in Voorvoegsel voor alle schema's. Dit is handig wanneer het geïmporteerde project zich in hetzelfde clouddatawarehouse bevindt als het geëxporteerde project.

   U kunt ook een standaardnaam instellen in Databasenaam. Voor Snowflake-projecten kunt u een standaard Datawarehouse-naam instellen en voor Databricks-projecten kunt u een standaard Catalogusnaam instellen. U kunt de standaardnaam van het project gebruiken voor alle taaktypen, of de naam instellen op standaard of een aangepaste naam voor elk taaktype.

   Klik op Volgende.

5. Stel Verbindingen en taakinstellingen in.

   U kunt de geïmporteerde bronverbindingen of projectoverschrijdende bronnen vervangen. Dit is vereist als u een project van een andere tenant hebt geïmporteerd.

   Bij het toewijzen van een projectoverschrijdende bron aan een project dat onder versiebeheer valt, is er een Vertakking-selector beschikbaar. Selecteer de vertakking van het project waarnaar wordt verwezen om te gebruiken. Als het project waarnaar wordt verwezen niet onder versiebeheer valt, wordt de vertakkingsselector niet weergegeven. Als een projectoverschrijdende bron is toegewezen aan een niet-hoofdvertakking, wordt de vertakkingsnaam tussen haakjes naast de projectnaam weergegeven.

   In Optionele taakinstellingen kunt u ook taakinstellingen wijzigen die in het oorspronkelijke project zijn overschreven.

6. Wanneer u klaar bent, klikt u op Importeren.

Het project wordt toegevoegd aan de startpagina van Gegevensintegratie.

Werken aan een project dat is geïmporteerd uit versiebeheer

U werkt op dezelfde manier als met reguliere projecten met versiebeheer, met een paar verschillen:

• U kunt alleen overschakelen naar de hoofdvertakking, of naar een andere vertakking die is geïmporteerd uit versiebeheer.

• Als u vanuit een vertakking hebt geïmporteerd, is de hoofdvertakking leeg.

• Het verwijderen van een project verwijdert de externe versie niet.

Beveiligingsoverwegingen

Zorg ervoor dat u gesynchroniseerde beveiligingsconfiguraties onderhoudt tussen Qlik Talend Data Integration en GitHub.

• In Qlik Talend Data Integration zijn machtigingen gebaseerd op ruimtes die meerdere projecten kunnen bevatten. In GitHub zijn machtigingen gebaseerd op opslagplaatsen die ook meerdere projecten kunnen bevatten. De beste werkwijze is om ze op elkaar af te stemmen en alle projecten in één ruimte te verbinden met dezelfde opslagplaats.

• Houd er rekening mee dat Qlik Talend Data Integration en GitHub verschillende machtigingen en rollen voor gebruikers gebruiken.

Beste werkwijzen

Hier zijn enkele algemene beste werkwijzen bij het werken met projecten die versiebeheer gebruiken.

• Voeg een README-bestand toe dat de opslagplaats in GitHub beschrijft. Voor meer informatie raadpleegt u About READMEs.

  Als u met een lege opslagplaats begint, voegt het versiebeheer van Qlik Talend Cloud automatisch een leeg README.md-bestand toe.

• Over het algemeen moet u het versiebeheer van Qlik Talend Cloud de GitHub-opslagplaats laten beheren.

• Commit alleen projecten die geldig zijn en getest zijn om te worden uitgevoerd.

  Als u projecten toevoegt met Landing- of Geregistreerde gegevenstaken die niet zijn voorbereid of getransformeerd, zijn de bronkolommen nog niet opgenomen. Bronkolommen worden toegevoegd wanneer de taak wordt voorbereid en getransformeerd.

• Wanneer u een vertakking maakt voor replicatieprojecten, moet u zich ervan bewust zijn dat de vertakkingen standaard hetzelfde doel gebruiken. Dit betekent dat het uitvoeren van taken in de vertakking gegevens van de hoofdversie kan overschrijven. Om gegevensverlies te voorkomen, wijzigt u de doelinstellingen in de vertakking zodat deze niet conflicteren met de hoofdversie.

• Wanneer u een vertakking maakt, kunnen er externe wijzigingen zijn die nog niet zijn toegepast op het werkgebied. Pas externe wijzigingen toe voor of na het maken van de vertakking, tenzij u de externe wijzigingen wilt negeren.

• Het aanbrengen van wijzigingen in dezelfde gegevensset in twee verschillende vertakkingen kan leiden tot samenvoegingsconflicten die moeilijk op te lossen zijn en tot het opnieuw maken van de gegevensset.

  InformatieWanneer een gegevensset aan een taak wordt toegevoegd, krijgt deze een interne identificatie. Interne identificaties worden gebruikt om naadloze naamswijzigingen en andere metagegevensbewerkingen in een pijplijn mogelijk te maken. Bij het maken van dezelfde gegevensset in een afzonderlijk project of vertakking, zal de interne identificatie anders zijn, wat een conflict kan veroorzaken bij het samenvoegen van de twee vertakkingen. Dit kan ertoe leiden dat het voorbereidingsproces een gegevensset verwijdert en opnieuw maakt, zelfs als deze dezelfde naam heeft.

Werken in vertakkingen

U kunt een project maken, het ontwerpen en wanneer het klaar is, het implementeren naar productie met behulp van de MAIN-vertakking. De versie op MAIN komt overeen met uw productie-pijplijn. U mag de MAIN-vertakking nooit rechtstreeks bewerken na de eerste implementatie.

Elke keer dat een ontwikkelaar een nieuwe wijziging in een project wil aanbrengen, zoals het toevoegen van een functie of het corrigeren van een bug, moet er een nieuwe vertakking worden gemaakt.

Ontwikkelaars kunnen een willekeurig aantal vertakkingen maken voor hun ontwikkelingsbehoeften

• Gebruik schemavoorvoegsels voor vertakkingen om databaseconflicten te voorkomen tijdens het aanbrengen van de wijzigingen.

• In een vertakking kunnen ontwikkelaars een willekeurig aantal wijzigingen aanbrengen en zo vaak als nodig committen en pushen. Het wordt aanbevolen om elke wijziging te isoleren in een op zichzelf staande, afzonderlijke commit. Als u bijvoorbeeld een wijziging aanbrengt in een transformatietaak die ook van invloed is op de datamart, zorg er dan voor dat u beide wijzigingen in één commit opneemt

• Alle teamleden moeten op elk moment Externe wijzigingen toepassen gebruiken om ervoor te zorgen dat hun MAIN up-to-date is, vooral voordat ze hun wijzigingen committen.

Wanneer ontwikkelaars klaar zijn met werken in hun vertakking, kunnen ze een pull-aanvraag maken voor peer review.

Na beoordeling en goedkeuring door andere teamleden kunt u de pull-aanvraag samenvoegen met de MAIN-versie in GitHub .

Gebruik ten slotte Externe wijzigingen toepassen in het project om de goedgekeurde vertakkingswijzigingen terug te halen naar de MAIN-vertakking (productie).

Werken in ruimtes

Voor grotere en kritieke implementaties wordt aanbevolen om speciale ruimtes te gebruiken voor ontwikkeling en productie om wijzigingen te isoleren en de integriteit van de pijplijn te waarborgen. Gebruik speciale gegevensverbindingen voor bronnen en doel in elke ruimte.

• Productie

  De MAIN-vertakking weerspiegelt wat er in productie is. Dit betekent dat er slechts één MAIN-versie van een project is.

  De productie is geïsoleerd in een speciale gegevensruimte, bijvoorbeeld PROD. Speciale verbindingen worden toegewezen aan de productieruimte.

  Er worden geen wijzigingen rechtstreeks in de productieruimte/MAIN-vertakking aangebracht. Alle wijzigingen worden aangebracht in andere ruimtes met speciale verbindingen, met behulp van vertakkingen.

  U kunt de MAIN-versie van een bestaand project in GitHub hergebruiken. Maak een leeg project met dezelfde naam als het bestaande project in GitHub. Hiermee wordt de laatst beschikbare versie op de MAIN-vertakking opgehaald om te beginnen met bewerken.

  Gebruikers maken een nieuwe vertakking, brengen hun wijzigingen aan, maken pull-aanvragen, voegen samen en halen terug naar MAIN/Productie.

• Ontwikkeling

  Ontwikkelaars kunnen hun wijzigingen isoleren in een speciale gegevensruimte, bijvoorbeeld DEV. Speciale verbindingen worden toegewezen aan de DEV-ruimte.

  Wijzigingen worden geïsoleerd met behulp van vertakkingen, meestal één vertakking per ontwikkelaar. Gebruik schemavoorvoegsels wanneer een vertakking wordt gemaakt om databaseconflicten te voorkomen tijdens het aanbrengen van de wijzigingen.

• Beoordeling / kwaliteitsacceptatie

  Beoordelaars krijgen toegang tot ontwikkelingsruimtes en verbindingen om:.

  • Projectvertakkingen te openen en te testen in Qlik Talend Cloud.

  • Pull-aanvragen goed te keuren om door te gaan met samenvoegen in GitHub.

  • Teamleden te informeren wanneer goedgekeurde wijzigingen kunnen worden teruggehaald naar MAIN/Productie.

Wanneer u de goedgekeurde wijzigingen terug implementeert naar de MAIN/Productie-ruimte, moet u verbindingen opnieuw toewijzen aan de productieruimteverbindingen.

Beperkingen

• Versiebeheer wordt niet ondersteund voor projecten met Qlik Cloud (QVD) als doel.

• Het is niet mogelijk om de verbinding met een project te verbreken of een project te verwijderen met behulp van versiebeheer als er vertakkingen zijn. De vertakkingen moeten worden verwijderd voordat u de verbinding met het project kunt verbreken of het project kunt verwijderen.

• Het is niet mogelijk om de naam van een project te wijzigen met behulp van versiebeheer.

• Wanneer u een tenant verwijdert, worden objecten die met versiebeheer in GitHub zijn opgeslagen, niet verwijderd. U moet deze objecten handmatig verwijderen.

• als een opslagplaats door veel projecten wordt gebruikt, of veel bestanden bevat die niet zijn opgeslagen in Qlik Talend Data Integration, kunnen de prestaties afnemen.

• Databaseschema's en verbindingen worden niet bijgehouden in versiebeheer.

• Fijnmazige persoonlijke toegangstokens voor GitHub worden niet ondersteund.

• Een vertakking (behalve de hoofdvertakking) kan door slechts één project per opslagplaats worden gebruikt, zelfs als twee projecten zich in dezelfde opslagplaats bevinden.

• Het is niet mogelijk om externe wijzigingen toe te passen vanuit een project dat een ander doelplatform gebruikt. Als u bijvoorbeeld wijzigingen in een project op Snowflake vastlegt, kunt u de wijzigingen niet toepassen op een Databricks-project.