Controllo delle versioni e distribuzione dei sistemi dipendenti

Should it be independent as well (own versioning) despite the fact that it's using a lot of shared libraries which are maintained by the desktop development team?

IMHO ci sono 2 possibili modelli qui:

1. Il servizio Web è visto come parte dell'applicazione desktop e ottiene lo stesso numero di versione.

2. Il servizio Web è visto come un'applicazione separata, ottiene la propria numerazione delle versioni (e devi tenere traccia di quali numeri di versione WS corrispondono al numero di versione dell'applicazione e del database)

Il modello 1 va bene quando la tua API REST è molto stabile e non cambia molto spesso e vuoi fornire una nuova versione WS ogni volta che crei una nuova versione dell'applicazione desktop & Banca dati. In genere ciò include una nuova distribuzione del WS ogni volta che si distribuisce una nuova versione dell'applicazione principale. Ciò può anche implicare una nuova versione (e distribuzione) dell'applicazione desktop ogni volta che è necessario fornire una correzione per il WS. Quest'ultimo può essere evitato se si utilizza uno schema di versioning come "major.minor.patchlevel", dove solo "major.minor" è uguale per WS e app / database desktop, mentre il patchlevel può essere diverso purché patch arbitraria i livelli dell'app / database del tuo desktop e il tuo WS possono lavorare insieme. Tale schema di controllo delle versioni è una "versione leggera" del modello 2 ..

Il modello 2 è migliore se il WS ha un "ciclo di rilascio" completamente diverso come l'applicazione e l'amp; Banca dati. Ad esempio, quando cambi la tua API REST molto più spesso rispetto al resto dell'applicazione (sembra improbabile), o quando la maggior parte delle applicazioni & le modifiche al database non influiscono sul servizio web e non è necessario fornire (e non si desidera distribuire) una nuova versione WS. Ciò può dipendere anche da chi sta sviluppando il WS: se si dispone di un team separato su questo, è probabile che richieda di avere il proprio ciclo di rilascio per fare le cose (vedi legge del comune ).

Quando il tuo servizio web condivide molte librerie con l'applicazione desktop, suppongo che sia più probabile che tu fornisca una nuova versione WS ogni volta che fornisci una nuova versione dell'applicazione desktop (modello 1), altrimenti ne ottieni una diverse versioni delle stesse librerie in produzione, che aumenta la complessità della manutenzione.

Where / when should i check if all three systems are compatible?

Lascia che il WS verifichi se il database ha un numero di versione a cui è compatibile ogni volta che collega il db. Nel modello 1 che dovrebbe essere semplice, nel modello 2 è necessario un elenco dei numeri di versione del database che può gestire (questo elenco deve essere parte integrante dell'installazione WS, quindi non può essere incasinato da una distribuzione errata) .

Le applicazioni mobili dovrebbero anche verificare se l'API REST fornisce tutto ciò che si aspetta. Potrebbero contenere un controllo esplicito della versione (e smettere di funzionare, o richiedere un aggiornamento, quando la versione WS è troppo vecchia o troppo nuova), o singoli controlli per le diverse funzioni API REST, con un comportamento diverso quando mancano alcune funzionalità. La cosa migliore dipende molto da come appare l'API REST, da ciò che gli utenti si aspettano, da come si distribuiscono nuove versioni sui dispositivi mobili, ecc.

Potrebbe essere una buona idea mantenere le nuove versioni dell'API REST in basso compatibile con le versioni precedenti (se possibile senza troppi grattacapi), e usare il WS come punto in cui la versione delle applicazioni mobili si disaccoppia dal versioning di l'altra parte del sistema.