Zarządzanie projektami przy użyciu kontroli wersji

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

Podczas pracy z kontrolą wersji można zatwierdzać wersje projektów w trakcie ich projektowania. Umożliwia to zobaczenie zmian między dwiema wersjami projektu. Projekty danych można również rozwijać przy użyciu strategii rozgałęziania. Pozwala to na pracę nad odizolowaną wersją projektu w poszczególnych obszarach roboczych, czyli gałęziach. Obszar roboczy może być współdzielony przez kilku użytkowników. Następnie można scalić zmiany z obszaru roboczego do głównej gałęzi w celu wdrożenia do produkcji.

Jako dostawca kontroli wersji jest używany GitHub.

Pierwsze kroki

• Utwórz użytkownika w usłudze GitHub, którego dzierżawa będzie mogła używać do uzyskiwania dostępu do usługi GitHub. Mógł on już zostać 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 zmieniać.

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

  Więcej informacji można znaleźć w dokumentacji GitHub: Managing your personal access tokens.

• Organizacja jest obowiązkowa w konfiguracji GitHub.

• Do wykonywania działań kontroli wersji jest wymagana rola Może edytować w przestrzeni, w której znajduje się projekt.

• Przed rozpoczęciem korzystania z kontroli wersji należy skonfigurować połączenie z GitHub za pomocą utworzonego użytkownika GitHub.

  Konfiguracja połączenia z serwisem GitHub

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

  Połączenie projektu z repozytorium

Konfiguracja połączenia z serwisem GitHub

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

GitHub można skonfigurować w sekcji Projekty. Sprawdź, czy wszystko zostało przygotowane zgodnie z Pierwsze kroki.

1. Kliknij , a następnie Konfiguracja GitHub.

2. Skonfiguruj uwierzytelnianie przy użyciu swojej organizacji i osobistego tokena dostępu GitHub opisanego w Pierwsze kroki.

3. Kliknij przycisk OK.

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

Połączenie projektu z repozytorium

Przed rozpoczęciem korzystania z kontroli wersji należy połączyć projekt z repozytorium. Sprawdź, czy zostało skonfigurowane połączenie z GitHub.

1. W oknie Projekty kliknij ... na projekcie i wybierz opcję Połącz z kontrolą wersji.

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

3. Dodaj ścieżkę do podstawowego katalogu.

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

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

   Jeżeli nie zatwierdzisz i nie wypchniesz zmian , gałąź główna 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 przy użyciu , nazwy repozytorium i bieżącej gałęzi.

Po otwarciu projektu wiersz tytułowy 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

Kontroli wersji można używać na różne sposoby:

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

• Praca ze strategią rozgałęziania, w której może uczestniczyć wielu programistów. Można również tworzyć gałęzie, aby odizolować nowe cechy lub zmiany.

Uproszczony przepływ pracy nad projektem jednego dewelopera

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 deweloper, muszą oni uważać, aby pracować synchronicznie.

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

Przepływ pracy w przypadku projektu wielu deweloperów

Ten przepływ pracy może być używany, jeśli nad projektem pracuje więcej niż jeden deweloper lub jeśli chcesz odizolować zmiany. Obejmuje to utworzenie gałęzi rozwojowej, którą można udostępniać innym użytkownikom. Dzięki takiemu przepływowi pracy deweloperzy mogą śledzić wzajemnie zmiany i decydować, kiedy scalić je z główną gałęzią.

1. Tworzenie nowej gałęzi

   Utwórz nową gałąź rozwojową z gałęzi głównej. Gałąź można udostępnić większej liczbie użytkowników.

2. Rozwój

   Dokonaj wszystkich wymaganych zmian w projekcie.

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

3. Stosowanie zmian zdalnych

   Zastosuj zdalne zmiany z innej gałęzi do swojego obszaru roboczego, aby być na bieżąco ze zmianami z drugiej gałęzi. Jest to pomocne w unikaniu lub godzeniu sprzecznych zmian.

   Jeśli masz dwie gałęzie zawierające zmiany, które mogą ze sobą kolidować, można to obejść następująco:

   1. Wprowadź zmiany w obu obszarach roboczych.

   2. Połącz obie gałęzie z główną.

   3. Zastosuj ponownie zmiany zdalne.

