Come gestisci il controllo delle versioni in un progetto a più lati?

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

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

Oltre alla versione delle interfacce di comunicazione, dovresti anche provare a rendere le modifiche retro-compatibili il più possibile. Idealmente potresti distribuire una nuova versione dell'interfaccia che supporti ancora pienamente i vecchi client in modo che non si accorgano che qualcosa è cambiato.

Questo post fa un punto interessante su la 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

Potresti utilizzare il tipico schema di controllo delle versioni M.m.p (Major.minor.patch) per ciascuno, ma, nel tuo URL di back-end potresti inserire qualcosa come http://youhost/M.m/resourceURI .

Man mano che evolvi e i cambiamenti nell'API non influenzano il tuo contratto con i consumatori, mantieni il M.m come nell'URL. Dal momento in cui apporti una modifica a BackEnd che influisce sui tuoi consumatori (che si tratti di un comportamento diverso o di un oggetto diverso), utilizzi un M.m+1 , M+1.m+1 o M+1.m .

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

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

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

1. Ogni componente verrà sottoposto a version quando verrà rilasciato. Ciò include le librerie di basso livello e i tuoi prodotti finali.
2. Ogni commit di codice attiverà una build di istantanee. Ciò aiuta a mantenere i tuoi sviluppatori onesti, soprattutto se usi la struttura per inviare email al colpevole che ha rotto la build.
3. Ogni build può eseguire test unitari. Migliora sensibilmente la qualità del codice.
4. Ogni versione verrà taggata, quindi se è necessaria una correzione di produzione, è facile deviare dal tag e correggere.
5. Sarà necessario mantenere un registro di compatibilità di qualche tipo. (Ad esempio, BackOffice 1.0.23 è compatibile con REST API 2.0.267, ecc.). Non conosco uno strumento che aiuti in quest'area.

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

Non sottovalutare il tempo di apprendimento per far crescere la tua squadra. Ma una volta che sono alla velocità, non torneranno mai indietro.

Per un team relativamente piccolo per lo sviluppo e l'implementazione, il modello di compatibilità N-1 del client utilizzato da IBM Jazz potrebbe funzionare abbastanza bene

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

Stabilire un criterio in base al quale la versione client X.y.y dovrebbe funzionare con tutte le versioni dei server superiori a X.y.y ma inferiori a X + 2.0.0

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

Una versione 4.x del client dovrebbe essere compatibile con i server versione 4.xe successiva ma inferiore 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.

Ref: Modello IBM Jazz [ link

Per prima cosa, parto dal framing del problema in modo un po 'diverso. Hai chiesto quali pezzi di software devi "versione". La versione è un termine sovraccarico in CS e potrebbe significare circa 100 cose diverse. Le cose principali che vorrei guardare sono:

1. Controllo versione - Il controllo versione è uno strumento di gestione della configurazione che ti aiuta a tenere traccia delle istantanee e della cronologia del tuo sviluppo. TUTTO IL CODICE DEVE ESSERE SOTTO CONTROLLO VERSIONE. Non mi interessa se solo gli script di convenienza che aggiungi alla tua cartella bin, tutto ciò che valeva la pena spendere del tempo per scrivere vale i due secondi da aggiungere a una revisione software di controllo.
2. Gestione della configurazione - Come controllo ciò che è 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 come controllo della versione è solo uno strumento per tracciare la cronologia dello sviluppo, mentre la gestione della configurazione è linee guida per come creiamo la storia e come facciamo le cose come decidere che il codice sia buono.
3. Controllo delle versioni del software - assegnazione dei nomi alle versioni di codice. Questa è la cosa a cui molte persone si attaccano quando vedono per la prima volta il problema perché sono abituati a vedere "MineSweeper 7.1.29290149210" o qualsiasi altra cosa sulla roba che acquistano, ma sinceramente trovo questa la parte più piccola di un problema molto più grande. Per essere onesti, basta usare l'hash generato da 1 e non preoccuparsi di tutto quello che non è leggibile da un punto di vista umano è perfettamente a posto.

Quindi, dato che è il più nebuloso e più interessante per me, mi concentrerò sul # 2. Non esiste una soluzione taglia unica adatta alla gestione della configurazione. Le regole che funzionano bene per una squadra di 2 o 3 possono essere troppo lente per mantenere la sanità mentale in un progetto che richiede centinaia di lavoratori. Le regole che funzionano nella grande squadra possono richiedere troppo spese generali per il piccolo team. Molto probabilmente dovrai mettere insieme qualcosa di tuo per ottenere qualcosa insieme, ma utilizzerei il seguente elenco come un modo per sviluppare le specifiche per il tuo sistema di gestione della configurazione:

1. Come posso tenere traccia delle versioni (e dei relativi problemi) che sto sostenendo sul mercato?
2. Come deciderò quali percorsi di sviluppo sono pronti per il rilascio nei sistemi di produzione? (Potrebbe anche essere pronto per qualsiasi altra fase di un processo)
3. Chi dovrebbe avere il controllo / gestione della configurazione del sistema? Qual è il flusso di lavoro per l'aggiunta del codice da distribuire ad altri sviluppatori?
4. Come faccio a controllare l'interazione tra le parti interagenti? Come faccio a sapere se la modifica di una parte interromperà il resto del sistema?
5. Come miglioreremo 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 ... rispondendo che può riempire i libri di testo ed è molto fuori portata per questo tipo di forum.