Zarządzanie projektami potoków za pomocą kontroli wersji

Możesz użyć kontroli wersji do zarządzania rozwojem projektu potoku i śledzenia zmian.

Podczas pracy z kontrolą wersji możesz zatwierdzać wersje projektów w trakcie projektowania. Pozwala to zobaczyć zmiany między dwiema wersjami projektu. Możesz również rozwijać swoje projekty danych, korzystając ze strategii rozgałęziania. Pozwala to na pracę nad odizolowaną wersją projektu w każdym obszarze roboczym lub gałęzi. Obszar roboczy może być współdzielony przez kilku użytkowników. Następnie możesz scalić swoje zmiany z obszaru roboczego do głównej gałęzi w celu wdrożenia na środowisko produkcyjne.

GitHub jest używany jako dostawca kontroli wersji. Implementacja jest zgodna z modelem współdzielonego repozytorium.

• GitHub Enterprise Cloud i GitHub Enterprise Server nie są obsługiwane.

• Więcej informacji na temat modelu współdzielonego repozytorium można znaleźć w sekcji Informacje o modelach programowania opartego na współpracy.

• Więcej informacji na temat Git i GitHub można znaleźć w sekcji Informacje o GitHub i Git.

• Kwestie bezpieczeństwa GitHub

  Qlik Talend Cloud obsługuje protokół bezpieczeństwa HTTPS i osobiste tokeny dostępu (PAT), co jest domyślnym trybem uwierzytelniania dla GitHub. Więcej informacji można znaleźć w sekcji Informacje o uwierzytelnianiu w GitHub.

Rozpoczęcie pracy

• Utwórz użytkownika w GitHub, którego dzierżawa może użyć do uzyskania dostępu do GitHub. Może on już być utworzony przez administratora.

  Użytkownik musi mieć następujące zakresy:

  • repo

  • read:org

  • read:user

  • read:project

• Potrzebujesz dostępu do zapisu w repozytoriach, które planujesz zmienić.

• Musisz utworzyć osobisty token dostępu GitHub (klasyczny). Szczegółowe osobiste tokeny dostępu nie są obsługiwane.

  Więcej informacji można znaleźć w dokumentacji GitHub: Zarządzanie osobistymi tokenami dostępu.

• Organizacja jest obowiązkowa w konfiguracji GitHub.

• Potrzebujesz roli Może edytować w przestrzeni, w której znajduje się projekt, aby wykonywać akcje kontroli wersji.

• Zanim zaczniesz korzystać z kontroli wersji, musisz skonfigurować połączenie z GitHub za pomocą utworzonego użytkownika GitHub.

  Konfigurowanie połączenia z GitHub

• Po skonfigurowaniu połączenia z GitHub możesz połączyć projekt z repozytorium.

  Łączenie projektu z repozytorium

Konfigurowanie połączenia z GitHub

Wszyscy użytkownicy, którzy chcą pracować z kontrolą wersji, muszą skonfigurować połączenie z GitHub przy użyciu konta użytkownika GitHub.

Możesz skonfigurować GitHub w sekcji Projekty potoków lub w ustawieniach profilu użytkownika. Upewnij się, że przygotowałeś się zgodnie z sekcją Rozpoczęcie pracy.

Aby skonfigurować GitHub w sekcji Projekty potoków:

1. Kliknij , a następnie Konfiguracja GitHub.

2. Skonfiguruj uwierzytelnianie przy użyciu swojej organizacji i osobistego tokenu dostępu GitHub opisanego w sekcji Rozpoczęcie pracy.

3. Kliknij OK.

Możesz teraz połączyć swoje projekty z repozytorium.

Łączenie projektu z repozytorium

Musisz połączyć projekt z repozytorium, zanim zaczniesz korzystać z kontroli wersji. Upewnij się, że skonfigurowałeś połączenie z GitHub.

