In un'architettura distribuita, perché è difficile gestire le versioni?

Question

Vedo di volta in volta. Il responsabile del test UAT desidera che la nuova build sia pronta per essere testata entro venerdì. La prima domanda posta, nella riunione pre-test, è & Quot; quale versione testerò, contro? & Quot; (che è una domanda equa da porre). La stanza diventa silenziosa, quindi qualcuno tornerà con & Quot; Tutti gli assembly hanno la loro versione, basta fare clic con il tasto destro del mouse e guardare le proprietà ... & Quot ;.

Dal punto di vista dei responsabili dei test, questo è inutile. Vogliono una versione / etichetta / tag in tutto che dica loro su cosa stanno lavorando. Vogliono che queste informazioni siano facilmente disponibili.

Ho visto soluzioni in cui la versione di aree diverse di un sistema viene archiviata in un archivio dati, quindi mostrata nella finestra about dell'applicazione principale. Il problema è che questo deve essere mantenuto.

Quali soluzioni hai visto per ovviare a questo problema?

EDIT. Il sistema distribuito copre VB6, ASP classico, VB.Net, C #, servizi Web (attraverso i dipartimenti, quindi quale versione stiamo usando?), SQL Server 2005.

Answer 1

Penso che il problema sia che tu e il tuo responsabile dei test stiamo parlando di due cose diverse. Le versioni di assembly sono ottime per gli assembly, ma il responsabile del test sta parlando di una versione di livello superiore, una & Quot; versione di sistema & Quot ;, se lo desideri. Almeno questa è la mia lettura del tuo post.

Quello che devi fare in tali situazioni è mappare tutti i tuoi diversi componenti in una versione del sistema. Dici qualcosa sulla falsariga di & Quot; La versione 1.5 del sistema è composta da Foo.Bar.dll v1.4.6 e Baz.Qux.dll v2.6.7 e (ecc.) & Quot ;. Inferno, in un sistema distribuito, potresti volere versioni diverse per ciascuno dei tuoi servizi, che possono essere composte da diverse versioni di .dlls. Si potrebbe dire, ad esempio: & Quot; La versione 1.5 del sistema è composta dal servizio Foo v1.3, composto da Foo.dll v1.9.3 e Bar.dll v1.6.9 e dal servizio Bar v1 .9, composto da Baz.dll v1.8.2 e Qux.dll v1.5.2 e (ecc.) & Quot ;.

Fare cose come questa è in genere il lavoro dell'architetto del software e / o del gestore della costruzione nella tua organizzazione.

Esistono diversi strumenti che è possibile utilizzare per gestire questo problema che non hanno nulla a che fare con la lingua scelta. Il mio preferito personale è attualmente Jira , che, oltre al bug tracking, ha un ottimo versioning del prodotto e supporto alla roadmapping.

Answer 2

Potrebbe voler dare un'occhiata a questa pagina che spiega alcuni modi per integrare un controllo delle versioni coerente nel processo di generazione.

Answer 3

Esistono diverse cose che contribuiscono al problema. Fuori dalla cima della mia testa, eccone uno:

Uno dei vantaggi di un'architettura distribuita è che otteniamo un enorme potenziale di riutilizzo creando servizi e pubblicando le loro interfacce in un modo o nell'altro. Ciò significa quindi che le versioni di un'applicazione client non sono necessariamente strettamente sincronizzate con le versioni dei servizi sottostanti. Pertanto, potrebbe essere rilasciata una nuova versione di un'applicazione aziendale che utilizza lo stesso vecchio servizio affidabile utilizzato da un anno. Come dovremmo quindi applicare un singolo tag di rilascio in questo caso?

Tuttavia, è una domanda giusta, ma richiede una risposta non banale per essere significativa.

Answer 4

Non usare la numerazione delle versioni basata su build per altro che riferimenti interni. Quando il gestore UAT pone la domanda che dici & Quot; Venerdì * & Quot ;.

L'unico trucco è quindi assicurarsi che l'etichettatura avvenga in modo affidabile nel controllo del codice sorgente.

* inserisci qui il datestamp / etichetta appropriato

Answer 5

Utilizziamo .NET e Subversion. Tutti i nostri gruppi di applicazioni condividono un numero di versione, che deriva da un numero di revisione maggiore e minore aggiornato manualmente e dal numero di revisione Subversion (<major>.<minor>.<revision>). Abbiamo un'attività pre-build che aggiorna questo numero di versione in un file AssemblyVersionInfo.vb condiviso. Quindi, quando i tester chiedono il numero di versione, possiamo dare loro il numero completo in 3 parti o solo la revisione della sovversione. Le librerie che consumiamo non cambiano o la modifica non è rilevante per il tester.