4. Zatwierdzenie i wypchanie

   Zatwierdź i wypchnij zmiany do gałęzi deweloperskiej. Wszystkie obiekty zostaną wypchnięte, więc dobrze jest sprawdzić poprawność projektu przed jego zatwierdzeniem.

5. Otwieranie żądania pobrania i scalanie

   Kiedy efekt prac rozwojowych jest gotowy, nadszedł czas, aby scalić zmiany z obszaru roboczego do głównej gałęzi. Scalenie gałęzi rozwojowej z gałęzią główną musi zostać wykonane w serwisie GitHub przez otwarcie żądania pobrania. Można skonfigurować zatwierdzanie scalenia gałęzi z gałęzią główną. Aby uzyskać więcej informacji, zobacz dokumentację żądań pobierania GitHub

Tworzenie nowej gałęzi

1. W sekcji Projekty kliknij ... na projekcie i wybierz Utwórz nową gałąź.

   Projekt musi być połączony z kontrolą wersji.

2. Wybierz, aby utworzyć gałąź z gałęzi głównej.

3. Wprowadź nazwę gałęzi.

4. Ustaw prefiks dodawany do wszystkich schematów w projekcie w Prefiks gałęzi dla wszystkich schematów. Umożliwia to stosowanie unikatowych nazw dla wszystkich schematów w celu uniknięcia konfliktów nazw.

5. Kliknij Utwórz.

Nowa gałąź jest tworzona z głównej i wyewidencjonowywana z repozytorium. Gałąź zawiera nową wersję projektu, a wszystkie zadania mają status Nowe. Oznacza to, że nie są one przygotowane i nie zawierają żadnych danych.

Stosowanie zmian zdalnych

Zmiany ze zdalnego repozytorium można zastosować w obszarze roboczym. Mogą to być zmiany utworzone poza zintegrowaną kontrolą wersji Qlik Cloud, na przykład w GitHub lub za pomocą innych narzędzi. Pomaga to uniknąć konfliktów podczas zatwierdzania i wypychania zmian do gałęzi.

1. W sekcji Projekty kliknij ... na projekcie i wybierz Zastosuj zmiany zdalne.

   W przypadku znalezienia zmian jest wyświetlane okno dialogowe Zastosuj zdalne zmiany do obszaru roboczego.

2. Można teraz wybrać zadania, w których mają zostać zastosowane zmiany, i sprawdzić wprowadzone zmiany. W przypadku każdej zmiany można wybrać wersję do użycia: wersję zdalną lub wersję w obszarze roboczym.

3. Kliknij Zastosuj zmiany zdalne.

Jeśli zmiany obejmują nowe zadania danych, należy dodać połączenia źródłowe i połączenia docelowe.

Zatwierdzanie i wypychanie

Możesz zatwierdzić i wypchnąć zmiany do gałęzi. Ponieważ zmiany zdalne, które nie zostały zastosowane do obszaru roboczego, mogą zostać nadpisane, przed zatwierdzeniem i wypchnięciem należy zastosować zmiany zdalne.

1. W sekcji Projekty kliknij ... na projekcie i wybierz Zatwierdź i wypchnij.

   W przypadku znalezienia zmian jest wyświetlane okno dialogowe Zatwierdź i wypchnij.

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

3. Kliknij Zatwierdź i wypchnij.

Usuwanie gałęzi

Gałąź można usunąć po scaleniu zmian z gałęzią główną.

1. W oknie Projekty kliknij ... na gałęzi do usunięcia i wybierz opcję Usuń gałąź.

   Można również usunąć zdalną gałąź w kontroli wersji.

   Jeśli istnieją niezatwierdzone zmiany, należy potwierdzić, że zostaną one utracone podczas usuwania gałęzi.

Usuwanie kontroli wersji dla projektu

Projekt można odłączyć od kontroli wersji. Jeśli istnieją gałęzie, muszą one zostać usunięte przed odłączeniem projektu.

1. W sekcji Projekty kliknij ... na projekcie do odłączenia i wybierz opcję Odłącz od GitHub.

Współdzielenie projektu z innymi przestrzeniami lub dzierżawami

