Modello di manutenzione per artefatti esterni

Question

Modello di manutenzione per artefatti esterni

#1 da (1 voti)

7

Quando pensiamo di mantenere una soluzione software in modo olistico, dobbiamo pensare a cose come il controllo delle modifiche senza codice e la gestione della configurazione, oltre al codice sorgente effettivo. Ad esempio, per mantenere una grande applicazione Web, tracciamento:

"Make the following (manual) configuration change to the farm, as part of deploying this specific xx.yy.zz version of the solution package."

Ho implementato un modello abbastanza buono per questo, ma ora sto affrontando il problema successivo più grande: come gestiamo i cambiamenti in altri sistemi che non possediamo? Facciamo un semplice esempio:

Abbiamo un'applicazione ASP.NET di proprietà di un team di soluzioni (chiamiamole il Team PLM). La loro prossima versione include una modifica che richiede che il team SAP (che si trova sotto un ombrello di manutenzione diverso) distribuisca anche una modifica a uno dei loro endpoint BAPI.

Naturalmente il coordinamento effettivo dello spiegamento al momento del rilascio è semplice interazione umana & coordinamento, ma in termini di SDLC totale:

Come funziona il nostro esempio "PLM Team" pacchetto & traccia questa dipendenza come un artefatto, sia come una modifica imminente che, dopo la distribuzione, una dipendenza gestita con i requisiti di cui è proprietaria, ma un'implementazione che non controlla direttamente?
Qual è l'informazione giusta da catturare in merito? Come dovrebbe essere trattato in modo diverso rispetto agli elementi di configurazione non di codice che controllano?

development-process maintenance sdlc enterprise-architecture

posta Rex M 24.08.2012 - 21:17

fonte

1 risposta

Leggi altre domande sui tag development-process maintenance sdlc enterprise-architecture

Programmazione di "tutto" usando HTML5? Dove è appropriato effettuare la convalida dell'input in Erlang?

score 1 · Answer 1

Se due team comunicano costantemente, si tratta piuttosto di interazione e coordinamento umano, non di processi aziendali. Sei solo d'accordo su come cambierà l'interfaccia utilizzata da entrambi i progetti, applichi la modifica e distribuirai entrambi i prodotti nello stesso momento. Allo stesso tempo, voglio dire che disconnetti una macchina da una fattoria, interrompi entrambe le app, quindi gli aggiornamenti vengono applicati a entrambe le app, quindi riprendono a funzionare e la macchina può tornare alla farm.
Se due squadre non riescono a comunicare molto bene (o perché si trovano in città diverse geograficamente o perché si odiano a vicenda, o comunque), non c'è davvero nulla che tu possa fare dal punto di vista del processo aziendale per aggiornare entrambe le applicazioni a allo stesso tempo.

In questo secondo caso, sei nel ruolo di un grande provider API che ha rilasciato una nuova versione dell'API, ma ha molti clienti che stanno ancora utilizzando la vecchia versione. Se la prossima versione non si estende¹ la prima, ma cambia², dovresti continuare ad eseguire entrambe le versioni.

Questo significa che avrai entrambi:

http://api.example.com/products/get/5

e

http://api.example.com/v2/d6w9UbnZ50/products/get/5
                       ↑       ↑
                    version  token

e mentre i nuovi client potranno beneficiare dell'API RESTfull utilizzando la seconda versione, i client precedenti che fanno affidamento sulle sessioni potranno comunque utilizzare l'API.

Poiché il tuo progetto è utilizzato da un solo altro progetto, entrambi sviluppano e mantengono due versioni dello stesso progetto sono proibitive in termini di costi . Ciò significa che una volta sviluppata e testata la seconda versione, dovresti provare a forzare l'altro team a iniziare a utilizzare la seconda versione il prima possibile . Questo significa anche che se aprono un ticket che dice che c'è un bug nella tua prima versione, questo ticket deve essere immediatamente chiuso come "non risolverà" con una nota che la prima versione non viene più mantenuta.

^{¹ Estensione: l'aggiunta di un argomento facoltativo al metodo en esistente o l'aggiunta di un overload o un nuovo metodo non interrompono l'API corrente.}

^{² Modifica: rinominando i metodi per renderli più espliciti o rimuovendo un argomento o aggiungendo uno obbligatorio interromperà l'API corrente.}