1. W sekcji Projekty potoków kliknij ... na projekcie i wybierz Połącz z kontrolą wersji.

2. Wybierz repozytorium, z którym chcesz powiązać projekt.

3. Dodaj ścieżkę katalogu bazowego.

   Jeśli chcesz połączyć się z istniejącym projektem w GitHub, musisz użyć tej samej ścieżki.

4. Możesz wybrać zatwierdzenie projektu i wypchnięcie go do zdalnego repozytorium po połączeniu. Wprowadź komunikat zatwierdzenia.

   Jeśli nie zatwierdzisz i nie wypchniesz, główna gałąź zostanie utworzona w obszarze roboczym, ale nie w zdalnym repozytorium.

5. Kliknij Połącz.

Projekt jest teraz połączony z wybranym repozytorium. Jest to wskazane na dole karty projektu za pomocą , nazwy repozytorium i bieżącej gałęzi.

Po otwarciu projektu wiersz tytułu będzie teraz zawierał menu GitHub z opcjami kontroli wersji. Do nazwy projektu zostanie również dołączona nazwa bieżącej gałęzi.

Rozwijanie projektu z kontrolą wersji

Możesz używać kontroli wersji z różnymi podejściami:

• Praca bezpośrednio na głównej gałęzi. Jest to odpowiednie głównie dla pojedynczego programisty w projekcie, który chce śledzić zmiany, ale może być również używane przez grupę programistów pracujących w synchronizacji.

• Praca ze strategią rozgałęziania, w której wielu programistów może wnosić wkład. Możesz również tworzyć gałęzie, aby izolować od siebie nowe cechy lub zmiany.

Uproszczony przepływ pracy dla projektu z jednym programistą

Możesz pracować bezpośrednio na głównej gałęzi projektu. To podejście jest prostsze i zawiera mniej operacji, ale nadal pozwala śledzić zmiany. Jeśli jest więcej niż jeden programista, muszą oni uważać, aby być zsynchronizowani.

Po wprowadzeniu zmian w projekcie, które chcesz zastosować, po prostu wykonaj Zatwierdź i wypchnij.

Przepływ pracy dla projektu z wieloma programistami

Ten przepływ pracy może być używany, jeśli nad projektem pracuje więcej niż jeden programista lub jeśli chcesz odizolować zmiany. Obejmuje to utworzenie gałęzi programistycznej, którą można udostępnić innym użytkownikom. Dzięki temu przepływowi pracy programiści mogą śledzić nawzajem swoje zmiany i decydować, kiedy scalić zmiany z główną gałęzią.

1. Utwórz nową gałąź

   Utwórz nową gałąź programistyczną z głównej gałęzi. Możesz udostępnić gałąź większej liczbie użytkowników.

2. Rozwijaj

   Wprowadź wszystkie wymagane zmiany w projekcie.

   InformacjaSchematy baz danych i połączenia nie są utrzymywane w kontroli wersji.

3. Zastosuj zdalne zmiany

   Zastosuj zdalne zmiany z innej gałęzi do swojego obszaru roboczego, aby upewnić się, że jesteś na bieżąco ze zmianami z innej gałęzi. Jest to pomocne w unikaniu lub łagodzeniu konfliktów zmian.

   Jeśli masz dwie gałęzie zawierające zmiany, które mogą być w konflikcie, obejściem jest:

   1. Zatwierdzenie zmian w obu obszarach roboczych.

   2. Scalenie obu gałęzi z główną.

   3. Ponowne zastosowanie zdalnych zmian.

4. Zatwierdź i wypchnij

   Zatwierdź i wypchnij swoje zmiany do gałęzi programistycznej. Wszystkie obiekty zostaną wypchnięte, więc dobrym pomysłem jest zweryfikowanie projektu przed jego zatwierdzeniem.

