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.