Qual è la struttura del processo di controllo delle versioni?

-3

Come dovrebbe essere rappresentato il processo di controllo delle versioni nel team degli sviluppatori? Supponiamo di avere un sistema CI e vogliamo avviare la versione del nostro software.

Se parliamo di semiver, le versioni major e secondarie devono essere modificate manualmente, giusto? Cosa fare con la versione del percorso? Penso anche manualmente, ma non sono sicuro. Il numero di build può essere ottenuto dal sistema CI. In tal caso, gli sviluppatori si assumeranno le responsabilità per le modifiche, che hanno fatto, anche le modifiche devono essere controllate con l'aiuto delle richieste di pull e la revisione del codice.

Tenendo conto di quanto sopra, supponiamo di sviluppare un progetto sulla piattaforma .NET. È normale che gli sviluppatori dopo le loro modifiche cambieranno AssemblyInfo? Rispettivamente, teamlead deve codificare i rilasci nel repository git allo sprint finale o qualcosa del genere.

Riepilogo:

  • 1) Crea modifiche nel codice del progetto;
  • 2) Cambiare manualmente AssemblyVersion: maggiore, minore o percorso dipendono dalle modifiche;
  • 3) Crea una richiesta di pull per l'unione nel ramo di sviluppo;
  • 4) Teamlead esegue la revisione del codice e approva o rifiuta le modifiche;
  • n) Alla release teamlead si fondono sviluppare in master e creare tag di rilascio.

O esistono strumenti comuni per automatizzare questo processo? Se possibile, descrivi il tuo punto di vista.

UPD : questa domanda nel contesto del processo di sviluppo del sistema di monitoraggio degli eventi sportivi. Il sistema è costituito da un'applicazione web client / amministratore e pochi servizi Windows. Per lo sviluppo utilizza N librerie interne che richiedono il controllo delle versioni.

Le versioni useranno il QA per specificare la versione del componente in cui è stato trovato un bug. Anche gli sviluppatori, poiché diversi client possono utilizzare diverse versioni dell'applicazione, necessitano di un meccanismo per rilevare l'applicazione dello stato e risolvere le dipendenze durante lo sviluppo.

    
posta 21.01.2018 - 09:21
fonte

1 risposta

1

Semver sembra inutilmente complesso se è solo per i QA essere in grado di specificare una versione quando segnalano un bug. Se fosse solo per quello suggerirei che usano l'ID di commit da git, o il numero di build dal sistema di CI.

Tuttavia semver ha più utilità per gli sviluppatori che usano le librerie interne e secondo semver.org " Una volta che un pacchetto con versione ha stato rilasciato, il contenuto di quella versione NON DEVE essere modificato. Qualsiasi modifica DEVE essere rilasciata come una nuova versione. "

Quindi è necessario un nuovo numero di versione (patch) almeno tanto quanto si fa una nuova versione. Il modo in cui imposti il numero di patch dovrebbe dipendere presumibilmente dalla frequenza con cui crei i rilasci. Se rilasci relativamente di rado, ad es. una volta alla settimana o meno, la scelta manuale del numero può funzionare correttamente.

D'altra parte se si dispone di una pipeline che crea automaticamente una versione ogni volta che un commit passa tutti i test, allora probabilmente si vuole che la pipeline imposti automaticamente il numero di patch.

    
risposta data 21.01.2018 - 14:25
fonte