Gestire i progetti pipeline con il controllo della versione

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

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

GitHub viene utilizzato come provider per il controllo della versione. L'implementazione segue il modello di repository condiviso.

• GitHub Enterprise Cloud e GitHub Enterprise Server non sono supportati.

• Per ulteriori informazioni sul modello di repository condiviso, vedere Informazioni sui modelli di sviluppo collaborativo.

• Per ulteriori informazioni su Git e GitHub, vedere Informazioni su GitHub e Git.

• Considerazioni sulla sicurezza di GitHub

  Qlik Talend Cloud supporta il protocollo di sicurezza HTTPS e i token di accesso personale (PAT), che rappresentano la modalità di autenticazione predefinita per GitHub. Per ulteriori informazioni, vedere Informazioni sull'autenticazione a GitHub.

Operazioni preliminari

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

  L'utente deve avere i seguenti ambiti:

  • repo

  • read:org

  • read:user

  • read:project

• È necessario l'accesso in scrittura sui repository che si intende modificare.

• È necessario creare un token di accesso personale GitHub (classico). I token di accesso personale a grana fine non sono supportati.

  Per ulteriori informazioni, vedere la documentazione di GitHub: Gestione dei token di accesso personale.

• L'organizzazione è obbligatoria nella configurazione di GitHub.

• È necessario il ruolo Può modificare nello spazio in cui risiede il progetto per eseguire azioni di controllo della versione.

• 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 per GitHub

• Dopo aver impostato una connessione a GitHub, è possibile connettere un progetto a un repository.

  Connessione di un progetto a un repository

Impostazione della configurazione per 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 pipeline o nelle impostazioni del profilo utente. Assicurarsi di essersi preparati in base a Operazioni preliminari.

Per configurare GitHub in Progetti pipeline:

1. Fare clic su e quindi su Configurazione GitHub.

2. Impostare l'autenticazione utilizzando la propria organizzazione e il token di accesso personale GitHub descritto in Operazioni preliminari.

3. Fare clic su OK.

Ora è possibile connettere i propri progetti a un repository.

Connessione di un progetto a un repository

È necessario connettere un progetto a un repository prima di poter iniziare a utilizzare il controllo della versione. Assicurarsi di aver impostato una connessione a GitHub.

1. In Progetti pipeline, fare clic su ... su un progetto e selezionare Connetti al controllo della versione.

2. Selezionare a quale repository associare il progetto.

3. Aggiungere un percorso di directory di base.

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

4. È possibile selezionare di eseguire il commit del progetto e il push del progetto nel repository remoto dopo la connessione. Inserire un messaggio di commit.

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

5. Fare clic su Connetti.

Il progetto è ora connesso al repository selezionato. Ciò è indicato nella parte inferiore della scheda del progetto con , il nome del repository e il branch corrente.

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

Sviluppo di un progetto con il controllo della versione

È possibile utilizzare il controllo della versione con approcci diversi:

• Lavorare direttamente sul branch principale. Questo è adatto principalmente per un singolo sviluppatore su un progetto che desidera tenere traccia delle modifiche, ma può essere utilizzato anche da un gruppo di sviluppatori che lavorano in sincronia.

• Lavorare con una strategia di branching, in cui più sviluppatori possono contribuire. È inoltre possibile creare branch per isolare nuove funzionalità o modifiche l'una dall'altra.

Flusso di lavoro semplificato per un progetto a sviluppatore singolo

È possibile lavorare direttamente sul branch principale di un progetto. Questo approccio è più semplice e contiene meno operazioni, ma consente comunque di tenere traccia delle modifiche. Se c'è più di uno sviluppatore, devono fare attenzione a essere sincronizzati.

Dopo aver apportato le modifiche al progetto che si desidera applicare, è sufficiente eseguire un Commit e push.

Flusso di lavoro per un progetto multi-sviluppatore

Questo flusso di lavoro può essere utilizzato se c'è più di uno sviluppatore che lavora su un progetto o se si desidera isolare le modifiche. Ciò comporta la creazione di un branch di sviluppo che è possibile condividere con altri utenti. Con questo flusso di lavoro, gli sviluppatori possono tenere traccia delle reciproche modifiche e decidere quando unire le modifiche al branch principale.

1. Creare un nuovo branch

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

2. Sviluppare

   Apportare tutte le modifiche necessarie nel progetto.

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

