In Git, è necessario l'uso di un ramo "PRODUZIONE" e / o sarebbe possibile avere più di uno di essi?

0

Un breve riassunto di come gestiamo la gestione delle filiali : dal ramo MASTER possono essere create una o più sezioni di funzionalità (per lo sviluppo a medio-lungo termine), quando le modifiche implementabili sono state unite a MASTER quindi rilascia i rami. I rami di rilascio vengono mantenuti per mantenere la versione distribuita fino al rilascio successivo e vengono uniti a PRODUCTION per creare TAG distribuiti in Live Environments.

Primo versetto della domanda : è effettivamente necessario il passaggio del ramo PRODUCTION? Sicuramente TAGS può essere creato in modo affidabile da un ramo di rilascio nello stesso punto in cui sarebbe stato unito al ramo PRODUCTION?

Se vale la pena di avere il secondo verso della domanda : sarebbe un controllo sorgente adatto avere più di un ramo PRODUCTION pur avendo un solo MASTER?

La motivazione : presto avremo un progetto interno che inizierà (si spera) sarà un prodotto "white-label" che possiamo usare per sostituire tre applicazioni interne separate che usiamo attualmente (così come per eventuali future applicazioni). Sarebbe un back-end, una libreria, un'API ma tre team che lo utilizzano e gestiscono le proprie interfacce utente e aggiungono funzionalità riutilizzabili al back-end.

Un pensiero era che il progetto poteva essere un repo con un MASTER, vari rami di funzionalità per qualsiasi team in quanto hanno bisogno di sviluppare le cose (a medio-lungo termine). Ma dovremmo avere un ramo PRODUCTION per ciascuna delle tre "versioni" del prodotto o semplicemente TAG fuori dai rispettivi rami di rilascio? In modo che possano essere distribuiti indipendentemente dagli sprint e dai requisiti degli altri (a condizione che non infrangano l'infrastruttura condivisa).

PS: Ciascuna delle tre applicazioni viene distribuita in ambienti Live indipendenti e utilizzata da diversi reparti dell'azienda.

PPS: Se sei a conoscenza di altri flussi di versioning che sarebbero più adatti per favore dimmelo!

[EDIT - Dopo aver letto la risposta di jhr] Pensa a questo come a un grande progetto / applicazione. Ma invece di avere un team BIG che lavora sulle sezioni utilizzate da 3 dipartimenti (ciascuno con i propri flussi e caratteristiche dell'interfaccia utente richiesti, ecc.) Potremmo essere suddivisi in tre team, ognuno dei quali lavora sulle funzionalità di un reparto, sullo stesso codice base (repository) . Questa non è una domanda di specifiche tecniche, ma piuttosto una opinione, esperienza o preferenza ecc.

    
posta David 'the bald ginger' 09.04.2014 - 08:37
fonte

1 risposta

3

Prima di tutto, dal momento che le tue specifiche sono poco chiare, non sono sicuro di quanto davvero si applichi. Ma ci provo ...

Se il progetto ha un ciclo di rilascio singolo, è necessario un solo repository. Se i tuoi tre team devono rilasciare la nuova versione in modo indipendente, diventa molto più caotico. Ma per quello avrei bisogno di un input più specifico. Al momento, mi sembra che tu abbia bisogno di stabilizzare la tua API, sviluppare la libreria e gestire lo sviluppo del tuo back-end. Se questo è parte di un progetto, vai avanti e usa un repository.

Per quanto riguarda la ramificazione, consiglierei di avere sempre un ramo che rappresenta semplicemente l'ultima versione rilasciata e funzionante. Probabilmente questo ramo avrà per lo più commit di unione. Mi piace l'idea di rami di release indipendenti dai rami di sviluppo in quanto un gestore di rilascio potrebbe quindi rivedere facilmente tutto (dopo il blocco delle funzionalità se lo si desidera), cancellare gli ultimi pruriti, impostare correttamente la versione e unire il ramo di produzione. (Potresti anche associare ganci o strategie di distribuzione a quell'unione per spingere automaticamente il rilascio sul tuo sistema di build o qualcosa del genere).

Come ho detto sopra, consiglierei di avere un ciclo di rilascio all'interno di un repository. Se puoi averlo, sarà necessario un solo ramo di produzione. Se i team hanno davvero bisogno di rilasciare nuove versioni dello stesso progetto in modo indipendente, si sente come se ci fosse qualcosa di sbagliato nella gestione del progetto. Ma questo è di nuovo senza sapere molto sul team e sul progetto in generale.

Uno stile che mi piace molto è git flow come descritto da Atlassian . Suggerisce di avere un master (produzione) e un ramo di sviluppo. Durante lo sviluppo accade il lavoro vero ma, che di solito si divide in rami di funzionalità. Quello che mi piace è che un responsabile dello sviluppo (qualcuno con una profonda conoscenza tecnica) può gestire il ramo di sviluppo. Decidono se unire nuove funzionalità o meno. Ad un certo punto diranno a un project / release manager che il team ha terminato e che il project / release manager può quindi (insieme al gestore dello sviluppo) risolvere gli ultimi problemi su un ramo di release prima che venga unito a master (e di nuovo in sviluppo, ovviamente). È solo un'interessante separazione di preoccupazioni che gli sviluppatori sono così interessati a considerare diversi aspetti degli stessi progetti. :)

Spero che questo aiuti un po '.

    
risposta data 09.04.2014 - 12:23
fonte

Leggi altre domande sui tag