5. Utwórz żądanie ściągnięcia i scal

   Kiedy będziesz gotowy z rozwojem, nadszedł czas, aby scalić zmiany z obszaru roboczego do głównej gałęzi.

   Możesz utworzyć żądanie ściągnięcia w kontroli wersji projektu, ale scalenie musi zostać wykonane w GitHub, gdzie możesz również skonfigurować zatwierdzenia. Więcej informacji można znaleźć w Dokumentacji żądań ściągnięcia GitHub

Tworzenie nowej gałęzi

1. W projekcie kliknij GitHub i wybierz Utwórz nową gałąź.

   Projekt musi być połączony z kontrolą wersji. Musisz również mieć uprawnienia do przestrzeni, w której znajduje się docelowe połączenie projektu.

2. Wybierz utworzenie gałęzi z głównej gałęzi.

3. Wprowadź nazwę dla gałęzi.

4. Ustaw prefiks, który ma zostać dodany do wszystkich schematów w projekcie w Prefiks gałęzi dla wszystkich schematów. Pozwala to na unikalne nazwanie wszystkich schematów, aby uniknąć konfliktów nazw.

5. Kliknij Utwórz

Nowa gałąź jest tworzona z głównej i pobierana z repozytorium. Gałąź zawiera nową wersję projektu, ze wszystkimi zadaniami w statusie Nowe. Oznacza to, że nie są one przygotowane i nie zawierają żadnych danych.

Stosowanie zdalnych zmian

Możesz zastosować zmiany ze zdalnego repozytorium do swojego obszaru roboczego. Mogą to być zmiany utworzone poza zintegrowaną kontrolą wersji Qlik Cloud, na przykład w GitHub lub przez inne narzędzia. Pomaga to uniknąć konfliktów, gdy chcesz zatwierdzić i wypchnąć swoje zmiany do gałęzi.

1. W projekcie kliknij GitHub i wybierz Zastosuj zdalne zmiany.

   Okno dialogowe Zastosuj zdalne zmiany do obszaru roboczego zostanie wyświetlone, jeśli zostaną znalezione zmiany.

2. Możesz teraz wybrać, dla których zadań zastosować zmiany i sprawdzić zmiany. Dla każdej zmiany możesz wybrać, której wersji użyć: zdalnej czy wersji w Twoim obszarze roboczym.

   Wprowadź wszelkie wymagane zmiany w celu zamapowania połączeń, które różnią się między projektem a zaimportowanym projektem.

   Na przykład zaimportowany projekt może używać połączenia źródłowego o nazwie SQL1, podczas gdy ten projekt używa podobnego połączenia o nazwie SQL2. W takim przypadku zamapuj zaimportowane połączenie na SQL2 w Ustaw połączenia dla zadań dodanych w oryginalnej wersji.

   Jeśli zmiany obejmują źródła międzyprojektowe, a projekt, do którego następuje odwołanie, znajduje się pod kontrolą wersji, dla każdego źródła międzyprojektowego dostępny jest selektor Gałąź. Wybierz gałąź do wykorzystania. Jeśli projekt, do którego następuje odwołanie, nie znajduje się pod kontrolą wersji, selektor gałęzi nie jest wyświetlany.

   InformacjaPodczas wybierania połączenia do zamapowania możesz utworzyć nowe połączenie z bazą danych, ale nie połączenie z aplikacją SaaS.

3. Kliknij Zastosuj zdalne zmiany

Musisz dodać połączenia źródłowe i połączenia docelowe, jeśli zmiany obejmują nowe zadania danych.

Zatwierdzanie i wypychanie

Możesz zatwierdzić i wypchnąć swoje zmiany do gałęzi. Ponieważ zdalne zmiany, które nie zostały zastosowane w Twoim obszarze roboczym, mogą zostać nadpisane, powinieneś wykonać Zastosuj zdalne zmiany przed zatwierdzeniem i wypchnięciem.

