Hantera dina pipeline-projekt med versionshantering

Du kan använda versionshantering för att hantera utvecklingen av ett pipeline-projekt och för att hålla reda på ändringar.

När du arbetar med versionshantering kan du checka in (commit) versioner av projekten under designen. Detta gör att du kan se ändringar mellan två versioner av projektet. Du kan också utveckla dina dataprojekt med hjälp av en förgreningsstrategi. Detta låter dig arbeta på en isolerad version av projektet i varje arbetsområde, eller gren. Arbetsområdet kan delas av flera användare. Du kan sedan slå samman dina ändringar från arbetsområdet till en huvudgren för distribution till produktion.

GitHub används som leverantör för versionshantering. Implementeringen följer modellen för delad databas.

• GitHub Enterprise Cloud och GitHub Enterprise Server stöds inte.

• För mer information om modellen för delad databas, se Om samarbetsmodeller för utveckling.

• För mer information om Git och GitHub, se Om GitHub och Git.

• Säkerhetsöverväganden för GitHub

  Qlik Talend Cloud stöder säkerhetsprotokollet HTTPS och personliga åtkomsttoken (PAT), vilket är standardläget för autentisering för GitHub. För mer information, se Om autentisering till GitHub.

Komma igång

• Skapa en användare i GitHub som din klientorganisation kan använda för att få åtkomst till GitHub. Detta kan redan ha skapats åt dig av en administratör.

  Användaren måste ha följande omfattningar:

  • repo

  • read:org

  • read:user

  • read:project

• Du behöver skrivåtkomst till de databaser du planerar att ändra.

• Du måste skapa en personlig åtkomsttoken (klassisk) för GitHub. Finkorniga personliga åtkomsttoken stöds inte.

  För mer information, se GitHub-dokumentationen: Hantera dina personliga åtkomsttoken.

• Organisation är obligatoriskt i GitHub-konfigurationen.

• Du behöver rollen Kan redigera i det utrymme där projektet finns för att utföra åtgärder för versionshantering.

• Innan du kan börja använda versionshantering måste du ställa in en konfiguration för att ansluta till GitHub med den GitHub-användare som du skapade.

  Ställa in konfiguration till GitHub

• När du har ställt in en koppling till GitHub kan du ansluta ett projekt till en databas.

  Ansluta ett projekt till en databas

Ställa in konfiguration till GitHub

Alla användare som vill arbeta med versionshantering måste ställa in en konfiguration för att ansluta till GitHub med ett GitHub-användarkonto.

Du kan konfigurera GitHub i Pipeline-projekt eller i dina användarprofilinställningar. Se till att du har förberett enligt Komma igång.

För att konfigurera GitHub i Pipeline-projekt:

1. Klicka på och sedan på GitHub-konfiguration.

2. Ställ in autentisering med din organisation och den personliga åtkomsttoken för GitHub som beskrivs i Komma igång.

3. Klicka på OK.

Du kan nu ansluta dina projekt till en databas.

Ansluta ett projekt till en databas

Du måste ansluta ett projekt till en databas innan du kan börja använda versionshantering. Se till att du har ställt in en koppling till GitHub.

1. I Pipeline-projekt klickar du på ... på ett projekt och väljer Anslut till versionshantering.

2. Välj vilken databas projektet ska associeras med.

3. Lägg till en bassökväg.

   Om du vill ansluta till ett befintligt projekt i GitHub måste du använda samma sökväg.

4. Du kan välja att checka in (commit) projektet och skicka (push) projektet till fjärrdatabasen efter anslutningen. Ange ett incheckningsmeddelande.

   Om du inte checkar in och skickar kommer en huvudgren att skapas i arbetsområdet, men inte i fjärrdatabasen.

5. Klicka på Anslut.

Projektet är nu anslutet till den valda databasen. Detta indikeras längst ner på projektkortet med , namnet på databasen och den aktuella grenen.

När du öppnar projektet kommer rubrikraden nu att innehålla en GitHub-meny med alternativ för versionshantering. Projektnamnet kommer också att kompletteras med namnet på den aktuella grenen.

Utveckla ett projekt med versionshantering

Du kan använda versionshantering med olika metoder:

• Arbeta direkt på huvudgrenen. Detta är främst lämpligt för en enskild utvecklare i ett projekt som vill hålla reda på ändringar, men kan också användas av en grupp utvecklare som arbetar synkroniserat.