Wersję projektu można udostępnić innej przestrzeni w tej samej lub w innej dzierżawie. Jest to przydatne, gdy chcesz utworzyć dwa środowiska, na przykład jedno do rozwoju, a drugie do produkcji.

1. Utwórz nowy projekt o takiej samej nazwie jak pierwotny.

   Ustaw to samo zastosowanie i typ platformy. Można korzystać z różnych połączeń.

2. Połącz nowy projekt z tym samym repozytorium i ścieżką katalogu podstawowego co oryginalny projekt.

   InformacjaNie wybieraj opcji Zatwierdź i wypchnij.

3. Jeśli połączenie platformy wskazuje na ten sam cel co oryginalny projekt, zmień bazę danych lub schematy zadań danych. Jednym ze sposobów zmiany schematów wszystkich zadań jest zmiana Prefiksu dla wszystkich schematów w ustawieniach Metadanych projektu przed zastosowaniem zmian zdalnych. Dzięki temu wszystkie zadania będą tworzone z tym prefiksem.

4. Zastosuj zmiany zdalne, wybierając wszystkie pliki.

5. Dodaj brakujące połączenia źródłowe dla wszystkich zadań umieszczania.

   Kliknij Wybierz źródło danych w zadaniu umieszczania, wybierz połączenie i kliknij Zapisz.

   InformacjaPołączenie musi pochodzić z tego samego typu źródła i wskazywać na tabele o takich samych nazwach jak w oryginalnym projekcie.

6. Dodaj brakujące połączenia źródłowe i docelowe dla wszystkich zadań umieszczania.

Spowoduje to utworzenie kolejnego obszaru roboczego. Zmiany w projekcie można wprowadzać w jednym z obszarów roboczych, a następnie użyć opcji Zastosuj zmiany zdalne, aby zsynchronizować drugi obszar roboczy.

Względy bezpieczeństwa

Utrzymuj zsynchronizowane konfiguracje zabezpieczeń między Qlik Talend Data Integration a GitHub.

• W Qlik Talend Data Integration uprawnienia są oparte na przestrzeniach, które mogą zawierać kilka projektów. W GitHub uprawnienia są oparte na repozytoriach, które także mogą zawierać kilka projektów. Najlepszą praktyką jest ich zharmonizowanie i połączenie wszystkich projektów w jednej przestrzeni z tym samym repozytorium.

• Należy pamiętać, że Qlik Talend Data Integration i GitHub używają różnych uprawnień i ról dla użytkowników.

Najlepsze praktyki

Oto kilka najlepszych praktyk podczas pracy z projektami wykorzystującymi kontrolę wersji.

• Dodaj plik README opisujący repozytorium w serwisie GitHub. Więcej informacji zawiera temat About READMEs.

• Zatwierdzaj tylko te projekty, które są ważne i przetestowane pod kątem uruchomienia.

  W przypadku dodawania projektów z zadaniami umieszczania danych lub zarejestrowanych danych, które nie zostały przygotowane lub przekształcone, kolumny źródłowe nie są jeszcze uwzględnione. Kolumny źródłowe są dodawane po przygotowaniu i przekształceniu zadania.

• 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 zadania uruchomione w gałęzi mogą zastąpić dane głównej wersji. Aby uniknąć utraty danych, należy zmienić ustawienia docelowe w gałęzi, aby nie powodowały konfliktu z główną wersją.

• Podczas tworzenia gałęzi mogą istnieć zdalne zmiany, które nie zostały jeszcze zastosowane do obszaru roboczego. 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 skutkować konfliktami scalania, które są trudne do rozwiązania.

Ograniczenia

• Nie jest możliwe odłączenie lub usunięcie projektu za pomocą kontroli wersji, jeśli istnieją gałęzie. Gałęzie należy usunąć przed odłączeniem lub usunięciem projektu.

• Nie ma możliwości zmiany nazwy projektu za pomocą kontroli wersji.

• Po usunięciu dzierżawy obiekty przechowywane z kontrolą wersji w GitHub nie zostaną usunięte. Należy je usunąć 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 bazy danych i połączenia nie są utrzymywane w ramach kontroli wersji.

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

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

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