Gestione dei progetti con il controllo della versione

È possibile utilizzare il controllo della versione per gestire lo sviluppo di un progetto dati e per tenere traccia delle modifiche.

Quando si utilizza con il controllo della versione, è possibile eseguire il commit delle versioni dei progetti durante la progettazione. Questo consente di visualizzare le modifiche tra due versioni del progetto. Ciò consente anche di sviluppare i progetti dati utilizzando una strategia di ramificazione. In questo modo, è possibile lavorare su una versione isolata del progetto in ogni area di lavoro o ramo. L'area di lavoro può essere condivisa da più utenti. È possibile quindi unire le modifiche dall'area di lavoro in un ramo principale per la distribuzione in produzione.

GitHub viene utilizzato come provider per il controllo della versione.

Guida introduttiva

• Creare un utente in GitHub che il tenant può utilizzare per accedere a GitHub. Questo potrebbe essere già stato creato per l'utente da un amministratore.

  L'utente deve avere i seguenti ambiti:

  • repo

  • read:org

  • read:user

  • read:project

• È necessario disporre di accesso in scrittura ai repository che si desidera modificare.

• È necessario creare un token di accesso personale per GitHub (classico). Non sono supportati token di accesso personali granulari.

  Per maggiori informazioni, vedere la documentazione di GitHub: Gestione dei token di accesso personali.

• L'organizzazione è obbligatoria nella configurazione di GitHub.

• Per eseguire le azioni di controllo della versione, è richiesto il ruolo Può modificare nello spazio in cui risiede il progetto.

• Prima di poter iniziare a utilizzare il controllo della versione, è necessario impostare una configurazione per connettersi a GitHub con l'utente GitHub creato.

  Impostazione della configurazione su GitHub

• Una volta impostata la connessione a GitHub, è possibile collegare un progetto a un repository.

  Connessione di un progetto a un repository

Impostazione della configurazione su GitHub

Tutti gli utenti che desiderano lavorare con il controllo della versione devono impostare una configurazione per connettersi a GitHub utilizzando un account utente GitHub.

È possibile configurare GitHub in Progetti. Assicurarsi di avere seguito le indicazioni in Guida introduttiva.

1. Fare clic su e poi su Configurazione GitHub.

2. Configurare l'autenticazione utilizzando la propria organizzazione e il token di accesso personale a GitHub descritto in Guida introduttiva.

3. Fare clic su OK.

Ora è possibile collegare i propri progetti a un repository.

Connessione di un progetto a un repository

Prima di poter iniziare a utilizzare il controllo della versione, è necessario collegare un progetto a un repository. Assicurarsi di aver impostato una connessione a GitHub.

1. In Progetti, fare clic su ... su un progetto e selezionare Connetti a controllo versione.

2. Selezionare il repository a cui associare il progetto.

3. Aggiungere un percorso directory di base.

   Se si desidera connettersi a un progetto esistente in GitHub, è necessario utilizzare lo stesso percorso.

4. È possibile scegliere di eseguire il commit e quindi il push del progetto sul repository remoto dopo la connessione. Inserire un messaggio per il commit.

   Se non si esegue subito il commit e il push, verrà creato un ramo principale nell'area di lavoro, ma non nel repository remoto.

5. Fare clic su Connetti.

Il progetto è ora connesso al repository selezionato. Lo stato è indicato nella parte inferiore della scheda del progetto con , il nome del repository e il ramo corrente.

Quando si apre il progetto, la riga del titolo ora conterrà il menu GitHub, con le opzioni di controllo della versione. Al nome del progetto verrà aggiunto anche il nome del ramo corrente.

Sviluppo di un progetto con il controllo della versione

È possibile utilizzare il controllo della versione con approcci diversi:

• Quando si lavora direttamente sul ramo principale. Questa opzione è idonea soprattutto per i singoli sviluppatori di un progetto che vogliono tenere traccia delle modifiche, ma può essere anche utilizzata da un gruppo di sviluppatori che lavorano in sincronia.

• Quando si lavora utilizzando una strategia di ramificazione, a cui possono contribuire più sviluppatori. È possibile anche creare rami per isolare le nuove funzioni o le modifiche l'una dall'altra.

Flusso di lavoro semplificato per i progetti con un solo sviluppatore

È possibile lavorare direttamente sul ramo principale di un progetto. Questo approccio è più semplice e contiene un minor numero di operazioni, ma consente comunque di tenere traccia delle modifiche. Se vi sono più sviluppatori, devono lavorare in sincronia.

Una volta apportate le modifiche al progetto che si desidera applicare, basta eseguire Esegui commit e invia.

Flusso di lavoro per un progetto con più sviluppatori

