Come gestite il versioning in un progetto su più lati?

So che è una domanda ampia, quindi cercherò di essere il più specifico possibile. Questa domanda è più una domanda "organizzativa" che tecnica.

Abbiamo un progetto su più lati con questi componenti principali:

• Un server che ospita la logica di business principale (modelli di dati)
• Un backoffice per i clienti che utilizza la logica aziendale principale
• Un'API dell'applicazione (REST) ​​che utilizza anche la logica aziendale principale
• Esistono app per smartphone (iOS e Android) che utilizzano l'API dell'applicazione
• Esistono un'altra app per tablet (Android) diversa da quella per smartphone che utilizza la stessa API dell'applicazione.

Presto sarò in produzione con clienti attivi. E come qualsiasi progetto, dovrò mantenere tutti i diversi componenti nel tempo. Ciò significa che è possibile aggiornare tutti i seguenti elementi:

• il codice della logica di business principale nel server (utilizzato dal back-office, dall'API e, come effetto collaterale, dalle app mobili)
• l'API stessa (utilizzata dalle app per smartphone e tablet)
• tutte le app mobili (tramite appstore / googleplay)

Naturalmente, le parti sul lato server (codice della logica aziendale principale e codice API) possono essere modificate immediatamente da solo. Tuttavia, le nuove app mobili devono essere scaricate dai client sull'appstore / googleplay e non posso essere sicuro che siano aggiornate.

Potresti fornire qualche consiglio, consigli sulle buone pratiche, per rendere questi aggiornamenti fluidi e senza scrupoli per il cliente?

Di quale componente ho bisogno per "versione"? Come garantire che tutto funzioni anche se il client non aggiorna la sua app mobile? Dovrei costringerlo ad aggiornare per semplificare il mio lavoro?

In una parola, come dovrei organizzarmi per rendere vivo il mio progetto su più lati nel tempo?

Poiché non puoi controllare quando le app mobili verranno aggiornate a una nuova versione, devi almeno la versione dell'API REST. In caso contrario, sarà impossibile apportare modifiche incompatibili all'indietro a tale interfaccia.

Oltre all'API REST, è consigliabile eseguire la versione anche delle altre interfacce di comunicazione che passano attraverso un'interfaccia di rete. In questo modo, non sei nemmeno obbligato ad aggiornare tutti i client di backoffice contemporaneamente ai server e puoi implementare una migrazione graduale verso una nuova versione con un periodo di "beta test".

Oltre al controllo delle versioni delle interfacce di comunicazione, dovresti anche provare a rendere le modifiche all'indietro il più possibile compatibili. Idealmente, potresti implementare una nuova versione dell'interfaccia che supporta ancora completamente i vecchi client in modo che non si accorgano che nulla è cambiato.

Questo post fa un punto interessante sulla tua domanda.

In un modo più pratico, se hai 3 componenti:

• 2 consumatori: un front-end e un'app mobile
• 1 provider API: un back-end

Puoi usare il tipico schema di controllo delle versioni di Mmp (Major.minor.patch) per ciascuno di essi, ma sul tuo URL back-end puoi mettere qualcosa come http://youhost/M.m/resourceURI.

Man mano che evolvi e le modifiche all'API non influiscono sul tuo contratto con i consumatori, mantieni M.ml'URL così com'è. Dal momento in cui apporti un cambiamento nel BackEnd che interessa i tuoi consumatori (sia esso un cambiamento nel comportamento o un oggetto diverso) usi un M.m+1, M+1.m+1o M+1.m.

Il modo per mantenere le cose in esecuzione è distribuire il nuovo back-end contemporaneamente al vecchio, mentre gli utenti installano i nuovi consumatori e interrompono lentamente l'API precedente.

Puoi vedere una risposta migliore della mia, qui: API REST di versione su StackOverflow

Ti consiglio di installare un server di integrazione continua, collegarlo al tuo repository di codici e un repository di snapshot / release e automatizzare le tue build. Ciò avrà una serie di vantaggi:

1. Ogni componente verrà aggiornato quando viene rilasciato. Ciò include le librerie di basso livello e i prodotti finali.
2. Ogni commit del codice attiverà una generazione di istantanee. Questo aiuta a mantenere gli sviluppatori onesti, soprattutto se si utilizza la funzione per inviare un'email al colpevole che ha rotto la build.
3. Ogni build può eseguire test unitari. Ciò migliora notevolmente la qualità del codice.
4. Ogni versione verrà taggata, quindi se è necessaria una correzione di produzione, è facile diramare dal tag ed eseguire la correzione.
5. Sarà necessario mantenere un registro di compatibilità di qualche tipo. (ad es. BackOffice 1.0.23 è compatibile con l'API REST 2.0.267 ecc.). Non conosco uno strumento che possa aiutare in questo settore.

La mia esperienza è stata con strumenti open source: SVN, Maven 2, Jenkins e Nexus, ma ci sono alternative a tutti questi.

Non sottovalutare il tempo di apprendimento per velocizzare la tua squadra. Ma una volta che saranno pronti, non torneranno mai più indietro.

Per un team relativamente piccolo per lo sviluppo e la distribuzione, il modello di compatibilità Client N-1 utilizzato da IBM Jazz potrebbe funzionare abbastanza bene

Cerca di mantenere client e server con lo stesso numero di versione. [Invece di gestire una matrice di versioni indipendenti e loro compatibilità]

Prepara una politica secondo cui la versione client Xyy dovrebbe funzionare con tutte le versioni server precedenti a Xyy ma inferiori a X + 2.0.0

Per un server versione 4.0, idealmente dovrebbe esserci un client versione 4.0 per ogni tipo di client. Tuttavia, la compatibilità dovrebbe essere mantenuta in modo da consentire versioni leggermente diverse di client e server.

Una versione client 4.x dovrebbe essere compatibile con i server versione 4.x e successive ma inferiori a 6.0; Un server 4.x dovrebbe essere compatibile con tutti i client versione 3.0 e successive ma inferiore o uguale a 4.x

In questo modo puoi aggiornare una versione sul server senza preoccuparti del rilascio immediato di nuove versioni dei client, ma avrai solo una finestra di compatibilità ben definita da mantenere.

Rif: IBM Jazz Model [ https://www.ibm.com/support/knowledgecenter/en/SSYMRC_6.0.0/com.ibm.jazz.install.doc/topics/c_n-1.html]

Per prima cosa, devo iniziare inquadrando il problema in modo leggermente diverso. Hai chiesto quali software sono necessari per "versione". Versione è un termine sovraccarico in CS e potrebbe significare circa 100 cose diverse. Le cose principali che vorrei guardare è:

1. Controllo versione: il controllo versione è uno strumento di gestione della configurazione che consente di tenere traccia delle istantanee e della cronologia dello sviluppo. TUTTO IL CODICE DOVREBBE ESSERE SOTTO CONTROLLO VERSIONE. Non mi importa se sono solo gli script di convenienza che aggiungi alla tua cartella bin, tutto ciò che valeva la pena spendere tempo a scrivere vale i due secondi da aggiungere a un software di controllo delle revisioni.
2. Gestione della configurazione - Come posso controllare cosa c'è nella build. Tutto il software dovrebbe avere un certo grado di gestione della configurazione. Mi piace descrivere ai gestori la differenza tra controllo della versione e gestione della configurazione poiché il controllo della versione è solo uno strumento per tenere traccia della cronologia di sviluppo, mentre la gestione della configurazione è le linee guida su come creiamo la cronologia e su come facciamo cose come decidere il codice è buono.
3. Versione del software: assegnazione di nomi alle versioni di codice. Questa è la cosa a cui molte persone si aggrappano quando vedono il problema per la prima volta perché sono abituati a vedere "MineSweeper 7.1.29290149210" o qualsiasi altra cosa sulle cose che acquistano, ma sinceramente trovo che questa sia la parte minore di un problema molto più grande. Ad essere onesti, basta usare l'hash generato da 1 e non preoccuparsi tanto di ciò che non è leggibile dall'uomo.

Quindi, dato che è il più nebuloso e più interessante per me, mi concentrerò solo sul n. 2. Non esiste una soluzione taglia-cookie unica per tutti, per la gestione della configurazione. Le regole che funzionano bene per un team di 2 o 3 possono essere troppo allentate per mantenere la sanità mentale in un progetto che impiega centinaia di lavoratori. Le regole che funzionano per la grande squadra possono richiedere troppe spese generali per la piccola squadra. Molto probabilmente dovrai mettere insieme qualcosa di tuo per mettere insieme qualcosa, ma userò il seguente elenco come modo per sviluppare le specifiche del tuo sistema di gestione della configurazione:

1. Come posso tenere traccia delle versioni (e dei problemi ad esse associati) che sto supportando sul mercato?
2. Come deciderò quali percorsi di sviluppo sono pronti per il rilascio ai sistemi di produzione? (Potrebbe anche essere pronto per qualsiasi altro passaggio in un processo)
3. Chi dovrebbe avere il controllo / gestire la configurazione del sistema? Qual è il flusso di lavoro per l'aggiunta di codice da distribuire ad altri sviluppatori?
4. Come posso controllare l'interazione tra parti interagenti? Come faccio a sapere se la modifica di una parte interromperà il resto del sistema?
5. Come potremo migliorare il nostro sistema di gestione della configurazione nel tempo.

Hai bisogno di aiuto per rispondere alle domande sopra? Probabilmente dovresti assumere un consulente o un responsabile dell'ingegneria del software ... una risposta che può riempire i libri di testo ed è fuori portata per questo tipo di forum.