3. Applicare le modifiche remote

   Applicare le modifiche remote da un altro branch alla propria area di lavoro per assicurarsi di essere aggiornati con le modifiche dell'altro branch. Questo è utile per evitare o mitigare modifiche in conflitto.

   Se si dispone di due branch contenenti modifiche che potrebbero essere in conflitto, una soluzione alternativa è:

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

   2. Unire entrambi i branch al principale.

   3. Applicare nuovamente le modifiche remote.

4. Commit e push

   Eseguire il commit e il push delle modifiche nel branch di sviluppo. Verrà eseguito il push di tutti gli oggetti, quindi è una buona idea convalidare il progetto prima di eseguirne il commit.

5. Creare una pull request e unire

   Quando si è pronti con lo sviluppo, è il momento di unire le modifiche dall'area di lavoro al branch principale.

   È possibile creare la pull request nel controllo della versione del progetto, ma l'unione deve essere eseguita in GitHub, dove è anche possibile impostare le approvazioni. Per ulteriori informazioni, vedere la Documentazione sulle pull request di GitHub

Creazione di un nuovo branch

1. Nel progetto, fare clic su GitHub e selezionare Crea nuovo branch.

   Il progetto deve essere connesso al controllo della versione. È inoltre necessario disporre dell'autorizzazione per lo spazio in cui risiede la connessione di destinazione del progetto.

2. Selezionare per creare un branch dal branch principale.

3. Inserire un nome per il branch.

4. Impostare un prefisso da aggiungere a tutti gli schemi nel progetto in Prefisso branch per tutti gli schemi. Ciò consente di assegnare un nome univoco a tutti gli schemi per evitare conflitti di denominazione.

5. Fare clic su Crea

Un nuovo branch viene creato dal principale e ne viene eseguito il checkout dal repository. Il branch contiene una nuova versione del progetto, con tutte le attività in stato Nuovo. Ovvero, non sono preparate e non contengono alcun dato.

Applicazione delle modifiche remote

È possibile applicare le modifiche dal repository remoto alla propria area di lavoro. Potrebbe trattarsi di modifiche create al di fuori del controllo della versione integrato di Qlik Cloud, ad esempio in GitHub o da altri strumenti. Questo aiuta a evitare conflitti quando si desidera eseguire il commit e il push delle modifiche nel branch.

1. Nel progetto, fare clic su GitHub e selezionare Applica modifiche remote.

   La finestra di dialogo Applica modifiche remote all'area di lavoro viene visualizzata se vengono trovate delle modifiche.

2. Ora è possibile selezionare per quali attività applicare le modifiche e ispezionare le modifiche. Per ogni modifica, è possibile selezionare quale versione utilizzare, la versione remota o la versione nell'area di lavoro.

   Apportare le modifiche necessarie per mappare le connessioni che sono diverse tra il progetto e il progetto importato.

   Ad esempio, il progetto importato potrebbe utilizzare una connessione di origine denominata SQL1, mentre questo progetto utilizza una connessione simile denominata SQL2. In questo caso, mappare la connessione importata a SQL2 in Imposta connessioni per le attività aggiunte nella versione originale.

   Se le modifiche includono origini tra progetti e il progetto di riferimento è sotto il controllo della versione, è disponibile un selettore Branch per ogni origine tra progetti. Selezionare il branch da consumare. Se il progetto di riferimento non è sotto il controllo della versione, il selettore del branch non viene mostrato.

   Nota informaticaQuando si seleziona una connessione da mappare, è possibile creare una nuova connessione al database, ma non una connessione all'applicazione SaaS.

3. Fare clic su Applica modifiche remote

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

Commit e push

È possibile eseguire il commit e il push delle modifiche nel branch. Poiché le modifiche remote che non vengono applicate all'area di lavoro possono essere sovrascritte, è necessario eseguire Applica modifiche remote prima di eseguire il commit e il push.

1. Nel progetto, fare clic su GitHub e selezionare Commit e push.

   La finestra di dialogo Commit e push viene visualizzata se vengono trovate delle modifiche.

2. Aggiungere un messaggio di commit che possa aiutare a tenere traccia di ciò che è cambiato.

3. Fare clic su Commit e push

Creazione di una pull request

Creare una pull request (PR) per unire le modifiche dall'area di lavoro al branch principale.

1. Nel progetto, fare clic su GitHub su un progetto e selezionare Crea pull request.

   Viene visualizzata la finestra di dialogo Crea pull request.

2. Aggiungere un titolo e una descrizione della pull request.

   È inoltre possibile selezionare di aprire la pull request in GitHub dopo la creazione.

3. Fare clic su Crea pull request.

Ora è possibile impostare le approvazioni per la pull request ed eseguire l'unione in GitHub.