Questo flusso di lavoro può essere utilizzato se vi sono più sviluppatori che lavorano su un progetto, o se desidera isolare le modifiche. Questo comporta la creazione di un ramo di sviluppo che è possibile condividere con altri utenti. Con questo flusso di lavoro, gli sviluppatori possono tenere traccia delle rispettive modifiche e decidere quando unire le modifiche al ramo principale.

1. Creazione di un nuovo ramo

   Creare un nuovo ramo di sviluppo dal ramo principale. È possibile condividere il ramo con più utenti.

2. Sviluppo

   Apportare tutte le modifiche necessarie al progetto.

   Nota informaticaGli schemi e le connessioni del database non vengono mantenuti nel controllo della versione.

3. Applicazione delle modifiche in remoto

   Applicare le modifiche remote da un altro ramo alla propria area di lavoro per assicurarsi sia aggiornata con le modifiche dell'altro ramo. Questa operazione è utile per evitare o attenuare le modifiche in conflitto.

   Se si dispone di due rami che contengono modifiche che possono essere in conflitto, una soluzione consiste nel:

   1. Eseguire il commit delle modifiche in entrambe le aree di lavoro.

   2. Unire entrambi i rami a quello principale.

   3. Applicare nuovamente le modifiche in remoto.

4. Esegui commit e invia

   Eseguire il commit e il push delle modifiche nel ramo di sviluppo. Tutti gli oggetti verranno distribuiti tramite push, quindi è una buona idea convalidare il progetto prima di eseguire il commit.

5. Aprire una richiesta di pull e unire

   Quando si è pronti per la fase di sviluppo, è il momento di unire le modifiche dall'area di lavoro al ramo principale. L'unione di un ramo di sviluppo al ramo principale deve essere eseguita su GitHub aprendo una richiesta di pull. È possibile impostare l'approvazione per il ramo da unire al ramo principale. Per maggiori informazioni, consultare la documentazione sulle richieste di pull su GitHub.

Creazione di un nuovo ramo

1. In Progetti, fare clic su ... su un progetto e selezionare Crea nuovo ramo.

   Il progetto deve essere connesso al controllo della versione.

2. Selezionare per creare un ramo dal ramo principale.

3. Inserire un nome per il ramo.

4. Impostare un prefisso da aggiungere a tutti gli schemi del progetto in Prefisso ramo per tutti gli schemi. Questo consente a tutti gli schemi di essere denominati in modo univoco per evitare conflitti di denominazione.

5. Fare clic su Crea.

Viene creato un nuovo ramo da quello principale e viene estratto dal repository. Il ramo contiene una nuova versione del progetto, con tutte le attività con lo stato Nuovo, e cioè che non sono state preparate e non contengono dati.

Applicazione delle modifiche in remoto

È possibile applicare le modifiche dal repository remoto alla propria area di lavoro. Si può trattare di modifiche create al di fuori del controllo di versione integrato in Qlik Cloud, ad esempio in GitHub o con altri strumenti. In questo modo, è possibile evitare i conflitti quando si desidera eseguire il commit e il push delle modifiche sul ramo.

1. In Progetti, fare clic su ... su un progetto e selezionare Applica modifiche in remoto.

   La finestra di dialogo Applica modifiche in remoto all'area di lavoro viene visualizzata se sono state trovate delle modifiche.

2. Ora è possibile selezionare le attività per alle quali applicare le modifiche ed esaminare le modifiche. Per ogni modifica, è possibile selezionare la versione da utilizzare, quella remota o quella presente nella propria area di lavoro.

3. Fare clic su Applica modifiche in remoto.

È necessario aggiungere le connessioni di origine e le connessioni di destinazione se le modifiche includono nuove attività di dati.

Esecuzione di commit e push

È possibile eseguire il commit e il push delle modifiche nel ramo. Poiché le modifiche remote che non sono state applicate alla propria area di lavoro possono essere sovrascritte, si consiglia di eseguire Applica modifiche remote prima di eseguire il commit e il push.

1. In Progetti, fare clic su ... su un progetto e selezionare Esegui commit e invia.

   La finestra di dialogo Esegui commit e invia viene visualizzata se sono state trovate delle modifiche.

2. Aggiungere un messaggio di commit che aiuta a tenere traccia delle modifiche apportate.

3. Fare clic su Esegui commit e invia.

Eliminazione di un ramo

Una volta unite le modifiche al ramo principale, è possibile eliminare un ramo.

1. In Progetti, fare clic su ... sul ramo da eliminare e selezionare Elimina ramo.

   È possibile scegliere di eliminare il ramo remoto anche nel controllo della versione.

   Se vi sono modifiche non applicate con il commit, è necessario confermare che queste modifiche andranno perse quando si eliminerà il ramo.

Rimozione del controllo della versione per un progetto

È possibile disconnettere il progetto dal controllo della versione. Se sono presenti rami esistenti, devono essere eliminati prima di poter disconnettere il progetto.

1. In Progetti, fare clic su ... sul progetto da disconnettere e selezionare Disconnetti da GitHub.