1. W projekcie kliknij GitHub i wybierz Zatwierdź i wypchnij.

   Okno dialogowe Zatwierdź i wypchnij zostanie wyświetlone, jeśli zostaną znalezione zmiany.

2. Dodaj komunikat zatwierdzenia, który pomoże Ci śledzić, co się zmieniło.

3. Kliknij Zatwierdź i wypchnij

Tworzenie żądania ściągnięcia

Utwórz żądanie ściągnięcia (PR), aby scalić zmiany z obszaru roboczego do głównej gałęzi.

1. W projekcie kliknij GitHub na projekcie i wybierz Utwórz żądanie ściągnięcia.

   Zostanie wyświetlone okno dialogowe Utwórz żądanie ściągnięcia.

2. Dodaj tytuł i opis żądania ściągnięcia.

   Możesz również wybrać otwarcie żądania ściągnięcia w GitHub po jego utworzeniu.

3. Kliknij Utwórz żądanie ściągnięcia.

Możesz teraz skonfigurować zatwierdzenia dla żądania ściągnięcia i wykonać scalenie w GitHub.

Usuwanie gałęzi

Możesz usunąć gałąź po scaleniu swoich zmian z główną gałęzią.

1. W projekcie kliknij na gałąź do usunięcia i wybierz Usuń gałąź.

   Możesz również wybrać usunięcie zdalnej gałęzi w kontroli wersji.

   Jeśli istnieją niezatwierdzone zmiany, będziesz musiał potwierdzić, że te zmiany zostaną utracone podczas usuwania gałęzi.

Usuwanie kontroli wersji dla projektu

Możesz odłączyć swój projekt od kontroli wersji. Jeśli istnieją gałęzie, muszą one zostać usunięte, zanim będzie można odłączyć projekt.

1. W sekcji Projekty potoków kliknij ... na projekcie do odłączenia i wybierz Odłącz od GitHub.

Importowanie projektu z kontroli wersji

Możesz zaimportować projekt z kontroli wersji, na przykład jeśli chcesz przejrzeć projekt innego programisty lub współpracować nad projektem. Importowanie projektu z kontroli wersji umożliwia również udostępnianie projektu innym przestrzeniom lub dzierżawom. Możesz udostępnić wersję projektu innej przestrzeni w tej samej dzierżawie lub w innej dzierżawie. Jest to przydatne, gdy chcesz utworzyć dwa środowiska, na przykład jedno do rozwoju, a drugie do produkcji."

Przed zaimportowaniem projektu

Zanim zaczniesz importować projekt:

• Utwórz wszystkie nowe połączenia, których będziesz potrzebować, jeśli importujesz do nowej dzierżawy lub przestrzeni.

• Jeśli projekt używa połączeń z aplikacjami SaaS, które jeszcze nie istnieją w dzierżawie lub przestrzeni, musisz utworzyć połączenia i wygenerować metadane przed rozpoczęciem importowania.

• Jeśli importujesz potok międzyprojektowy, musisz najpierw zaimportować projekty nadrzędne.

Importowanie projektu

Jeśli projekt wykorzystuje zadania z innych projektów, musisz zamapować projekty i zadania, chyba że nazwy przestrzeni i projektów są identyczne.

1. W sekcji Data Integration > Projekty kliknij Utwórz nowy i wybierz Importuj projekt z kontroli wersji.

2. Wybierz repozytorium, a następnie wybierz gałąź.

   Wybierz ścieżkę katalogu bazowego, jeśli to konieczne, i kliknij Pokaż projekty.

   Wybierz projekt do zaimportowania z listy.

   Kliknij Dalej.

3. Ustaw Właściwości projektu dla nowego projektu.

   Musisz wybrać przestrzeń, do której chcesz dodać projekt w Przestrzeń.

   W Platforma danych możesz zmienić platformę danych projektu i połączenie z platformą danych.

   Zmiana Połączenie jest wymagana, jeśli zaimportowałeś projekt z innej dzierżawy lub jeśli zmieniłeś platformę danych w poprzednim kroku.

   Możesz zmienić połączenie z obszarem przejściowym. Jest to wymagane, jeśli zaimportowałeś projekt z innej dzierżawy lub w niektórych przypadkach, jeśli zmieniłeś platformę danych w poprzednim kroku.

   Kliknij Dalej.