Eliminazione di un branch

È possibile eliminare un branch dopo aver unito le modifiche al branch principale.

1. Nel progetto, fare clic sul branch da eliminare e selezionare Elimina branch.

   È possibile selezionare di eliminare anche il branch remoto nel controllo della versione.

   Se ci sono modifiche di cui non è stato eseguito il commit, sarà necessario confermare che queste modifiche andranno perse durante l'eliminazione del branch.

Rimozione del controllo della versione per un progetto

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

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

Importazione di un progetto dal controllo della versione

È possibile importare un progetto dal controllo della versione, ad esempio se si desidera rivedere il progetto di un altro sviluppatore o collaborare a un progetto. L'importazione di un progetto dal controllo della versione consente inoltre di condividere un progetto con altri spazi o tenant. È possibile condividere una versione di un progetto con uno spazio diverso sullo stesso tenant o su un altro tenant. Questo è utile quando si desidera creare due ambienti, ad esempio uno per lo sviluppo e uno per la produzione."

Prima di importare un progetto

Prima di iniziare a importare un progetto:

• Creare tutte le nuove connessioni necessarie se si sta importando in un nuovo tenant o spazio.

• Se il progetto utilizza connessioni all'applicazione SaaS che non esistono ancora sul tenant o sullo spazio, è necessario creare le connessioni e generare i metadati prima di iniziare l'importazione.

• Se si sta importando una pipeline tra progetti, è necessario importare prima i progetti a monte.

Importazione di un progetto

Se il progetto consuma attività da altri progetti, è necessario mappare progetti e attività a meno che i nomi per gli spazi e i progetti non siano identici.

1. In Integrazione dati > Progetti, fare clic su Crea nuovo e selezionare Importa progetto dal controllo della versione.

2. Selezionare il repository, quindi selezionare il branch.

   Selezionare il percorso della directory di base, se necessario, e fare clic su Mostra progetti.

   Selezionare il progetto da importare dall'elenco.

   Fare clic su Avanti.

3. Impostare le Proprietà del progetto per il nuovo progetto.

   È necessario selezionare a quale spazio aggiungere il progetto in Spazio.

   In Piattaforma dati è possibile modificare la piattaforma dati del progetto e la connessione alla piattaforma dati.

   La modifica della Connessione è necessaria se si è importato un progetto da un altro tenant o se si è modificata la piattaforma dati nel passaggio precedente.

   È possibile modificare la connessione all'area di staging. Questo è necessario se si è importato un progetto da un altro tenant o, in alcuni casi, se si è modificata la piattaforma dati nel passaggio precedente.

   Fare clic su Avanti.

4. Impostare le Impostazioni predefinite del progetto per il nuovo progetto.

   È possibile aggiungere un prefisso agli schemi di dati creati nel progetto in Prefisso per tutti gli schemi. Questo è utile quando il progetto importato si trova nello stesso data warehouse cloud del progetto esportato.

   È inoltre possibile impostare un nome predefinito in Nome database. Per i progetti Snowflake è possibile impostare un Nome data warehouse predefinito e per i progetti Databricks è possibile impostare un Nome catalogo predefinito. È possibile utilizzare il nome predefinito del progetto per tutti i tipi di attività o impostare il nome su predefinito o su un nome personalizzato per ogni tipo di attività.

   Fare clic su Avanti.

5. Impostare Connessioni e impostazioni attività.

   È possibile sostituire le connessioni di origine importate o le origini tra progetti. Questo è necessario se si è importato un progetto da un altro tenant.

   Quando si mappa un'origine tra progetti a un progetto che è sotto il controllo della versione, è disponibile un selettore Branch. Selezionare il branch del progetto di riferimento da consumare. Se il progetto di riferimento non è sotto il controllo della versione, il selettore del branch non viene mostrato. Se un'origine tra progetti è mappata a un branch non principale, il nome del branch viene mostrato tra parentesi accanto al nome del progetto.

   In Impostazioni attività opzionali è inoltre possibile modificare le impostazioni dell'attività che sono state sovrascritte nel progetto originale.

6. Quando si è pronti, fare clic su Importa.

Il progetto viene aggiunto alla home di Integrazione dati.

Lavorare su un progetto importato dal controllo della versione

Si lavora allo stesso modo dei normali progetti con controllo della versione, con alcune differenze:

• È possibile passare solo al branch principale o a un altro branch che è stato importato dal controllo della versione.

• Se si è importato da un branch, il branch principale sarà vuoto.

• L'eliminazione di un progetto non eliminerà la versione remota.

