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

Question

Vedo questo e più volte. Il test manager UAT vuole che la nuova build sia pronta per essere testata entro venerdì. La prima delle domande poste nella riunione di pre-test è "quale versione verrà testata, contro?" (che è una domanda equa da chiedere). La stanza diventa silenziosa, quindi qualcuno tornerà con "Tutti gli assemblaggi hanno una loro versione, basta fare clic con il tasto destro e guardare le proprietà ...".

Dal punto di vista del responsabile dei test, questo è inutile. Vogliono una versione/etichetta/tag attraverso tutto ciò che è che dice loro su cosa stanno lavorando. Vogliono queste informazioni facilmente disponibili.

Ho visto soluzioni in cui la versione di aree diffierenti di un sistema viene memorizzata in un archivio dati, quindi visualizzata nella casella relativa all'applicazione principale. Il problema è che questo deve essere mantenuto.

Quali soluzioni hai visto che aggirano questo problema?

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

Answer 1

Penso che il problema sia che tu e il tuo responsabile del test state parlando di due cose diverse. Le versioni di assembly sono ideali per gli assembly, ma il tuo manager di test parla di una versione di livello superiore, una "versione di sistema", se lo desideri. Almeno questa è la mia lettura del tuo post.

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

Fare cose del genere è tipicamente il lavoro dell'architetto del software e/o del gestore di build nella vostra organizzazione.

Esistono numerosi strumenti che è possibile utilizzare per gestire questo problema che non hanno nulla a che fare con la lingua scelta. Il mio preferito è attualmente il Jira, che, oltre al bug tracking, ha un ottimo supporto delle versioni dei prodotti e dell'assistenza stradale.

Answer 2

Potrebbe voler dare un'occhiata a this page che spiega alcuni modi per integrare il controllo delle versioni coerente nel processo di compilazione.

Answer 3

Non si utilizza la numerazione delle versioni basata su build per scopi diversi da riferimenti interni. Quando il manager UAT pone la domanda, dici "Venerdì *".

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

* inserire appropriato datestamp/etichetta qui

Answer 4

Usiamo .NET e Subversion. Tutti i nostri assembly di applicazioni condividono un numero di versione, derivato da un numero di revisione maggiore e minore aggiornato manualmente e dal numero di revisione di Subversion (<major>.<minor>.<revision>). Abbiamo un'attività di preinstallazione 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 di 3 parti o solo la revisione di subversion. Le librerie che consumiamo non cambiano o il cambiamento non è rilevante per il tester.

Answer 5

Ci sono un certo numero di cose diverse che contribuiscono al problema. Fuori di testa, ecco uno:

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

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