Vai al contenuto principale Passa a contenuto complementare

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.

Nota informaticaIl controllo della versione non è disponibile con una sottoscrizione a Avvio Qlik Talend Cloud.

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.

Connessione a 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.

Nota informaticaNello spazio personale dell'utente verrà creata una connessione di tipo GitHub - Controllo versione. Tutti gli utenti avranno una connessione personale al controllo della versione, quindi non è necessario gestirla.

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.

Connettere un progetto al controllo della versione.

Elenco a discesa con le aree geografiche durante la configurazione del tenant.
  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.

Flusso di lavoro per un progetto con più sviluppatori con il controllo della versione

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

  2. Apportare tutte le modifiche necessarie al progetto.

    Nota informaticaGli schemi e le connessioni del database non vengono mantenuti nel controllo della versione.
  3. 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. 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. 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 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. È necessario anche disporre dei permessi per lo spazio in cui risiede la connessione di destinazione del progetto.

  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.

Nota informaticaSe si applicano solo le attività selezionate, è necessario fare attenzione a mantenere la validità strutturale del progetto. Per esempio, se si applica una nuova attività di archiviazione, è necessario applicare anche l'attività di trasferimento di origine. Non è possibile aggiungere manualmente i set di dati di trasferimento.

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 generali 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.

    Se si inizia con un repository vuoto, il controllo della versione di Qlik Talend Cloud aggiungerà automaticamente un file README.md vuoto.

  • In generale, si dovrebbe lasciare che il controllo di versione Qlik Talend Cloud gestisca il repository di GitHub.

  • 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.

Utilizzo dei rami

È possibile creare un progetto, progettarlo e, una volta pronto, distribuirlo in produzione utilizzando il ramo MAIN. La versione su MAIN corrisponde alla pipeline di produzione. Si consiglia di non modificare mai il ramo MAIN direttamente dopo la prima distribuzione.

Ogni volta che uno sviluppatore desidera apportare una nuova modifica in un progetto, come l'aggiunta di una funzionalità o la correzione di un errore, è necessario creare un nuovo ramo.

Gli sviluppatori possono creare un numero qualsiasi di rami in base alle esigenze di sviluppo.

  • Utilizzare i prefissi dello schema per i rami, per evitare conflitti del database durante l'esecuzione delle modifiche.

  • In un ramo, gli sviluppatori possono apportare un numero qualsiasi di modifiche e fare il commit e il push tutte le volte necessarie. Si consiglia di isolare ogni modifica in un commit autonomo e separato. Per esempio, se si apporta una modifica a un'attività di trasformazione che ha un impatto anche sul data mart, assicurarsi di includere entrambe le modifiche in un unico commit.

  • Tutti i membri del team dovrebbero utilizzare Applica modifiche remote in qualsiasi momento per assicurarsi che il ramo MAIN sia aggiornato, soprattutto prima di eseguire il commit delle modifiche apportate.

Quando gli sviluppatori hanno finito di lavorare sul proprio ramo, possono creare una richiesta pull per la revisione tra pari.

Nota informaticaAttualmente è necessario creare una richiesta pull prima di poter utilizzare Applica modifiche remote e unire le modifiche del ramo a quello principale.

È possibile creare una richiesta pull in GitHub, alla voce Richieste pull. È necessario specificare il ramo da cui creare una richiesta pull.

Dopo la verifica e l'approvazione da parte degli altri membri del team, è possibile unire la richiesta pull con la versione MAIN.

Infine, utilizzare Applica modifiche in remoto nel progetto per estrarre le modifiche approvate apportate al ramo e applicarle nuovamente al ramo MAIN (produzione).

Nota informaticaTutti i membri del team dovrebbero utilizzare Applica modifiche in remoto in qualsiasi momento per assicurarsi che il ramo MAIN sia aggiornato.

Uso degli spazi

Per le distribuzioni più grandi e critiche, si raccomanda di utilizzare spazi dedicati per lo sviluppo e la produzione, per isolare le modifiche e garantire l'integrità della pipeline. Utilizzare connessioni dati dedicate per le sorgenti e le destinazioni in ogni spazio.

  • Il ramo MAIN riflette i contenuti in produzione. Ciò significa che esiste una sola versione MAIN di un progetto.

    La produzione è isolata in uno spazio dati dedicato, ad esempio PROD. Le connessioni dedicate sono assegnate allo spazio di produzione.

    Non vengono apportate modifiche direttamente nello spazio di produzione/ramo MAIN. Tutte le modifiche vengono effettuate in altri spazi con connessioni dedicate, utilizzando i rami.

    È possibile riutilizzare la versione MAIN di un progetto esistente in GitHub. Creare un progetto vuoto con lo stesso nome del progetto esistente in GitHub. Questo recupera l'ultima versione disponibile sul ramo MAIN per iniziare la modifica.

    Gli utenti creano un nuovo ramo, apportano le modifiche desiderate, creano richieste pull, le uniscono e le riportano in MAIN/Produzione.

  • Gli sviluppatori possono isolare le proprie modifiche in uno spazio dati dedicato, ad esempio DEV. Le connessioni dedicate sono assegnate allo spazio DEV.

    Le modifiche vengono isolate utilizzando i rami, di solito un ramo per ogni sviluppatore. Utilizzare i prefissi dello schema quando si crea un ramo, per evitare conflitti del database durante l'esecuzione delle modifiche.

  • Ai revisori viene concesso l'accesso agli spazi di sviluppo e alle connessioni per eseguire le seguenti operazioni:

    • Aprire e testare i rami del progetto in Qlik Talend Cloud.

    • Approvare le richieste pull per procedere a effettuare l'unione in GitHub.

    • Informare i membri del team quando le modifiche approvate possono essere riportate in MAIN/Produzione.

Quando si distribuiscono nuovamente le modifiche approvate nello spazio MAIN/Produzione, è necessario riassegnare le connessioni alle connessioni dello spazio di produzione.

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.

Hai trovato utile questa pagina?

Se riscontri problemi con questa pagina o con il suo contenuto – un errore di battitura, un passaggio mancante o un errore tecnico – facci sapere come possiamo migliorare!