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
eDEMO
); 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?