• Arbeta med en förgreningsstrategi, där flera utvecklare kan bidra. Du kan också skapa grenar för att isolera nya funktioner eller ändringar från varandra.

Förenklat arbetsflöde för ett projekt med en enda utvecklare

Du kan arbeta direkt på huvudgrenen i ett projekt. Denna metod är enklare och innehåller färre åtgärder, men låter dig ändå hålla reda på ändringar. Om det finns mer än en utvecklare måste de vara noga med att vara synkroniserade.

När du har gjort ändringar i projektet som du vill tillämpa gör du bara en Commit and push.

Arbetsflöde för ett projekt med flera utvecklare

Detta arbetsflöde kan användas om det finns mer än en utvecklare som arbetar med ett projekt, eller om du vill isolera ändringar. Detta innebär att du skapar en utvecklingsgren som du kan dela med andra användare. Med detta arbetsflöde kan utvecklarna hålla reda på varandras ändringar och bestämma när ändringarna ska slås samman till huvudgrenen.

1. Skapa en ny gren

   Skapa en ny utvecklingsgren från huvudgrenen. Du kan dela grenen med fler användare.

2. Utveckla

   Gör alla nödvändiga ändringar i projektet.

   Anteckning om informationDatabasscheman och kopplingar underhålls inte i versionshanteringen.

3. Tillämpa fjärrändringar

   Tillämpa fjärrändringar från en annan gren till ditt arbetsområde för att se till att du är uppdaterad med ändringar från den andra grenen. Detta är till hjälp för att undvika eller mildra motstridiga ändringar.

   Om du har två grenar som innehåller ändringar som kan komma i konflikt är en lösning att:

   1. Checka in ändringar i båda arbetsområdena.

   2. Slå samman båda grenarna till main.

   3. Tillämpa fjärrändringar igen.

4. Checka in och skicka (Commit and push)

   Checka in och skicka dina ändringar till utvecklingsgrenen. Alla objekt kommer att skickas, så det är en bra idé att validera ditt projekt innan du checkar in det.

5. Skapa en pull-begäran och slå samman

   När du är klar med utvecklingen är det dags att slå samman ändringarna från arbetsområdet till huvudgrenen.

   Du kan skapa pull-begäran i projektets versionshantering, men sammanslagningen måste utföras i GitHub där du också kan ställa in godkännanden. För mer information, se GitHub-dokumentationen för pull-begäranden

Skapa en ny gren

1. I projektet klickar du på GitHub och väljer Skapa ny gren.

   Projektet måste vara anslutet till versionshantering. Du måste också ha behörighet till det utrymme där projektets målkoppling finns.

2. Välj att skapa en gren från huvudgrenen.

3. Ange ett namn för grenen.

4. Ange ett prefix som ska läggas till i alla scheman i projektet i Grenprefix för alla scheman. Detta gör att alla scheman kan namnges unikt för att undvika namnkonflikter.

5. Klicka på Skapa

En ny gren skapas från main och checkas ut från databasen. Grenen innehåller en ny version av projektet, med alla uppgifter i status Ny. Det vill säga, de är inte förberedda och innehåller inga data.

Tillämpa fjärrändringar

Du kan tillämpa ändringar från fjärrdatabasen till ditt arbetsområde. Detta kan vara ändringar som skapats utanför den integrerade versionshanteringen i Qlik Cloud, till exempel i GitHub eller av andra verktyg. Detta hjälper dig att undvika konflikter när du vill checka in och skicka dina ändringar till grenen.

1. I projektet klickar du på GitHub och väljer Tillämpa fjärrändringar.

   Dialogrutan Tillämpa fjärrändringar på arbetsområde visas om det finns ändringar.

2. Du kan nu välja vilka uppgifter du vill tillämpa ändringar för och inspektera ändringarna. För varje ändring kan du välja vilken version som ska användas, fjärrversionen eller versionen i ditt arbetsområde.

   Gör eventuella nödvändiga ändringar för att mappa kopplingar som skiljer sig mellan projektet och det importerade projektet.

   Till exempel kan det importerade projektet använda en källkoppling med namnet SQL1, medan detta projekt använder en liknande koppling med namnet SQL2. I det här fallet mappar du den importerade kopplingen till SQL2 i Ställ in kopplingar för de uppgifter som lagts till i originalversionen.

   Om ändringarna inkluderar källor över flera projekt och det refererade projektet är under versionshantering, finns en Gren-väljare tillgänglig för varje källa över flera projekt. Välj den gren som ska konsumeras. Om det refererade projektet inte är under versionshantering visas inte grenväljaren.

   Anteckning om informationNär du väljer en koppling att mappa kan du skapa en ny databaskoppling, men inte en SaaS-applikationskoppling.