4. Ustaw Domyślne ustawienia projektu dla nowego projektu.

   Możesz dodać prefiks do schematów danych, które są tworzone w projekcie w Prefiks dla wszystkich schematów. Jest to przydatne, gdy zaimportowany projekt znajduje się w tej samej hurtowni danych w chmurze co wyeksportowany projekt.

   Możesz również ustawić domyślną nazwę w Nazwa bazy danych. Dla projektów Snowflake możesz ustawić domyślną Nazwa hurtowni danych, a dla projektów Databricks możesz ustawić domyślną Nazwa katalogu. Możesz użyć domyślnej nazwy projektu dla wszystkich typów zadań lub ustawić nazwę na domyślną lub niestandardową dla każdego typu zadania.

   Kliknij Dalej.

5. Ustaw Połączenia i ustawienia zadań.

   Możesz zastąpić zaimportowane połączenia źródłowe lub źródła międzyprojektowe. Jest to wymagane, jeśli zaimportowałeś projekt z innej dzierżawy.

   Podczas mapowania źródła międzyprojektowego na projekt, który znajduje się pod kontrolą wersji, dostępny jest selektor Gałąź. Wybierz gałąź projektu, do którego następuje odwołanie, do wykorzystania. Jeśli projekt, do którego następuje odwołanie, nie znajduje się pod kontrolą wersji, selektor gałęzi nie jest wyświetlany. Jeśli źródło międzyprojektowe jest zamapowane na gałąź inną niż główna, nazwa gałęzi jest wyświetlana w nawiasach obok nazwy projektu.

   W Opcjonalne ustawienia zadań możesz również zmienić ustawienia zadań, które zostały nadpisane w oryginalnym projekcie.

6. Kiedy będziesz gotowy, kliknij Importuj.

Projekt zostaje dodany do strony głównej Integracja danych.

Praca nad projektem zaimportowanym z kontroli wersji

Pracujesz w taki sam sposób, jak w przypadku zwykłych projektów z kontrolą wersji, z kilkoma różnicami:

• Możesz przełączyć się tylko na główną gałąź lub na inną gałąź, która została zaimportowana z kontroli wersji.

• Jeśli zaimportowałeś z gałęzi, główna gałąź będzie pusta.

• Usunięcie projektu nie spowoduje usunięcia zdalnej wersji.

Kwestie bezpieczeństwa

Upewnij się, że utrzymujesz zsynchronizowane konfiguracje zabezpieczeń między Qlik Talend Data Integration a GitHub.

• W Qlik Talend Data Integration uprawnienia opierają się na przestrzeniach, które mogą zawierać kilka projektów. W GitHub uprawnienia opierają się na repozytoriach, które również mogą zawierać kilka projektów. Najlepszą praktyką jest ich dostosowanie i połączenie wszystkich projektów w jednej przestrzeni z tym samym repozytorium.

• Pamiętaj, że Qlik Talend Data Integration i GitHub używają różnych uprawnień i ról dla użytkowników.

Najlepsze praktyki

Oto kilka ogólnych najlepszych praktyk podczas pracy z projektami korzystającymi z kontroli wersji.

• Dodaj plik README, który opisuje repozytorium w GitHub. Więcej informacji można znaleźć w sekcji Informacje o plikach README.

  Jeśli zaczniesz od pustego repozytorium, kontrola wersji Qlik Talend Cloud automatycznie doda pusty plik README.md.

• Ogólnie rzecz biorąc, powinieneś pozwolić kontroli wersji Qlik Talend Cloud zarządzać repozytorium GitHub.

