È buona pratica separare Git Repo dal Repo pubblicato?

2

Abbiamo un repository Git centrale da cui gli sviluppatori recuperano e inviano le modifiche. Apportano modifiche al ramo principale predefinito. Il nostro strumento CI (Continuous Integration) crea artefatti da questo ramo master predefinito ed è l'entità responsabile della promozione di qualcosa che vogliamo testare su un ramo "UAT" (questo è in realtà fatto da una persona build-master che fa clic su un pulsante sul Pagina Web degli strumenti CI che farà la promozione). Lo strumento CI è anche responsabile della promozione del codice da UAT al ramo "Produzione". Lo scopo delle filiali UAT e Produzione è quello di catturare ciò che è stato promosso a UAT e alla produzione. Nessuno sviluppo si verifica sul ramo UAT e Production conterrà solo "sviluppo" sotto forma di "hot-fix" infrequenti poiché le nostre iterazioni di sviluppo / rilascio sono molto veloci (iterazioni di 1 settimana).

Se riusciamo a farlo facilmente, vorremmo introdurre un controllo che impedisca a qualcuno che per errore apporta modifiche di sviluppo direttamente alle filiali UAT e Produzione. Un pensiero è quello di avere un gancio sul server centrale che si assicura che solo l'utente dello strumento CI possa apportare modifiche a UAT e Produzione. Abbiamo anche pensato che potremmo avere un repository centrale che gli sviluppatori usano che contiene solo il ramo master e un secondo repository che contiene i rami UAT e Production. Lo strumento CI comunicherà con entrambi i repository - esaminerà lo sviluppo da repo per vedere quando ci sono cambiamenti e usa il secondo repository per fare la sua promozione ai rami UAT e Produzione.

Questo è ciò che le persone fanno tipicamente (repository separati per scopi di sviluppo rispetto alla promozione?) Sarebbe meglio dell'approccio hook del server?

    
posta BestPractices 05.08.2012 - 20:21
fonte

2 risposte

2

Lo strumento CI necessita comunque di un proprio repo per mantenere un albero di lavoro per le build, giusto? Può anche solo pubblicare quel repository di sola lettura per l'UAT e le filiali di produzione. Alcune persone preferiscono il metodo di aggancio perché è più centralizzato, ma il metodo di raccolta separata è più facile da proteggere, perché è possibile averli su computer completamente separati controllati da persone separate. Non devi preoccuparti di chi ha i permessi per cambiare hook sul repository degli sviluppatori.

    
risposta data 06.08.2012 - 20:33
fonte
1

No, non necessariamente. Di solito viene utilizzato un repository di un progetto con una corretta gestione delle filiali. Questo separa il ciclo di vita del codice in "fasi" che aiuta a mantenere i cambiamenti indesiderati che vengono distribuiti nei posti sbagliati. Potresti dare un'occhiata a qualcosa come git-flow per aiutare il tuo codice a passare dallo sviluppo a distribuito in produzione, utilizzando un Repo.

Git-flow può anche essere facilitato da strumenti come Stash e Jenkins di Atlassian.

PS: a seconda degli strumenti utilizzati (come lo Stash) puoi bloccare i rami in modo che sia richiesta una richiesta di pull prima che il codice venga unito al master ecc. Ciò potrebbe consentire la revisione del codice.

    
risposta data 09.04.2014 - 08:50
fonte

Leggi altre domande sui tag