3. Klicka på Tillämpa fjärrändringar

Du måste lägga till källkopplingar och målkopplingar om ändringarna inkluderar nya datauppgifter.

Checka in och skicka

Du kan checka in och skicka dina ändringar till grenen. Eftersom fjärrändringar som inte tillämpas på ditt arbetsområde kan skrivas över bör du utföra Tillämpa fjärrändringar innan du checkar in och skickar.

1. I projektet klickar du på GitHub och väljer Commit and push.

   Dialogrutan Commit and push visas om det finns ändringar.

2. Lägg till ett incheckningsmeddelande som kan hjälpa dig att hålla reda på vad som har ändrats.

3. Klicka på Commit and push

Skapa en pull-begäran

Skapa en pull-begäran (PR) för att slå samman ändringarna från arbetsområdet till huvudgrenen.

1. I projektet klickar du på GitHub på ett projekt och väljer Skapa pull-begäran.

   Dialogrutan Skapa pull-begäran visas.

2. Lägg till en titel och en beskrivning av pull-begäran.

   Du kan också välja att öppna pull-begäran i GitHub efter att den har skapats.

3. Klicka på Skapa pull-begäran.

Du kan nu ställa in godkännanden för pull-begäran och utföra sammanslagningen i GitHub.

Ta bort en gren

Du kan ta bort en gren när du har slagit samman dina ändringar till huvudgrenen.

1. I projektet klickar du på den gren som ska tas bort och väljer Ta bort gren.

   Du kan välja att ta bort fjärrgrenen i versionshanteringen också.

   Om det finns ändringar som inte har checkats in måste du bekräfta att dessa ändringar kommer att gå förlorade när du tar bort grenen.

Ta bort versionshantering för ett projekt

Du kan koppla bort ditt projekt från versionshantering. Om det finns befintliga grenar måste de tas bort innan du kan koppla bort projektet.

1. I Pipeline-projekt klickar du på ... på det projekt som ska kopplas bort och väljer Koppla bort från GitHub.

Importera ett projekt från versionshantering

Du kan importera ett projekt från versionshantering, till exempel om du vill granska en annan utvecklares projekt eller samarbeta i ett projekt. Att importera ett projekt från versionshantering gör det också möjligt att dela ett projekt med andra utrymmen eller klientorganisationer. Du kan dela en version av ett projekt med ett annat utrymme i samma klientorganisation, eller i en annan klientorganisation. Detta är användbart när du vill skapa två miljöer, till exempel en för utveckling och en för produktion."

Innan du importerar ett projekt

Innan du börjar importera ett projekt:

• Skapa alla nya kopplingar som du kommer att behöva om du importerar till en ny klientorganisation eller ett nytt utrymme.

• Om projektet använder SaaS-applikationskopplingar som ännu inte finns i klientorganisationen eller utrymmet måste du skapa kopplingarna och generera metadata innan du börjar importera.

• Om du importerar en pipeline över flera projekt måste du importera uppströmsprojekten först.

Importera ett projekt

Om projektet konsumerar uppgifter från andra projekt måste du mappa projekt och uppgifter såvida inte namnen på utrymmen och projekt är identiska.

1. I Data Integration > Projekt klickar du på Skapa ny och väljer Importera projekt från versionshantering.

2. Välj databasen och välj sedan grenen.

   Välj bassökvägen om det behövs och klicka på Visa projekt.

   Välj det projekt som ska importeras från listan.

   Klicka på Nästa.

3. Ställ in Projektegenskaper för det nya projektet.

   Du måste välja vilket utrymme projektet ska läggas till i under Utrymme.

   I Dataplattform kan du ändra projektets dataplattform och kopplingen till dataplattformen.

   Att ändra Koppling krävs om du importerade ett projekt från en annan klientorganisation, eller om du ändrade dataplattformen i föregående steg.

   Du kan ändra kopplingen till mellanlagringsområdet. Detta krävs om du importerade ett projekt från en annan klientorganisation, eller i vissa fall om du ändrade dataplattformen i föregående steg.

   Klicka på Nästa.