• Zatwierdzaj tylko projekty, które są prawidłowe i przetestowane pod kątem działania.

  Jeśli dodasz projekty z zadaniami danych Landing lub Registered, które nie zostały przygotowane lub przekształcone, kolumny źródłowe nie są jeszcze uwzględnione. Kolumny źródłowe są dodawane, gdy zadanie jest przygotowywane i przekształcane.

• Podczas tworzenia gałęzi dla projektów replikacji należy pamiętać, że gałęzie domyślnie używają tego samego celu. Oznacza to, że uruchamianie zadań w gałęzi może nadpisać dane głównej wersji. Aby uniknąć utraty danych, zmień ustawienia docelowe w gałęzi, aby nie kolidowały z główną wersją.

• Podczas tworzenia gałęzi mogą wystąpić zdalne zmiany, które nie zostały jeszcze zastosowane w obszarze roboczym. Zastosuj zdalne zmiany przed lub po utworzeniu gałęzi, chyba że chcesz odrzucić zdalne zmiany.

• Wprowadzanie zmian w tym samym zestawie danych w dwóch różnych gałęziach może prowadzić do konfliktów scalania, które są trudne do rozwiązania, oraz do ponownego utworzenia zestawu danych.

  InformacjaGdy zestaw danych jest dodawany do zadania, otrzymuje wewnętrzny identyfikator. Wewnętrzne identyfikatory są używane w celu umożliwienia płynnej zmiany nazwy i innych operacji na metadanych w potoku. Podczas tworzenia tego samego zestawu danych w oddzielnym projekcie lub gałęzi wewnętrzny identyfikator będzie inny, co może spowodować konflikt podczas scalania dwóch gałęzi. Może to spowodować, że proces przygotowania usunie i ponownie utworzy zestaw danych, nawet jeśli ma on tę samą nazwę.

Praca w gałęziach

Możesz utworzyć projekt, zaprojektować go, a gdy będzie gotowy, wdrożyć go na środowisko produkcyjne za pomocą gałęzi MAIN. Wersja na MAIN odpowiada Twojemu potokowi produkcyjnemu. Nigdy nie powinieneś edytować gałęzi MAIN bezpośrednio po pierwszym wdrożeniu.

Za każdym razem, gdy programista chce wprowadzić nową zmianę w projekcie, taką jak dodanie cechy lub poprawienie błędu, należy utworzyć nową gałąź.

Programiści mogą tworzyć dowolną liczbę gałęzi dla swoich potrzeb programistycznych

• Używaj prefiksów schematów dla gałęzi, aby uniknąć konfliktów w bazie danych podczas wprowadzania zmian.

• W gałęzi programiści mogą wprowadzać dowolną liczbę zmian oraz zatwierdzać i wypychać je tyle razy, ile to konieczne. Zaleca się izolowanie każdej zmiany w samodzielnym, oddzielnym zatwierdzeniu. Na przykład, jeśli wprowadzisz zmianę w zadaniu transformacji, która wpływa również na hurtownię danych, upewnij się, że obie zmiany zostały uwzględnione w jednym zatwierdzeniu

• Wszyscy członkowie zespołu powinni w dowolnym momencie używać Zastosuj zdalne zmiany, aby upewnić się, że ich MAIN jest aktualny, zwłaszcza przed zatwierdzeniem swoich zmian.

Gdy programiści zakończą pracę w swojej gałęzi, mogą utworzyć żądanie ściągnięcia do wzajemnej weryfikacji.

Po weryfikacji i zatwierdzeniu przez innych członków zespołu możesz scalić żądanie ściągnięcia z wersją MAIN w GitHub .

Na koniec użyj Zastosuj zdalne zmiany w projekcie, aby ściągnąć zatwierdzone zmiany z gałęzi z powrotem do gałęzi MAIN (produkcja).

Praca w przestrzeniach

