Strategie di promozione delle dipendenze: silenziate o orchestrate?

Question

Strategie di promozione delle dipendenze: silenziate o orchestrate?

#1 da (7 voti)

10

Abbiamo un sacco di app e servizi web (alcuni prodotti pubblici, alcuni interni e parte di un "back-end" privato) che sono interdipendenti l'uno con l'altro. Ognuno di questi componenti ha 4 ambienti (cluster di server / nodi che servono a scopi specifici):

Non-Production
- DEV - Ambiente di sviluppo integrato in cui le build CI costruiscono le modifiche; utile per gli ingegneri per la risoluzione di bug difficili da trovare che non sono localmente riproducibili
- QA - QA / ambiente di test isolato
- DEMO - Ambiente UAT stabile per gli stakeholder di business
Produzione
- LIVE - Il nostro ambiente di produzione / live

La promozione del codice diventa: LOCAL (macchina dello sviluppatore) = > DEV = > QA = > DEMO = > LIVE .

Diciamo che abbiamo un'applicazione chiamata myapp che è supportata da un servizio web RESTful chiamato myws , a sua volta supportato da un DB chiamato mydb .

Attualmente abbiamo quella che chiamerei la promozione " orchestrata " tra queste dipendenze: il myapp-dev punta a myws-dev che utilizza mydb-dev . Allo stesso modo, myapp-qa punta a myws-qa che utilizza mydb-qa . Lo stesso per DEMO e LIVE .

Il problema con questo è che ogni volta che apporto una modifica a, diciamo, myapp , questo mi impone di apportare modifiche anche a myws e mydb . Ma poiché ogni ambiente DEV punta agli ambienti di DEV delle dipendenze, significa che devo pianificare e implementare queste modifiche tutte contemporaneamente. Inoltre, se una build diventa instabile / interrotta, spesso fa cadere altri componenti a monte; ad esempio se uno sviluppatore rompe qualcosa cambiando mydb-dev , anche i cluster myws-dev e myapp-dev diventano di solito instabili.

Per risolvere questo problema, sto mettendo insieme una proposta per quella che definirei una strategia di promozione " siled : tutte le dipendenze tra componenti seguono questa linea guida:

Le dipendenze upstream dipendono dall'ambiente DEMO per le loro dipendenze downstream, per tutti i loro ambienti non di produzione ( DEV , QA e DEMO ); e
Le dipendenze upstream dipendono dall'ambiente LIVE per le loro dipendenze downstream per il loro ambiente di produzione

Usando questa convenzione, myapp-dev attiverebbe puntualmente a myws-demo , che userebbe mydb-demo . Allo stesso modo, myapp-qa punterebbe anche a myws-demo e mydb-demo .

Il vantaggio qui che posso trovare è stab stabization : è molto meno probabile che l'ambiente DEMO per un particolare componente diventi instabile, perché il codice non può arrivare a DEMO senza test rigorosi sia su DEV che QA .

L'unico svantaggio che posso trovare in questo metodo è che, se DEMO si interrompe per un particolare componente, tutti gli ambienti non di produzione per tutte le dipendenze upstream verranno improvvisamente interrotti. Ma vorrei ribattere che ciò dovrebbe accadere estremamente raramente a causa dei test eseguiti su DEV e QA .

Questo ha ottenuto come un problema che molti sviluppatori (molto più intelligenti ed esperti di me) hanno risolto, e non sarei sorpreso se questo problema e le sue soluzioni avessero già dei nomi ( inoltre quello che chiamo orchestrato / siled). Quindi chiedo: I meriti di una strategia di promozione con silos superano ogni contro e quali sono gli svantaggi che potrei trascurare qui?

release-management continuous-integration environment dependency-management

posta smeeb 17.01.2015 - 20:07

fonte

1 risposta

Leggi altre domande sui tag release-management continuous-integration environment dependency-management

Qual è il punto di collegamento rel="self" in un'API REST? Come progettare il controllo degli accessi basato sui ruoli?

score 7 · Accepted Answer

Se leggo correttamente il tuo post, non sembra che questa proposta risolva effettivamente uno dei presunti problemi.

anytime I make a change to, say, myapp, this requires me to make changes to myws and mydb as well. But because each DEV environment points to its dependencies' DEV environments, it means I have to schedule and rollout these changes all at the same time

La "strategia di promozione siled" sembra che peggiorerebbe solo la situazione. Se myapp v2, myws v2 e mydb v2 sono solo su DEV e myapp v2 si basa su mydb v2 per non bloccarsi, quindi quando provo a eseguire myapp v2 su DEV, colpirò mydb v1 DEMO e si blocca. Saresti essenzialmente costretto a scavalcare costantemente i silos o a distribuire mydb v2 fino al pungolo prima di poter iniziare a lavorare su myapp v2. Ancora più importante, non verificherai mai mydb v2 su DEV, quindi se è rotto non lo scopri fino a quando non si rompe su DEMO, e poi torni al punto di partenza.

In una certa misura, il problema che descrivi è inevitabile, indipendentemente dal modo in cui è impostato il tuo flusso di lavoro, ma può essere ridotto a icona. Il trucco consiste nel garantire che l'interfaccia tra mydb e myws (e l'interfaccia tra myws e myapp) sia rigorosamente definita e richiedere che tutti gli aggiornamenti a tale interfaccia siano completamente compatibili con le versioni precedenti . Al mio lavoro abbiamo uno schema XML che definisce l'interfaccia tra le nostre app e i nostri servizi, e molti dei nostri strumenti interni semplicemente non ci permettono di creare aggiornamenti incompatibili con questi schemi.

Furthermore, if one build becomes unstable/broken, it often brings down other upstream components; for instance if a developer breaks something when changing mydb-dev, the myws-dev and myapp-dev clusters usually also become unstable.

Questo mi sembra un problema serio, ma non un problema di distribuzione. Un database danneggiato sicuramente impedirà il corretto funzionamento del servizio e dell'app, ma non dovrebbe diventare "instabile". Dovrebbero restituire messaggi di errore di qualche tipo, in modo che chiunque abbia in esecuzione myapp su dev visualizzi "Siamo spiacenti, il nostro database ha problemi oggi" invece di limitarsi a bloccarsi.

Se il problema è che un database danneggiato causa questi problemi, allora è possibile configurare un sistema di "siloing temporaneo" che ti permetta di dire "mydb DEV è rotto ora, per favore indirizza tutte le query myws DEV a mydb DEMO per ora ". Ma questo dovrebbe essere solo un modo per eseguire correzioni temporanee fino a quando mydb DEV funziona di nuovo normalmente. Se tutto è "disattivato" in questo modo per impostazione predefinita, sei di nuovo ai problemi che ho descritto sopra perché nessuno ha mai funzionato contro DEV per mydb.

Mi sembra che probabilmente stia fraintendendo la tua proposta in qualche modo, ma spero che questa risposta, almeno, renda ovvio ciò che è stato frainteso e il modo migliore per riformularlo.