4. Ställ in Standardinställningar för projekt för det nya projektet.

   Du kan lägga till ett prefix till de datascheman som skapas i projektet i Prefix för alla scheman. Detta är användbart när det importerade projektet finns i samma molndatalager som det exporterade projektet.

   Du kan också ställa in ett standardnamn i Databasnamn. För Snowflake-projekt kan du ställa in ett standard-Datalagernamn, och för Databricks-projekt kan du ställa in ett standard-Katalognamn. Du kan använda projektets standardnamn för alla uppgiftstyper, eller ställa in namnet till standard eller ett anpassat namn för varje uppgiftstyp.

   Klicka på Nästa.

5. Ställ in Kopplingar och uppgiftsinställningar.

   Du kan ersätta de importerade källkopplingarna eller källorna över flera projekt. Detta krävs om du importerade ett projekt från en annan klientorganisation.

   När du mappar en källa över flera projekt till ett projekt som är under versionshantering finns en Gren-väljare tillgänglig. Välj den gren i det refererade projektet som ska konsumeras. Om det refererade projektet inte är under versionshantering visas inte grenväljaren. Om en källa över flera projekt är mappad till en gren som inte är huvudgrenen visas grennamnet inom parentes bredvid projektnamnet.

   I Valfria uppgiftsinställningar kan du också ändra uppgiftsinställningar som åsidosattes i det ursprungliga projektet.

6. När du är klar klickar du på Importera.

Projektet läggs till på startsidan för Dataintegrering.

Arbeta med ett projekt som importerats från versionshantering

Du arbetar på samma sätt som med vanliga versionshanterade projekt, med några få skillnader:

• Du kan bara byta till huvudgrenen, eller till en annan gren som importerades från versionshantering.

• Om du importerade från en gren kommer huvudgrenen att vara tom.

• Att ta bort ett projekt tar inte bort fjärrversionen.

Säkerhetsöverväganden

Se till att du upprätthåller synkroniserade säkerhetskonfigurationer mellan Qlik Talend Data Integration och GitHub.

• I Qlik Talend Data Integration baseras behörigheter på utrymmen som kan innehålla flera projekt. I GitHub baseras behörigheter på databaser som också kan innehålla flera projekt. Bästa praxis är att anpassa dem och ansluta alla projekt i ett utrymme till samma databas.

• Tänk på att Qlik Talend Data Integration och GitHub använder olika behörigheter och roller för användare.

Bästa praxis

Här är några allmänna bästa praxis när du arbetar med projekt som använder versionshantering.

• Lägg till en README-fil som beskriver databasen i GitHub. För mer information, se Om README-filer.

  Om du börjar med en tom databas kommer versionshanteringen i Qlik Talend Cloud att lägga till en tom README.md-fil automatiskt.

• I allmänhet bör du låta versionshanteringen i Qlik Talend Cloud hantera GitHub-databasen.

• Checka bara in projekt som är giltiga och testade för att köras.

  Om du lägger till projekt med Landing- eller Registered-datauppgifter som inte har förberetts eller transformerats är källkolumnerna ännu inte inkluderade. Källkolumner läggs till när uppgiften förbereds och transformeras.

• När du skapar en gren för replikeringsprojekt bör du vara medveten om att grenarna använder samma mål som standard. Detta innebär att körning av uppgifter i grenen kan skriva över data i huvudversionen. För att undvika dataförlust ändrar du målinställningarna i grenen så att de inte kommer i konflikt med huvudversionen.

• När du skapar en gren kan det finnas fjärrändringar som ännu inte har tillämpats på arbetsområdet. Tillämpa fjärrändringar antingen före eller efter att du skapar grenen, såvida du inte vill kassera fjärrändringarna.

• Att göra ändringar i samma dataset i två olika grenar kan resultera i sammanslagningskonflikter som är svåra att lösa och i att datasetet återskapas.

  Anteckning om informationNär ett dataset läggs till i en uppgift får det en intern identifierare. Interna identifierare används för att möjliggöra sömlös namnändring och andra metadataoperationer i en pipeline. När du skapar samma dataset i ett separat projekt eller en separat gren kommer den interna identifieraren att vara annorlunda, vilket kan orsaka en konflikt när de två grenarna slås samman. Detta kan leda till att förberedelseprocessen tar bort och återskapar ett dataset även om det har samma namn.

Arbeta i grenar

Du kan skapa ett projekt, designa det och när det är klart distribuera det till produktion med hjälp av MAIN-grenen. Versionen på MAIN motsvarar din produktionspipeline. Du bör aldrig redigera MAIN-grenen direkt efter den första distributionen.