Condivisione di un progetto con altri spazi o tenant

È possibile condividere una versione di un progetto con un altro spazio nello stesso tenant o di un altro tenant. Questa opzione è utile quando si desidera creare due ambienti, ad esempio uno per lo sviluppo e uno per la produzione.

1. Creare un nuovo progetto con lo stesso nome di quello originale.

   Impostare lo stesso caso d'uso e lo stesso tipo di piattaforma. È possibile utilizzare diverse connessioni.

2. Connettere il nuovo progetto allo stesso percorso del repository e della directory di base del progetto originale.

   Nota informaticaNon selezionare l'opzione Esegui commit e invia.

3. Se la connessione alla piattaforma punta alla stessa destinazione del progetto originale, assicurarsi di cambiare il database o gli schemi delle attività dati. Un modo per modificare gli schemi di tutte le attività è quello di cambiare il Prefisso per tutti gli schemi nelle impostazioni del progetto Metadati prima di applicare le modifiche in remoto. Ciò consente di assicurare che tutte le attività vengano create con questo prefisso.

4. Applicare le modifiche in remoto, selezionando tutti i file.

5. Aggiungere le connessioni di origine mancanti per tutte le attività di trasferimento.

   Fare clic su Seleziona sorgente dati nell'attività di trasferimento, selezionare la connessione, quindi fare clic su Salva.

   Nota informaticaLa connessione deve provenire dallo stesso tipo di sorgente e puntare a tabelle con gli stessi nomi del progetto originale.

6. Aggiungere le connessioni di origine e di destinazione mancanti per tutte le attività di replica.

Questa azione crea un'altra area di lavoro. È possibile apportare modifiche al progetto in una delle aree di lavoro e utilizzare Applica modifiche in remoto per sincronizzare l'altra area di lavoro.

Considerazioni di sicurezza

Assicurarsi di mantenere sincronizzate le configurazioni di sicurezza tra Qlik Talend Data Integration e GitHub.

• In Qlik Talend Data Integration le autorizzazioni si basano su spazi che possono contenere diversi progetti. In GitHub le autorizzazioni si basano su repository che possono anche contenere diversi progetti. La procedura consigliata è quella di allinearli e di connettere tutti i progetti in uno spazio allo stesso repository.

• Tenere presente che Qlik Talend Data Integration e GitHub utilizzano autorizzazioni e ruoli diversi per gli utenti.

Procedure consigliate

Ecco alcune procedure consigliate quando si lavora con progetti che utilizzano il controllo della versione.

• Aggiungere un file README che descriva il repository in GitHub. Per ulteriori informazioni, vedere Informazioni sui README.

• Eseguire il commit solo per i progetti validi e testati per essere eseguiti.

  Se si aggiungono progetti con attività di trasferimento o di dati registrati che non sono state preparate o trasformate, le colonne di origine non sono ancora incluse. Le colonne di origine vengono aggiunte quando l'attività viene preparata e trasformata.

• Quando si crea un ramo per i progetti di replica, è necessario tenere presente che i rami utilizzano la stessa destinazione per impostazione predefinita. Ciò significa che le attività in esecuzione nel ramo possono sovrascrivere i dati della versione principale. Per evitare la perdita di dati, modificare le impostazioni di destinazione nel ramo per evitare i conflitti con la versione principale.

• Quando si crea un ramo, possono esserci delle modifiche in remoto che non sono ancora state applicate all'area di lavoro. Applicare le modifiche in remoto prima o dopo la creazione del ramo, a meno che non vogliano scartare le modifiche in remoto.

• Se si apportano modifiche allo stesso set di dati in due rami diversi, queste possono generare conflitti di unione difficili da risolvere.

Limitazioni

• Non è possibile scollegare o eliminare un progetto utilizzando il controllo della versione se vi sono dei rami. I rami devono essere eliminati prima di poter disconnettere o eliminare il progetto.

• Non è possibile rinominare un progetto utilizzando il controllo della versione.

• Quando si elimina un tenant, gli oggetti archiviati con il controllo della versione in GitHub non verranno eliminati. È necessario eliminare questi oggetti manualmente.

• Se un repository è utilizzato da molti progetti o contiene molti file che non sono archiviati in Qlik Talend Data Integration, le prestazioni possono diminuire.

• Gli schemi e le connessioni del database non vengono mantenuti nel controllo della versione.

• I token di accesso personali granulari con GitHub non sono supportati.

• Un ramo (tranne quello principale) può essere utilizzato da un solo progetto per repository, anche se due progetti si trovano nello stesso repository.

• Non è possibile applicare le modifiche in remoto da un progetto che utilizza una piattaforma di destinazione diversa. Ad esempio, se si esegue il commit delle modifiche a un progetto su Snowflake, non è possibile applicare le modifiche a un progetto di Databricks.