Git
PowerShell Universal è in grado di sincronizzare gli script di configurazione con un repository git remoto.
Configurazione
Console di amministrazione
La sincronizzazione git può essere configurata nel database modificando le impostazioni all'interno della console di amministrazione. Questo è l'approccio preferito. Il vantaggio è che, quando connette nuove istanze di PowerShell Universal alla sua istanza SQL, non dovrà configurare nuovamente la sincronizzazione git.
Per configurare la sincronizzazione git, vada in Impostazioni \ Git all'interno della console di amministrazione. Potrà fare clic sul pulsante Create Git Settings.
appsettings.json
Può anche utilizzare le impostazioni di configurazione per impostare la sincronizzazione git. Questo è utile se ha una singola istanza di PSU e desidera eseguire il backup del file appsettings.json. La modifica delle impostazioni all'interno della console di amministrazione non aggiornerà il file appsettings.json. Dovrà farlo manualmente e riavviare PowerShell Universal dopo aver modificato le impostazioni.
Se le impostazioni di sincronizzazione git sono specificate nel database, le impostazioni definite in appsettings.json vengono ignorate.
Impostazioni di sincronizzazione Git
Branch
Per impostazione predefinita, PowerShell Universal si sincronizzerà con il branch master. Se desidera utilizzare un branch diverso, specifichi l'impostazione GitBranch all'interno del suo appsettings.json.
Correzione del tracking upstream mancante
Se riscontra l'errore "There is no tracking information for the current branch", il branch locale non è collegato al remoto. Per risolvere il problema:
Apra PowerShell in
%ProgramData%\UniversalAutomation\Repository(o nel percorso del repository configurato)Esegua:
Remoto
I remoti non sono obbligatori. Se non viene specificato un remoto, il repository git viene memorizzato localmente nella directory Repository. Se specificato, PowerShell Universal si sincronizzerà con il remoto. Sono necessarie credenziali corrette per accedere a tale remoto.
Formato URL di Azure DevOps
I repository di Azure DevOps devono utilizzare il formato URL moderno dev.azure.com anziché il dominio legacy visualstudio.com:
Formato corretto:
Esempi:
Se il nome del suo repository contiene spazi, questi devono essere codificati come %20 nell'URL. Eviti di utilizzare URL con il vecchio dominio visualstudio.com, poiché potrebbero causare loop di reindirizzamento o errori di autenticazione con l'errore "too many redirects or authentication replays".
Per Azure DevOps, il suo Personal Access Token deve avere l'ambito Code (Read & Write). I token fine-grained funzionano, ma sono consigliati i PAT classici per compatibilità tra le varie versioni di PSU.
Nota per gli utenti GitLab: se la sua istanza GitLab richiede l'autenticazione basata su header, potrebbe essere necessario utilizzare l'opzione External Git Client e configurare gli helper delle credenziali Git, poiché il client Git integrato di PSU utilizza l'autenticazione HTTP Basic con il PAT come password. Alcune configurazioni GitLab si aspettano invece un header Private-Token.
Autenticazione
Dovrà configurare l'autenticazione al suo repository git remoto. Consigliamo un personal access token.
Client Git esterno
Può scegliere di utilizzare un client git esterno anziché la libreria integrata in PowerShell Universal. Ciò le consente opzioni di configurazione aggiuntive, come l'utilizzo dell'autenticazione SSH. PowerShell Universal non utilizzerà i nomi utente, le password o i PAT configurati quando si abilita questo metodo. Dovrà avere un client git installato.
Utilizzo delle chiavi SSH
Può utilizzare PowerShell Universal per generare e gestire le chiavi SSH. All'interno della console di amministrazione, faccia clic su Platform \ SSH Keys. Generi una nuova chiave SSH. Successivamente, faccia clic sul pulsante di copia accanto alla chiave SSH per ottenere la chiave pubblica.
Registri la chiave pubblica con il repository o l'account di destinazione. Ad esempio, può seguire la guida di GitHub qui.
All'interno della finestra Git Settings, selezioni la chiave SSH che desidera utilizzare con la sincronizzazione git. Quando utilizza le chiavi SSH, si assicuri che sia selezionato l'URL SSH per la clonazione del suo repository.
Impostazione delle credenziali
Quando utilizza il client git esterno, è responsabile della configurazione delle credenziali prima di eseguire una sincronizzazione.
Può configurare le credenziali tramite la configurazione git o l'URL passato a PowerShell Universal.
Il comando seguente memorizzerà le credenziali in testo normale sul server PowerShell Universal. Dovrà eseguire questo comando come utente dell'account di servizio in modo che abbia accesso alle credenziali. Questo creerà un file .git-credentials che verrà utilizzato durante l'autenticazione con l'URL di destinazione. Potrebbe essere necessario modificare l'URL a seconda del suo remoto git.
Può anche memorizzare le credenziali direttamente nell'URL fornito a PowerShell Universal.
Esempio: nome utente e PAT
Per utilizzare un client git esterno e passare un nome utente e un PAT per l'autenticazione, può specificarli nell'URL del remoto git. Ad esempio:
Esempio: SSH e GitHub
Innanzitutto, dovrà configurare il suo ssh-agent locale e il suo account GitHub con le chiavi SSH.
Può seguire la guida disponibile qui.
Successivamente, fornirà un URI SSH per l'URL del remoto git in PowerShell Universal. La chiave SSH configurata verrà utilizzata per la connessione.
Problema con il certificato SSL
SSL Certificate problem: unable to get local issuer certificate
Se sta eseguendo su Windows e riceve un problema relativo al certificato SSL, potrebbe essere necessario assicurarsi di aver abilitato il supporto schannel.
Persistenza delle credenziali
Unable to persist credentials with the 'wincredman' credential store.
Se si trova su Windows e riceve un errore relativo alla persistenza delle credenziali in wincredman, potrebbe essere necessario impostare la persistenza delle credenziali su DAPI. Può scoprire come farlo qui.
Modalità manuale
La modalità manuale richiede che gli utenti che modificano l'istanza di PowerShell Universal facciano clic su Edit per apportare modifiche al sistema.
Una volta completate le modifiche, l'utente può fare clic su Save Changes per avviare un commit
Nella pagina di commit git, può visualizzare i file modificati e inserire un messaggio di commit.
Una volta eseguito il commit delle modifiche, queste verranno inviate al remoto e il servizio inizierà nuovamente a sincronizzarsi con git. In questo momento esiste anche la possibilità che si verifichi un conflitto di merge git. Consulti Gestione dei conflitti per maggiori informazioni.
La modalità manuale può essere impostata nelle impostazioni git all'interno della console di amministrazione o all'interno di appsettings.json.
Metodo uno: invio dei file locali al remoto
Deve assicurarsi che la sua cartella locale non sia un repository git preesistente. La directory del suo repository dovrebbe essere semplicemente una cartella con i suoi file di PowerShell Universal. Se esiste una cartella .git e non desidera utilizzare questo repository, dovrebbe eliminarla e PowerShell Universal creerà un nuovo repository.
Se sta popolando un nuovo repository git, deve assicurarsi che il remoto non contenga alcun file. Dovrebbe essere un repository completamente vuoto. Ad esempio, quando crea un repository su GitHub, non selezioni la creazione di un file di licenza o readme.md.
Una volta creato il repository, può recuperare l'URL del remoto git e fornirlo al file appsettings.json di PowerShell Universal.
Una volta ottenuti il branch, l'URL del remoto git e le credenziali, può fornirli al suo file appsettings.json e il remoto git verrà popolato con i suoi file locali.
Metodo due: pull da un remoto Git
Può configurare PowerShell Universal per eseguire il pull da un remoto git. In questa configurazione, deve assicurarsi che la cartella del suo repository locale sia completamente vuota. Qualsiasi file all'interno della cartella causerà il fallimento della sincronizzazione git e ne impedirà il ripristino.
Configuri il file appsettings.json in modo da includere il branch, le credenziali e l'URL del remoto git che sta clonando. Una volta impostati i campi, può avviare il servizio PowerShell Universal. La prima cosa che farà il servizio sarà clonare il repository e configurarlo localmente.
Timeout della sincronizzazione Git
La sincronizzazione git andrà in timeout se non riesce a contattare il remoto dopo 60 minuti. Ciò consente il tempo necessario per scaricare repository di grandi dimensioni o per far fronte a ritardi con reti lente. Potrebbe vedere il servizio PowerShell Universal bloccato su "Synchronizing with git" durante l'avvio, mentre il server attende che ciò avvenga. Se desidera ridurre questo tempo, può utilizzare la seguente impostazione di appsetting.json. Il valore è espresso in minuti.
Intervallo di sincronizzazione
Tipo: Integer
Predefinito: 60
appsettings.json: GitSyncInterval
L'intervallo, in secondi, tra i tentativi di sincronizzazione Git automatica quando la sincronizzazione automatica è abilitata. Il valore predefinito è 60 secondi (1 minuto).
Per regolare la frequenza di sincronizzazione, modifichi appsettings.json:
Questo modificherebbe l'intervallo di sincronizzazione a 5 minuti. Valori più bassi aumentano la frequenza di sincronizzazione, ma possono avere un impatto sulle prestazioni in repository di grandi dimensioni o su reti lente. Impostare questo valore troppo basso (al di sotto di 30 secondi) non è consigliato per gli ambienti di produzione.
Risoluzione dei problemi
Azure DevOps: "Too many redirects or authentication replays"
Questo errore indica in genere uno dei seguenti problemi:
Formato URL legacy: si assicuri di utilizzare
https://dev.azure.com/<org>/<project>/_git/<repo>anziché il vecchio dominiovisualstudio.comAmbito PAT non valido: il suo Personal Access Token deve avere le autorizzazioni Code (Read & Write) in Azure DevOps
Credenziali scadute: generi un nuovo PAT e lo reinserisca nelle impostazioni Git di PSU
Spazi codificati: se il nome del suo repository contiene spazi, si assicuri che siano codificati come
%20nell'URL
Risoluzione:
Aggiorni l'URL del remoto per utilizzare
dev.azure.comGeneri un nuovo PAT con l'ambito Code (Read & Write)
Abiliti Use External Git Client e installi Git for Windows se il client integrato continua a non funzionare
Tracking upstream mancante
Errore: "There is no tracking information for the current branch"
Causa: il branch Git locale non è configurato per tracciare un branch remoto.
Risoluzione: apra PowerShell nella directory del repository ed esegua:
Sostituisca main con il nome effettivo del suo branch. Quindi faccia clic su Synchronize Now in PSU.
La sincronizzazione Git si interrompe dopo la modifica delle impostazioni nell'interfaccia utente
Sintomi: dopo aver modificato le impostazioni Git (URL remoto, credenziali, intervallo di sincronizzazione, ecc.) nell'interfaccia utente di PSU e aver fatto clic su OK, la sincronizzazione smette di funzionare anche se le impostazioni sembrano corrette.
Causa: in PSU 5.x, le credenziali Git sono memorizzate nel database SQL. Qualsiasi modifica alle impostazioni Git tramite l'interfaccia utente può cancellare le credenziali memorizzate, anche se il campo della password sembra ancora compilato nel modulo.
Risoluzione:
Reinserisca il Personal Access Token in Impostazioni → Git
Faccia clic su OK per salvare
Negli ambienti multi-nodo, ripeta questo processo su ogni nodo: le credenziali devono essere inserite singolarmente su ciascun server
Faccia clic su Synchronize Now per verificare che la sincronizzazione funzioni di nuovo
Il sistema non propaga automaticamente le credenziali tra i nodi in una configurazione con bilanciamento del carico o ad alta disponibilità.
Problemi di agent e di rete
Sintomi: la sincronizzazione funziona su un nodo ma non riesce sugli altri, oppure vede errori RpcException o "service is unavailable" nei log.
Cause comuni:
Mancata corrispondenza delle versioni: si assicuri che tutti i server e gli agent PSU eseguano la stessa versione
Regole del firewall: gli agent comunicano con il server PSU tramite gRPC sulle porte 5000 (HTTP) o 5001 (HTTPS)
Blocco di proxy o WebSocket: i proxy aziendali possono bloccare o ispezionare il traffico gRPC; configuri git per utilizzare il proxy o abiliti il client Git esterno
Risoluzione:
Verifichi che tutti i nodi eseguano la stessa versione di PSU
Controlli che le regole del firewall consentano il traffico sulle porte 5000/5001
Testi la connettività gRPC tra i nodi
Se utilizza un proxy, configuri le variabili di ambiente
http_proxyehttps_proxyper l'account di servizio PSU
Distribuzioni Docker e containerizzate
Si assicuri che l'immagine del container includa
git(eseguagit --versionper verificare)Verifichi l'accesso di rete in uscita al remoto git
Monti volumi persistenti per
/datao%ProgramData%\UniversalAutomationper preservare lo stato di git tra i riavviiSe la sincronizzazione fallisce silenziosamente, controlli i log del container per individuare errori git o di rete
Modifica di .git/config senza la CLI di Git
Se lo strumento da riga di comando Git non è installato sul server e si verificano errori di tracciamento upstream, può modificare direttamente la configurazione del repository tramite il file browser di PSU:
Vada a Platform → Configurazione → Repository → .git → config
Aggiunga le righe seguenti (adatti il nome del branch al suo repository):
Faccia clic su Salva
Torni a Impostazioni → Git e faccia clic su Sincronizza ora
Questo approccio consente di configurare il tracciamento upstream senza bisogno dei comandi git, il che è particolarmente utile quando Git for Windows non è installato o quando si esegue con account di servizio con restrizioni.
Le impostazioni Git non vengono mantenute
Se le modifiche alle impostazioni Git non vengono salvate o vengono ripristinate subito dopo aver fatto clic su OK:
Verifichi le autorizzazioni del file system:
Arresti il servizio PowerShell Universal
Provi a modificare manualmente
%ProgramData%\PowerShellUniversal\appsettings.json(o%ProgramData%\UniversalAutomation\appsettings.jsonnelle versioni precedenti)Aggiunga una riga di commento, salvi e riapra il file per verificare che le modifiche siano state mantenute
Se le modifiche vengono ripristinate, verifichi la presenza di software antivirus, oggetti Criteri di gruppo (GPO) o autorizzazioni NTFS che bloccano le scritture nella directory dati di PSU
Abiliti il logging di debug per la risoluzione dei problemi:
Arresti il servizio PowerShell Universal
Modifichi
appsettings.jsone imposti:
Salvi e riavvii il servizio
Provi nuovamente a salvare le impostazioni Git
Esamini
%PROGRAMDATA%\PowerShellUniversal\systemLog.txtper individuare errori relativi alle scritture di configurazione
Popoli manualmente le impostazioni Git:
Con il servizio arrestato, può popolare direttamente i campi Git in appsettings.json:
Riavvii il servizio e verifichi che le impostazioni compaiano in Impostazioni → Git. Se scompaiono di nuovo, i log di debug indicheranno se il ripristino è causato da un problema di autorizzazioni, da software di protezione degli endpoint o da un errore di convalida della configurazione.
unknown certificate lookup failure: 16777280
Quando si utilizza la libreria git integrata, potrebbe riscontrare problemi con il certificato durante la connessione a repository git ospitati localmente. In questa configurazione, consigliamo di utilizzare il client git esterno per fornire maggiore supporto alla configurazione del processo di ricerca del certificato.
File inclusi
I file inclusi in una sincronizzazione git sono tutti i file all'interno del repository locale. Ciò include i file di configurazione PS1, i file XML delle pagine e qualsiasi altro file che può aggiungere manualmente.
I seguenti non sono inclusi:
appsettings.json
database.db
web.config
Binari dell'applicazione PowerShell Universal
Più repository Git
PowerShell Universal supporta l'archiviazione di più configurazioni di repository git all'interno del database. In questo modo, può passare rapidamente da una configurazione all'altra di PowerShell Universal. Faccia clic sulla scheda Repositories per visualizzare i repository attualmente configurati. Da qui può eliminare e modificare le configurazioni dei repository.
PowerShell Universal non rimuove la cartella .git quando elimina una configurazione di repository. Dovrà farlo manualmente per poter configurare un nuovo repository.
Quando aggiunge una nuova configurazione di repository, può fare clic sul pulsante Applica per passare al repository selezionato. Ciò eliminerà tutti i file nella directory del repository e clonerà il repository selezionato. Non è possibile applicare una configurazione di repository se sono presenti modifiche non sottoposte a commit nel repository. Dopo aver clonato il repository, PowerShell Universal ricaricherà completamente la sua configurazione.
Pagina della cronologia e dello stato di Git
La scheda della cronologia mostra tutta la cronologia dei commit git per il repository corrente.
La scheda dello stato di sincronizzazione mostra lo stato attuale dei nodi all'interno del cluster PSU.
Test della sincronizzazione Git
Il modo migliore per assicurarsi che la sincronizzazione git funzioni correttamente è fare clic sul pulsante Sincronizza ora. Ciò forzerà l'esecuzione di una sincronizzazione e potrà verificare se le impostazioni inserite funzionano correttamente.
Visualizzazione delle modifiche
Può visualizzare le modifiche nella tabella delle sincronizzazioni git. Ogni sincronizzazione include il numero di modifiche rilevate dall'ultima sincronizzazione, lo SHA del commit e un elenco delle modifiche tra quello SHA e il precedente. Quando i file sono in stato modificato, potrà visualizzare le differenze utilizzando lo strumento di diff dei file.
Gestione dei conflitti
Quando più utenti modificano i file di configurazione di PowerShell Universal, possono verificarsi conflitti. PowerShell Universal indicherà che un determinato nodo si trova in stato di conflitto quando si tenta di eseguire il commit delle modifiche. Vedrà un elenco delle modifiche in conflitto nella pagina di commit git. Faccia clic sul pulsante Risolvi conflitto per visualizzare il conflitto in un editor.
In questo esempio, la stringa per questo endpoint è stata modificata sia nel repository remoto sia in quello locale.
Modifichi il testo per rimuovere il conflitto.
Salvi le modifiche e torni alla pagina di commit git. Inserisca un nuovo messaggio di commit per il conflitto di merge e faccia clic su Esegui commit delle modifiche.
Ciò risolverà il conflitto di merge ed eseguirà il push al remoto.
Comportamento della sincronizzazione Git
Bidirezionale
Per impostazione predefinita, la sincronizzazione git funziona in entrambe le direzioni. Se apporta modifiche nella console di amministrazione PSU, tali modifiche verranno sottoposte a commit e sincronizzate con il remoto configurato.
Tutte le modifiche apportate nel remoto verranno estratte (pull) localmente.
Se configura la sincronizzazione git con un remoto git preesistente, le modifiche verranno estratte e sincronizzate localmente. Non può avere alcuna modifica in locale.
Se configura la sincronizzazione git con un repository vuoto (bare), le modifiche locali verranno sincronizzate e il repository verrà inizializzato.
Unidirezionale
Può regolare il comportamento della sincronizzazione git modificando l'impostazione GitSyncBehavior in appsettings.json. Se impostata su OneWay, la console di amministrazione e l'API di gestione diventeranno di sola lettura. Il sistema PowerShell Universal eseguirà il pull dal remoto ma non eseguirà mai push o commit localmente.
Solo push
La modalità di sincronizzazione git solo push non esegue il pull delle modifiche dal remoto. Tutte le modifiche apportate localmente verranno inviate al remoto. La console non sarà di sola lettura. Questa configurazione è utile per scenari in cui si dispone di una macchina utilizzata per la configurazione di riferimento (source-of-truth) di un pool di server di sola lettura.
Token di accesso personale
Consigliamo di utilizzare un token di accesso personale (PAT) anziché un nome utente e una password. Può configurare un token di accesso personale impostando la proprietà password in appsettings.json o con altri metodi di configurazione.
Token fine-grained di GitHub
In GitHub, può recuperare un token fine-grained facendo clic sul suo avatar in alto a destra e selezionando Settings, Developers Settings, Personal Access Tokens e infine Fine-Grained Tokens.
Ambiti dei token
Quando genera il token, si assicuri di concedere al repository l'autorizzazione Read-Write per Content. Ciò aggiungerà automaticamente Read all'autorizzazione Metadata. Può fornire l'accesso solo al repository che intende clonare.
Token GitHub (Classic)
In GitHub, può recuperare un token di accesso personale facendo clic sul suo avatar in alto a destra e selezionando Settings, Developer Settings, Personal Access Tokens e infine Tokens (Classic).
Quando genera il token di accesso, si assicuri di selezionare le autorizzazioni Repo.
Nota: se utilizza BitBucket, dovrà specificare il nome utente oltre al PAT in appsettings.json.
Nome utente e password
Può anche configurare un remoto git per l'autenticazione con nome utente e password. Imposti il nome utente e la password tramite il file appsettings.json o un altro metodo di configurazione.
Errori comuni
Git synchronization failed. unknown certificate lookup failure: 16777280
La libreria lib2gitsharp non è riuscita a convalidare il certificato del repository git remoto. Dovrà utilizzare il client git esterno e una configurazione git personalizzata per risolvere il problema.
Alcune opzioni comuni per il supporto HTTPS di git includono:
"too many redirects" o replay di autenticazione
Il remoto git ha rifiutato le sue credenziali per accedere al repository. Il suo token di accesso personale potrebbe essere scaduto o non avere accesso al remoto.
repository not owned by current user
Il repository git locale non dispone dei controlli di accesso corretti per l'utente che tenta di accedervi. Ciò può accadere se PowerShell Universal ha clonato il repository e successivamente è stato impostato un account di servizio diverso sul servizio. Poiché i controlli di accesso non corrispondono, git non accederà alla cartella. Questa è una funzionalità di sicurezza di git.
Può aggiornare il proprietario della cartella per evitare questo problema oppure configurare git per considerare attendibile la cartella. Imposti il valore seguente nella configurazione git globale.
La configurazione globale si trova in: C:\Program Files\git\etc\gitconfig
Vantaggi della sincronizzazione Git rispetto alla sincronizzazione Git manuale
È possibile sincronizzare manualmente un repository git. PowerShell Universal utilizza comandi molto basilari quando si tratta di git. Qualsiasi modifica apportata a PowerShell Universal tramite la console di amministrazione o l'API richiama un git commit e l'autore viene impostato sull'identità dell'utente che effettua la modifica. Durante un'operazione di sincronizzazione git, eseguiamo prima un git pull per assicurarci di avere la versione più recente dei file sul remoto. Successivamente, eseguiamo un git push per inviare i commit locali avvenuti dall'ultima sincronizzazione.
Potrebbe ottenere questa funzionalità con un job pianificato.
Detto questo, una funzionalità della sincronizzazione git è che analizza il commit per garantire che vengano ricaricati solo i file modificati durante la sincronizzazione. Ciò impedirà alle dashboard di essere distribuite automaticamente quando non sono cambiate o ai servizi API di riavviarsi quando gli ambienti non sono stati aggiornati. Si ottiene quindi un guadagno in termini di prestazioni.
L'altro problema è che, a causa del modo in cui PowerShell Universal monitora i file (con un FileSystemWatcher) e del modo in cui git aggiorna i file, le configurazioni non verranno ricaricate automaticamente dopo un pull. Dovrà assicurarsi di forzare la rivalutazione delle configurazioni.
Strategie di branching
Le strategie di branching in git determinano come le modifiche vengono spostate da un branch all'altro. L'utilizzo di diversi tipi di strategie di branching in PowerShell Universal può garantire che team di dimensioni diverse possano lavorare insieme in modo efficace nella piattaforma.
Utenti singoli e piccoli team
Per utenti singoli e piccoli team, potrebbe non essere necessario avere più di un singolo branch. Il branch viene utilizzato per il tracciamento della cronologia e offre la possibilità di annullare le modifiche. Gli utenti accederanno direttamente a PowerShell Universal per apportare modifiche oppure eseguiranno il commit delle modifiche nel singolo branch da cloni locali della directory del repository utilizzando uno strumento come VS Code.
main - Singolo branch che accetta direttamente tutte le modifiche
Utenti singoli e piccoli team con un branch di staging
Anche gli utenti singoli e i piccoli team possono trovare vantaggioso utilizzare un branch di staging, o dev. Questo branch riceverà le modifiche durante lo sviluppo. Un'istanza autonoma di PowerShell Universal verrà configurata per essere eseguita su questo branch dev in modo che gli utenti possano convalidare le modifiche prima di inviarle in produzione.
Quando si utilizza una configurazione con branch di staging, gli ambienti PowerShell Universal sono completamente separati. Utilizzano un database e uno scheduler diversi. Dati come identità, token app e cronologia dei job non sono condivisi tra gli ambienti.
È quindi possibile configurare un'istanza separata di PowerShell Universal in modo che punti a un branch main, o di produzione, che riceverà gli aggiornamenti tramite merge o pull request in un sistema come GitHub. In questa configurazione, è possibile utilizzare la sincronizzazione git unidirezionale per estrarre le modifiche da main senza mai eseguire il push dalla piattaforma. Ciò previene anche la maggior parte dei conflitti di merge, poiché verranno risolti nel branch dev o tramite lo strumento di merge nel repository di origine.
main - Branch di produzione che riceve le modifiche dalle pull request del branch dev
dev - Il branch di staging utilizzato per accettare i commit e convalidare le modifiche prima di inviarle a master.
Team di medie e grandi dimensioni
Quando si considerano team con più di un paio di sviluppatori, una strategia di branching più complessa può essere utile per valutare meglio le modifiche al codice ed evitare conflitti di merge. PowerShell Universal fornisce strumenti di merge di base, ma per questo scopo sono disponibili strumenti migliori, come le pull request di GitHub, le merge request di GitLab e strumenti locali come GitKraken.
Nei team di medie dimensioni, può essere desiderabile avere branch di funzionalità aggiuntivi che isolino modifiche specifiche in un determinato branch. Ad esempio, uno sviluppatore potrebbe creare un nuovo set di API per gestire Azure in PowerShell Universal. Per evitare modifiche che compromettano il branch dev, gli sviluppatori creeranno il proprio branch di funzionalità che conterrà tutte le loro modifiche fino a quando non sarà sufficientemente completo per essere unito al branch di sviluppo.
In questo tipo di configurazione, lo sviluppo locale è ideale perché gli sviluppatori lavoreranno sulla loro istanza locale di PowerShell Universal all'interno del loro branch di funzionalità. Quando la funzionalità è completa, creeranno una pull o merge request nel repository di origine per spostare le modifiche nel branch dev. I test verranno completati sul branch dev prima del merge in produzione.
Analogamente a una strategia di branching main\dev, tutte le istanze di PowerShell Universal saranno isolate e non condivideranno un database o uno scheduler.
Una volta che un set di funzionalità è pronto per la produzione, verrà effettuata una pull o merge request da dev al branch main.
main - Branch di produzione che riceverà modifiche solo da dev
dev - Branch di staging che riceve le modifiche dai branch di funzionalità ma non viene modificato direttamente
feature - Branch di funzionalità su cui gli sviluppatori eseguono direttamente i commit e che viene unito a dev quando è pronto
A seconda della complessità del suo ambiente, potrebbe essere consigliabile utilizzare i Deployment anziché git in produzione. Consulti la sezione Team di grandi dimensioni più avanti per maggiori informazioni.
Team di grandi dimensioni
Nei team di grandi dimensioni, consigliamo di utilizzare git per scopi di sviluppo, ma di utilizzare i Deployment, o un concetto simile, per la produzione.
I Deployment forniscono pacchetti di configurazione immutabili che sono stati testati a fondo negli ambienti di livello inferiore. Utilizzando i Deployment, può scegliere come sviluppare e gestire il suo codice e semplicemente pubblicare il risultato negli ambienti di sviluppo, staging, QA e produzione. Ciò garantisce che tutto il codice sia ben testato prima della distribuzione nei suoi sistemi critici.
Può utilizzare workflow automatizzati, come GitHub Actions, per pubblicare i suoi Deployment senza dover aggiornare manualmente alcun sistema.
Hosting Git
PowerShell Universal supporta qualsiasi soluzione di hosting git standard. I nostri clienti utilizzano spesso le seguenti:
GitHub
GitHub Enterprise
GitLab
Bitbucket
Azure DevOps
Sebbene queste siano le piattaforme più comuni, supportiamo qualsiasi piattaforma che utilizzi il protocollo git.
Esempio: Gitea
È inoltre possibile utilizzare soluzioni semplici e self-hosted come Gitea. Ecco un esempio di come configurare facilmente un container docker Gitea da utilizzare con PowerShell Universal.
Ultimo aggiornamento
È stato utile?