Närhelst en utvecklare vill göra en ny ändring i ett projekt, till exempel lägga till en funktion eller korrigera en bugg, måste en ny gren skapas.

Utvecklare kan skapa valfritt antal grenar för sina utvecklingsbehov

• Använd schemaprefix för grenar för att undvika databaskonflikter medan du gör ändringarna.

• I en gren kan utvecklare göra valfritt antal ändringar och checka in och skicka (commit & push) så många gånger som krävs. Det rekommenderas att isolera varje ändring i en fristående, separat incheckning. Till exempel, om du gör en ändring i en transform-uppgift som också påverkar datamarknaden, se till att inkludera båda ändringarna i en enda incheckning

• Alla teammedlemmar bör använda Tillämpa fjärrändringar när som helst för att se till att deras MAIN är uppdaterad, särskilt innan de checkar in sina ändringar.

När utvecklare är klara med arbetet i sin gren kan de skapa en pull-begäran för kollegial granskning.

Efter granskning och godkännande från andra teammedlemmar kan du slå samman pull-begäran med MAIN-versionen i GitHub .

Slutligen använder du Tillämpa fjärrändringar i projektet för att hämta de godkända grenändringarna tillbaka till MAIN-grenen (produktion).

Arbeta i utrymmen

För större och kritiska distributioner rekommenderas det att använda dedikerade utrymmen för utveckling och produktion för att isolera ändringar och säkerställa pipeline-integritet. Använd dedikerade datakopplingar för källor och mål i varje utrymme.

• Produktion

  MAIN-grenen återspeglar vad som finns i produktion. Detta innebär att det bara finns en MAIN-version av ett projekt.

  Produktionen är isolerad i ett dedikerat datautrymme, till exempel PROD. Dedikerade kopplingar tilldelas produktionsutrymmet.

  Inga ändringar görs direkt i produktionsutrymmet/MAIN-grenen. Alla ändringar görs i andra utrymmen med dedikerade kopplingar, med hjälp av grenar.

  Du kan återanvända MAIN-versionen av ett befintligt projekt i GitHub. Skapa ett tomt projekt med samma namn som det befintliga projektet i GitHub. Detta hämtar den senaste tillgängliga versionen på MAIN-grenen för att börja redigera.

  Användare skapar en ny gren, gör sina ändringar, skapar pull-begäranden, slår samman och hämtar tillbaka till MAIN/Produktion.

• Utveckling

  Utvecklare kan isolera sina ändringar i ett dedikerat datautrymme, till exempel DEV. Dedikerade kopplingar tilldelas DEV-utrymmet.

  Ändringar isoleras med hjälp av grenar, vanligtvis en gren per utvecklare. Använd schemaprefix när en gren skapas för att undvika databaskonflikter medan du gör ändringarna.

• Granskning / kvalitetsacceptans

  Granskare beviljas åtkomst till utvecklingsutrymmen och kopplingar för att:.

  • Öppna och testa projektgrenar i Qlik Talend Cloud.

  • Godkänna pull-begäranden för att fortsätta med sammanslagning i GitHub.

  • Informera teammedlemmar när godkända ändringar kan hämtas tillbaka till MAIN/Produktion.

När du distribuerar de godkända ändringarna tillbaka till MAIN/Produktionsutrymmet måste du tilldela om kopplingar till produktionsutrymmets kopplingar.

Begränsningar

• Versionshantering stöds inte för projekt med Qlik Cloud (QVD) som mål.

• Det är inte möjligt att koppla bort eller ta bort ett projekt som använder versionshantering om det finns grenar. Grenarna måste tas bort innan du kan koppla bort eller ta bort projektet.

• Det är inte möjligt att byta namn på ett projekt som använder versionshantering.

• När du tar bort en klientorganisation kommer objekt som lagras med versionshantering i GitHub inte att tas bort. Du måste ta bort dessa objekt manuellt.

• om en databas används av många projekt, eller innehåller många filer som inte lagras i Qlik Talend Data Integration, kan prestandan försämras.

• Databasscheman och kopplingar underhålls inte i versionshanteringen.

• Finkorniga personliga åtkomsttoken för GitHub stöds inte.

• En gren (förutom huvudgrenen) kan endast användas av ett projekt per databas, även om två projekt finns i samma databas.

• Det är inte möjligt att tillämpa fjärrändringar från ett projekt som använder en annan målplattform. Till exempel, om du checkar in ändringar i ett projekt på Snowflake kan du inte tillämpa ändringarna på ett Databricks-projekt.