W przypadku większych i krytycznych wdrożeń zaleca się korzystanie z dedykowanych przestrzeni do rozwoju i produkcji, aby odizolować zmiany i zapewnić integralność potoku. Używaj dedykowanych połączeń danych dla źródeł i celów w każdej przestrzeni.

• Produkcja

  Gałąź MAIN odzwierciedla to, co jest na produkcji. Oznacza to, że istnieje tylko jedna wersja MAIN projektu.

  Produkcja jest odizolowana w dedykowanej przestrzeni danych, na przykład PROD. Dedykowane połączenia są przypisane do przestrzeni produkcyjnej.

  Żadne zmiany nie są wprowadzane bezpośrednio w przestrzeni produkcyjnej/gałęzi MAIN. Wszystkie zmiany są wprowadzane w innych przestrzeniach z dedykowanymi połączeniami, przy użyciu gałęzi.

  Możesz ponownie użyć wersji MAIN istniejącego projektu w GitHub. Utwórz pusty projekt o tej samej nazwie co istniejący projekt w GitHub. Spowoduje to pobranie najnowszej dostępnej wersji z gałęzi MAIN w celu rozpoczęcia edycji.

  Użytkownicy tworzą nową gałąź, wprowadzają swoje zmiany, tworzą żądania ściągnięcia, scalają i ściągają z powrotem do MAIN/Produkcja.

• Rozwój

  Programiści mogą izolować swoje zmiany w dedykowanej przestrzeni danych, na przykład DEV. Dedykowane połączenia są przypisane do przestrzeni DEV.

  Zmiany są izolowane za pomocą gałęzi, zazwyczaj jedna gałąź na programistę. Używaj prefiksów schematów podczas tworzenia gałęzi, aby uniknąć konfliktów w bazie danych podczas wprowadzania zmian.

• Przegląd / akceptacja jakości

  Recenzenci otrzymują dostęp do przestrzeni programistycznych i połączeń w celu:.

  • Otwierania i testowania gałęzi projektów w Qlik Talend Cloud.

  • Zatwierdzania żądań ściągnięcia w celu kontynuowania scalania w GitHub.

  • Informowania członków zespołu, kiedy zatwierdzone zmiany mogą zostać ściągnięte z powrotem do MAIN/Produkcja.

Podczas wdrażania zatwierdzonych zmian z powrotem do przestrzeni MAIN/Produkcja musisz ponownie przypisać połączenia do połączeń przestrzeni produkcyjnej.

Ograniczenia

• Kontrola wersji nie jest obsługiwana dla projektów z Qlik Cloud (QVD) jako celem.

• Nie jest możliwe odłączenie lub usunięcie projektu korzystającego z kontroli wersji, jeśli istnieją gałęzie. Gałęzie muszą zostać usunięte, zanim będzie można odłączyć lub usunąć projekt.

• Nie jest możliwa zmiana nazwy projektu korzystającego z kontroli wersji.

• Po usunięciu dzierżawy obiekty przechowywane z kontrolą wersji w GitHub nie zostaną usunięte. Musisz usunąć te obiekty ręcznie.

• Jeśli repozytorium jest używane przez wiele projektów lub zawiera wiele plików, które nie są przechowywane w Qlik Talend Data Integration, wydajność może ulec pogorszeniu.

• Schematy baz danych i połączenia nie są utrzymywane w kontroli wersji.

• Szczegółowe osobiste tokeny dostępu GitHub nie są obsługiwane.

• Gałąź (z wyjątkiem głównej gałęzi) może być używana tylko przez jeden projekt na repozytorium, nawet jeśli dwa projekty znajdują się w tym samym repozytorium.

• Nie jest możliwe zastosowanie zdalnych zmian z projektu, który używa innej platformy docelowej. Na przykład, jeśli zatwierdzisz zmiany w projekcie na Snowflake, nie możesz zastosować zmian do projektu Databricks.