Il requisito che il codice cambi all'interno della versione sia inversamente compatibile con lo schema DB

Recentemente ho riscontrato un requisito relativo al nostro processo di rilascio / SDLC che mi sembra un po 'fuori dall'ordinario, quindi scrivo questo per verificare se questa pratica è comune e, in caso contrario, se il nostro processo di distribuzione debba essere modificato per eliminare un vincolo gravoso.

Lavoro per un piccolo negozio di software che produce software aziendale (quindi non è un nome familiare) e abbiamo solo una manciata di clienti ancora grandi. Si tratta di un'applicazione di gestione del sistema multi-server in esecuzione su Linux, back-end DB, front-end Web, molti I / O asincroni e messaggistica. Distribuiamo aggiornamenti ca. ogni 2-3 mesi e i nostri clienti li distribuiscono utilizzando i pacchetti deb o rpm (a seconda del sistema operativo) che forniamo loro. Tutti i clienti distribuiscono l'app in un ambiente cluster con ogni istanza del server che punta a più frammenti di database.

Da qualche tempo ho lavorato su alcuni refactoring legacy che hanno significativamente modificato il nostro schema DB. Per farla breve, ho riorganizzato il modo in cui memorizziamo alcuni dati, diviso alcune tabelle in più nuovi tavoli, ridotto l'esposizione alle condizioni di gara e apportato modifiche al codice corrispondenti.

Proprio mentre mi stavo preparando a presentare le mie modifiche, il nostro architetto di sistema mi ha informato che "a causa del modo in cui i nostri clienti implementano gli aggiornamenti" (ogni server e ogni database separatamente, uno per uno e può richiedere giorni se non settimane, durante le quali alcuni server devono rimanere alzati), non possiamo avere modifiche strettamente accoppiate e tutti gli aggiornamenti di codice devono essere compatibili con il database inverso entro un periodo di un ciclo di rilascio. IOW, non possiamo rimuovere campi dalle tabelle del database perché in tutte le configurazioni dei clienti tutti i server puntano a tutti i frammenti del database e dobbiamo abilitare un server a lavorare simultaneamente con un frammento che viene aggiornato insieme a un altro che non lo è.

Ora, sono stato confuso e turbato da questo requisito per non dire altro. Sembrava indicativo di problemi che il modo in cui i nostri clienti amano implementare le modifiche (impiegando molto tempo), così come la loro configurazione, ci impone di fornire ingombrante doppia funzionalità in parallelo. Nel mio caso particolare, mi è stato detto che ho bisogno di mantenere i campi refactored nelle vecchie tabelle per le letture legacy mentre scrivo nelle nuove tabelle e quindi amalgamare i dati recuperati. Questo mi sembra inutilmente complesso per non dire altro.

Le mie domande sono le seguenti:

1. Questo requisito è insolito per la configurazione generale che ho descritto? Ho lavorato qui per circa sei mesi e non ho mai lavorato per una società di prodotto prima, ho sempre lavorato sul sito che creava e distribuiva app personali (come un sito web, ecc.). Questo scenario è comune nelle società di prodotti software?

2. Questo fenomeno della necessaria compatibilità con DB inverso indica problemi con il modo in cui i nostri clienti desiderano implementare il nostro software? A mia conoscenza, applicano i nostri aggiornamenti manualmente server per server, database per database mantenendo la funzione di produzione. Dovrebbero utilizzare qualcosa come Puppet o Chef per distribuire i nostri aggiornamenti in un lasso di tempo molto ridotto?

3. Come dovrei avvicinarmi alla presentazione della necessità di cambiare tutto questo, presenta un inconveniente per lo sviluppatore, per non dire altro, dover fornire questa funzionalità biforcata?