Considerazioni sulla 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 contenere anche diversi progetti. La best practice è allinearli e 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.

Best practice

Di seguito sono riportate alcune best practice 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 file 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 della versione di Qlik Talend Cloud gestisca il repository GitHub.

• Eseguire il commit solo di progetti validi e testati per l'esecuzione.

  Se si aggiungono progetti con attività dati di Landing o Registrate 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 branch per i progetti di replica, è necessario tenere presente che i branch utilizzano la stessa destinazione per impostazione predefinita. Ciò significa che l'esecuzione di attività nel branch può sovrascrivere i dati della versione principale. Per evitare la perdita di dati, modificare le impostazioni di destinazione nel branch in modo che non siano in conflitto con la versione principale.

• Quando si crea un branch, potrebbero esserci modifiche remote che non sono ancora state applicate all'area di lavoro. Applicare le modifiche remote prima o dopo la creazione del branch, a meno che non si desideri scartare le modifiche remote.

• Apportare modifiche allo stesso set di dati in due branch diversi può causare conflitti di unione difficili da risolvere e la ricreazione del set di dati.

  Nota informaticaQuando un set di dati viene aggiunto a un'attività, ottiene un identificatore interno. Gli identificatori interni vengono utilizzati per consentire la ridenominazione senza interruzioni e altre operazioni sui metadati in una pipeline. Quando si crea lo stesso set di dati in un progetto o branch separato, l'identificatore interno sarà diverso, il che potrebbe causare un conflitto durante l'unione dei due branch. Ciò potrebbe far sì che il processo di preparazione elimini e ricrei un set di dati anche se ha lo stesso nome.

Lavorare nei branch

È possibile creare un progetto, progettarlo e, quando si è pronti, distribuirlo in produzione utilizzando il branch MAIN. La versione su MAIN corrisponde alla pipeline di produzione. Non si dovrebbe mai modificare direttamente il branch MAIN oltre la prima distribuzione.

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

Gli sviluppatori possono creare un numero qualsiasi di branch per le loro esigenze di sviluppo

• Utilizzare i prefissi dello schema per i branch per evitare conflitti di database durante l'apporto delle modifiche.

• In un branch, gli sviluppatori possono apportare un numero qualsiasi di modifiche ed eseguire commit e push tutte le volte che è necessario. Si consiglia di isolare ogni modifica in un commit separato e autonomo. Ad 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 all'interno di un singolo commit

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

Quando gli sviluppatori hanno finito di lavorare nel loro branch, possono creare una pull request per la revisione tra pari.

Dopo la revisione e l'approvazione da parte di altri membri del team, è possibile unire la pull request con la versione MAIN in GitHub .

Infine, utilizzare Applica modifiche remote nel progetto per eseguire il pull delle modifiche approvate del branch nel branch MAIN (produzione).

Lavorare negli spazi

Per distribuzioni più grandi e critiche si consiglia 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 origini e destinazione in ogni spazio.

• Produzione

  Il branch MAIN riflette ciò che è 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.

  Nessuna modifica viene apportata direttamente nello spazio di produzione/branch MAIN. Tutte le modifiche vengono apportate in altri spazi con connessioni dedicate, utilizzando i branch.

  È 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 branch MAIN per iniziare la modifica.

  Gli utenti creano un nuovo branch, apportano le loro modifiche, creano pull request, uniscono ed eseguono il pull back in MAIN/Produzione.

• Sviluppo

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

  Le modifiche sono isolate utilizzando i branch, di solito un branch per sviluppatore. Utilizzare i prefissi dello schema quando viene creato un branch per evitare conflitti di database durante l'apporto delle modifiche.

• Revisione / accettazione della qualità

  Ai revisori viene concesso l'accesso agli spazi di sviluppo e alle connessioni per:.

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

  • Approvare le pull request per procedere con l'unione in GitHub.

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

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

Limiti

• Il controllo della versione non è supportato per i progetti con Qlik Cloud (QVD) come destinazione.

• Non è possibile disconnettere o eliminare un progetto che utilizza il controllo della versione se sono presenti branch. I branch devono essere eliminati prima di poter disconnettere o eliminare il progetto.

• Non è possibile rinominare un progetto che utilizza 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 potrebbero peggiorare.

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

• I token di accesso personale a grana fine di GitHub non sono supportati.

• Un branch (ad eccezione del branch principale) può essere utilizzato da un solo progetto per repository, anche se due progetti si trovano nello stesso repository.

• Non è possibile applicare modifiche remote 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 Databricks.