Sono necessari i numeri di versione

Potresti avere numeri di versione interni della tua applicazione per gestire al meglio i tuoi processi di sviluppo interni. Tuttavia, questi numeri sono di scarsa utilità per l'utente.

Lo scopo usuale dei numeri di versione è di dire all'utente se la loro applicazione è aggiornata o meno. Quando questo non è sotto il loro controllo, può almeno essere utile per il personale di supporto verificare che abbiano ricevuto l'ultima versione. Ma quando hai un software come servizio in cui tutti gli utenti condividono la stessa distribuzione, non c'è motivo di comunicargli il numero di versione.

Un'eccezione potrebbe essere quando non sei l'unico a offrire il servizio. Quando si concede in licenza solo il software o lo si autorizza da solo, così altri offrono lo stesso software di un servizio, potrebbe essere utile comunicare il numero di versione all'utente finale in modo da poter confrontare il provider che offre la versione e anche essere a conoscenza di la versione utilizzata dal loro provider nel caso ci siano differenze rilevanti nell'utilizzo.

Ci sono due possibili consumatori di numeri di versione. I tuoi processi interni e le persone che utilizzano il tuo servizio.

Con i processi interni, i numeri di versione ti aiutano a identificare quando qualcosa è stato corretto e cosa è cambiato da loro. Dicendo "abbiamo risolto questo nella versione 1.2.3" sai dove è stato fatto e se ora stai riscontrando lo stesso bug, hai una regressione. Essendo in grado di identificare quando è stato corretto o implementato (con un numero di versione) ora puoi restringere ciò che devi fare per risolverlo.

I consumatori del servizio possono anche utilizzare i numeri di versione. Non tutti i consumatori devono conoscere i numeri di versione, ma è qualcosa che li può aiutare. Dicendo "questi bug sono stati corretti nella versione 1.2.3 che è stata distribuita in una data" tu, come il consumatore, sai che i bug che potresti aver segnalato sono corretti. Inoltre, quando segnali bug, hai l'opportunità di dire "questo è stato risolto in 1.2.3 ma ora in 1.2.5 è stato interrotto di nuovo". Questa è probabilmente una informazione preziosa per segnalare bug.

Molte volte, anche il software as a service ha un'API per l'interfacciamento. Questa API dovrebbe anche essere versionata. Puoi visualizzarlo con l'API Stack Exchange e API dei dati di Google . Un'API è molto simile a una libreria che è ospitata su un altro server. Proprio come le librerie sono versionate, così come le API.

Lo scopo di un numero di versione in questi casi è quello di consentire una comunicazione più efficiente delle informazioni su quale software è stato segnalato, inserito e attualmente in esecuzione. Che ci sia solo una istanza di "attualmente in esecuzione" non diminuisce l'utilità dei primi due punti. È utile sia per interni che per esterni.

Considera inoltre che, a meno che tu non stia offrendo un'API, versioning semantico non è necessariamente utile. Ho lavorato in situazioni in cui il numero di build del server di integrazione continua era sufficientemente utile per un numero di versione: "la produzione sta eseguendo la build 123, l'abbiamo risolta nella build 145 che è attualmente in fase di test nell'ambiente QA. 155 ".

Il codice rivolto all'utente non richiede i numeri di versione.

Ma se stai scrivendo il codice che viene utilizzato da sviluppatori esterni, devi assolutamente offrire i numeri di versione e ALSO mantenere più versioni sul tuo sito. Con una chiara politica di deprecazione. In questo modo avrai la libertà di apportare modifiche potenzialmente incompatibili con le versioni precedenti all'API, quindi consentirà alle persone che dipendono da te di eseguire l'aggiornamento quando è più conveniente per loro. E farlo non è così difficile come si potrebbe pensare nei giorni di AWS poiché si limitano a mantenere i server che eseguono una vecchia versione e lanciarne di nuovi utilizzando la nuova. Rilascia il vecchio quando è necessario, quindi disattivali quando hai finito.

Sì, so che Facebook non è bravo a farlo. Ma sono anche famigerati per il rilascio di codice che inaspettatamente infrange le persone che usano le loro API. E conosco parecchi sviluppatori che desiderano strongmente che abbiano qualche alternativa a Facebook. Facebook blocca gli sviluppatori con successo perché hanno gli utenti. Ma tu non hai quello. Se fai in modo che gli sviluppatori si sentano in questo modo sull'utilizzo del tuo servizio, se ne andranno.

Tornerei al vero scopo dei numeri di versione: identificare un particolare corpo di codice in modo univoco. Questo è importante in molti luoghi, ma ci sono diversi casi in cui ho potuto vedere di doverli mostrare ai clienti:

• Sono usati dai clienti che devono aggiornare (che hai detto esplicitamente che non hai a che fare con). Ciò include anche i clienti che avrebbero bisogno di fare confronti, come confrontare il modo in cui il software funziona tra due client.
• Sono utili agli sviluppatori che devono eseguire il debug delle situazioni con il cliente.
  • Se è facile per gli sviluppatori sapere con quale versione stanno lavorando, come "c'è solo una versione con cui lavorare in qualsiasi momento", non hanno bisogno di numeri.
• Stai lavorando con software in cui la versione del software non è importante quanto altri fattori. Ad esempio, se lavori con le IA, lo stato dell'IA è molto più significativo della versione del codice in molte situazioni.

Usare assolutamente versioni per i clienti. Google e Facebook fanno questo come versioni principali. Controlla i tuoi dati su quello.

Naturalmente ci sono versioni interne ma quelle esterne dovrebbero essere stabili in termini di contratti / firme e risposte. Gli aggiornamenti quindi non infrangono i clienti e le versioni più recenti possono eliminare cruft se necessario. Puoi anche annunciare un orario in cui le versioni precedenti non saranno più supportate e avranno la possibilità di specificare quale versione intendi. Questo non è possibile se non supporti la versione del cliente Apis.

Se la tua soluzione SaaS è composta da applicazioni client come Android, App IOS, ecc. Potresti voler eseguire la versione dell'applicazione server per avere un mapping di compatibilità delle versioni tra la tua app del server e le tue app del client .

Alcuni potrebbero dire: ecco perché hai il versioning delle API ma non è lo stesso.

A volte l'API potrebbe rimanere intatta ma le regole di business interne potrebbero cambiare, richiedendo anche modifiche corrispondenti sulle app client.

Bene, sono un novizio per l'industria, ma finora ciò che ho conosciuto è che le versioni sono sempre utili in termini di sviluppo e gestione interna. L'utente potrebbe non essere interessato a cosa e come stai lavorando sul tuo sistema di controllo della versione o se stai lanciando versioni alfa, beta. Ma allo stesso tempo, quando aggiorniamo una versione, vogliamo trasmettere agli utenti che l'aggiornamento è davvero importante, identifica la versione e allo stesso tempo gli utenti possono confrontare due versioni. Proprio come Android, noi paragoniamo gli aggiornamenti del sistema operativo e li confrontiamo, quindi è anche più facile per gli utenti a volte.