framework di applicazioni hosted centralizzato o "copie private" per ciascun programma?

Naviga le tue risposte
2

Abbiamo un framework per applicazioni aziendali centralizzato e contiene tutta la nostra logica aziendale e fornisce l'accesso a tutti i nostri sistemi di back-end. Vi si accede da una serie di diversi programmi e client tramite servizi remoti.

Quando abbiamo bisogno di fare un cambiamento in una certa parte del programma, al momento dobbiamo sottoporre nuovamente a test tutti i nostri diversi programmi e client. Anche supponendo di estendere i nostri test automatizzati, riteniamo che non ci sia modo di essere certi che rilasciando una nuova versione del nostro framework applicativo tutti i diversi programmi funzioneranno correttamente dopo tale modifica senza ripetere manualmente tutti questi programmi. Ogni volta che rilasciamo una nuova versione del progetto C, dobbiamo testare anche i programmi A e B per modifiche involontarie.

Preferibilmente, passeremmo a un sistema di rilascio dove, rilasciando il progetto C, dovremo ripetere solo il test del programma C, e non A e B per eventuali modifiche di rottura che abbiamo trascurato.

L'idea vive per duplicare il nostro quadro applicativo aziendale centralizzato, uno per ciascun sottoprogetto. Significherebbe che quando pubblicheremo una nuova versione del programma C, forniremo una versione privata del framework dell'applicazione. Al rilascio del programma C, nulla sarà cambiato per l'applicazione A e B, essi comunicano ancora con il loro framework di applicazione privato - quindi non è necessario sottoporli a test.

Ho trovato i seguenti pro e contro:

Aspetti negativi:

  • Avremo il nostro framework ospitato n volte per ogni progetto
  • Ci confonderemo in quale versione / progetto quale bug è stato risolto.
  • Con una correzione / modifica importante, dovremo rilasciare nuovamente tutte le n versioni del framework dell'applicazione.

Professionisti:

  • Riduce notevolmente i test
  • "Certezza" che nessuna modifica non intenzionale è stata rilasciata per diversi progetti.

Devo ammettere che non sono un fan dell'approccio delle copie private, ma non riesco a fornire un'alternativa migliore, o argomenti migliori contro questo.

Qualcuno si è trovato in una situazione simile e come è stato gestito? L'approccio sopra descritto di "quadri privati" copia un approccio solido / accettato? Qualsiasi consiglio è ben accetto.

Grazie in anticipo.

    
posta Jonas 05.09.2011 - 11:53
fonte

1 risposta

4

Il tuo framework, come qualsiasi codice di libreria, dovrebbe essere un progetto separato, con versioni. E ogni app dovrebbe dipendere da una versione specifica del framework.

Ogni volta che apporti modifiche al framework, la sua versione dovrebbe cambiare e la nuova versione dovrebbe essere resa disponibile in aggiunta alle vecchie versioni ancora disponibili per le altre app.

È quindi possibile passare a ciascuna app desiderata o necessaria per una nuova versione (er) del framework. E puoi "smontare" una versione quando non è ancora presente in una singola app come dipendenza.

Sì, ci sarà una duplicazione, ma con una struttura di cartelle corretta e qualche configurazione nelle app la duplicazione può essere limitata ai file distribuiti / implementabili. Tutti gli altri dopplication dovrebbero essere nel tuo sistema di controllo della versione (che spero tu usi ...).

Guarda il tuo framework come un altro framework come .Net. Il mio provider di hosting rende felicemente la versione 2.0, 3.5, 4.0 ... disponibile e quella utilizzata per il mio sito è definita da un'impostazione di configurazione che può essere diversa dalle impostazioni di configurazione di qualsiasi altro sito ospitato dallo stesso server.

Per quanto riguarda i tuoi contrari :

  • Non vedo più versioni ospitate come un problema. Se mai, rende le dipendenze molto più esplicite e ti consente di sviluppare il framework con sicurezza.
  • Indipendentemente dalla confusione in quale versione / progetto viene corretto un bug dipende interamente dal sistema di tracciamento dei bug. Inoltre il framework dovrebbe essere il suo progetto. Non ho menzionato questo perché per me è così ovvio che non mi aspettavo che qualcuno lo avesse / cambiando come parte di un altro progetto.
  • Sì, se una correzione è abbastanza importante da essere applicata alle versioni precedenti, dovrai infatti correggere tutte le versioni precedenti (e successive). Ma questa è una buona cosa. Ti farà riflettere due volte sul fatto che una cosa sia o meno "fissata a caldo" (che richiede la modifica di tutte le release attualmente mantenute) o solo qualcosa che le altre app possono ottenere quando passano a una versione più recente del tuo framework.
risposta data 05.09.2011 - 12:43
fonte

Leggi altre domande sui tag

Framework esterno per risolvere i problemi di crescita del codice Come descrivere framework / funzionalità di un'applicazione java per la presentazione client?