Strategie di promozione delle dipendenze: taciute o orchestrate?

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

• Non-Production
  • DEV- Ambiente di sviluppo integrato in cui CI costruisce cambiamenti push; utile per gli ingegneri per risolvere bug difficili da trovare che non sono riproducibili localmente
  • QA - Ambiente di prova / QA isolato
  • DEMO - Ambiente UAT stabile per gli stakeholder aziendali
• Produzione
  • LIVE - Il nostro ambiente live / di produzione

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

Supponiamo di avere un'applicazione chiamata myappche è supportata da un servizio Web RESTful chiamato myws, che a sua volta è supportato da un DB chiamato mydb.

Attualmente, tra queste dipendenze abbiamo quella che definirei promozione " orchestrata ": i myapp-devpunti a myws-devcui si serve mydb-dev. Allo stesso modo, myapp-qaindica a myws-qaquali usi mydb-qa. Lo stesso per DEMOe LIVE.

Il problema è che ogni volta che apporto una modifica, diciamo myapp, ciò mi richiede di apportare modifiche mywse mydbanche. Ma poiché ogni DEVambiente punta agli ambienti delle sue dipendenze DEV, significa che devo pianificare e implementare tutte queste modifiche contemporaneamente. Inoltre, se una build diventa instabile / rotta, spesso porta giù altri componenti a monte; per esempio se uno sviluppatore rompe qualcosa quando cambia mydb-dev, anche i cluster myws-deve myapp-devdiventano di solito instabili.

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

• Dipendenze a monte dipendono DEMOambiente per loro dipendenze a valle, per tutte le loro ambienti non di produzione ( DEV, QAe DEMO); e
• Le dipendenze a monte dipendono LIVEdall'ambiente per le loro dipendenze a valle per il loro ambiente di produzione

Usando questa convenzione, myapp-devattiveremmo a tutti myws-demo, che sarebbe utile mydb-demo. Allo stesso modo, myapp-qaindicherebbe anche myws-demoe mydb-demo.

Il vantaggio che posso trovare è la stabilizzazione di compilazione : è molto meno probabile che l' DEMOambiente per un particolare componente diventa instabile, perché il codice non ce la fa a DEMOnon rigorosi test sia su DEVe QA.

L'unico svantaggio che posso trovare in questo metodo è che, se DEMOsi rompe per un particolare componente, tutti gli ambienti di non produzione per tutte le dipendenze a monte verranno improvvisamente rotti. Ma direi che ciò dovrebbe accadere molto raramente a causa dei test eseguiti su DEVe QA.

Questo ha ottenuto di essere un problema che molti sviluppatori (molto più intelligente e con esperienza di me) hanno risolto, e io non sarei sorpreso se questo problema e le sue soluzioni sono già nomi a loro (oltre a ciò che io chiamo orchestrato / silos). Quindi chiedo: i meriti di una strategia di promozione insensata superano qualsiasi contro, e quali sono i contro che potrei trascurare qui?

Se sto leggendo bene il tuo post, non sembra che questa proposta risolva effettivamente nessuno dei presunti problemi.

ogni volta che apporto una modifica, ad esempio, a myapp, ciò richiede che apporti anche modifiche a myws e mydb. Ma poiché ogni ambiente DEV indica gli ambienti DEV delle sue dipendenze, significa che devo pianificare e implementare tutte queste modifiche contemporaneamente

La "strategia di promozione insensata" sembra peggiorare le cose. Se myapp v2, myws v2 e mydb v2 sono solo su DEV, e myapp v2 si affida a mydb v2 per non arrestarsi in modo anomalo, quindi quando provo a eseguire myapp v2 su DEV, premo mydb v1 DEMO e si arresta in modo anomalo. In sostanza, saresti costretto a scavalcare costantemente i silos o distribuire mydb v2 fino a produrre prima di poter iniziare a lavorare su myapp v2. Ancora più importante, non testeresti mai mydb v2 su DEV, quindi se è rotto non lo scopri nemmeno fino a quando non si rompe su DEMO, e poi sei tornato al punto di partenza.

In una certa misura, il problema che descrivi è inevitabile, indipendentemente dalla configurazione del flusso di lavoro, ma può essere ridotto al minimo. Il trucco è garantire che l'interfaccia tra mydb e myws (e l'interfaccia tra myws e myapp) sia definita in modo rigoroso e che tutti gli aggiornamenti di tale interfaccia siano pienamente compatibili con le versioni precedenti . Nel mio lavoro abbiamo uno schema XML che definisce l'interfaccia tra le nostre app e servizi e molti dei nostri strumenti interni semplicemente non ci consentono di effettuare aggiornamenti incompatibili a tali schemi.

Inoltre, se una build diventa instabile / rotta, spesso porta giù altri componenti a monte; per esempio se uno sviluppatore rompe qualcosa quando cambia mydb-dev, anche i cluster myws-dev e myapp-dev diventano di solito instabili.

Questo mi sembra un problema serio, ma non un problema di distribuzione. Un database danneggiato impedirà sicuramente il corretto funzionamento del servizio e dell'app, ma non dovrebbero diventare "instabili". Dovrebbero restituire messaggi di errore di qualche tipo, in modo che chiunque esegua myapp su dev visualizzi "Siamo spiacenti, il nostro database sta riscontrando problemi oggi" invece di semplicemente arrestarsi in modo anomalo.

Se il problema è che un database non funzionante causa questi problemi, allora quello che puoi fare è impostare un sistema di "siloing temporaneo" che ti permetta di dire "mydb DEV adesso è rotto, per favore indirizza tutte le query myws DEV a mydb DEMO per il per ora". Ma questo dovrebbe essere solo un modo per eseguire correzioni temporanee fino a quando mydb DEV non funziona di nuovo normalmente. Se tutto è "insiliato" in quel modo di default, allora sei tornato ai problemi che ho descritto sopra perché nessuno corre mai contro mydb DEV.

Mi sento come se stessi probabilmente fraintendendo la tua proposta in qualche modo, ma spero che questa risposta almeno renda evidente ciò che veniva frainteso e il modo migliore per riformularla.