Come si ospita un ruolo di lavoro di Azure localmente/su premise?

Question

Alcuni di fondo ....

Stiamo avventurarsi in Azure per la prima volta e stanno cercando di farlo in piccoli passi. Per ora, le nostre prime app saranno ruoli di lavoro che monitorano le code per elaborare le richieste (come l'invio di e-mail o l'esecuzione di alcuni screen scraping) e inseriremo semplicemente le code dalla nostra app MVC on-premise e dai servizi WCF. Sposteremo in seguito l'app MVC e i servizi WCF in Azure.

Il nostro flusso di lavoro di sviluppo va essenzialmente come questo (un po 'modificato in modi poco importanti):

1. Sviluppare a livello locale e su alcuni server condivisi. Controlla nel controllo del codice sorgente.
2. Ogni 15 minuti, costruire server di costruisce e distribuisce a un ambiente di "sviluppo" (raddoppia come CI e copre in caso abbiamo bisogno di colpire un ambiente di "sviluppo" diverso da quello locale)
3. tester tecnici attivare manualmente costruire server per distribuire l'ultimo build "Dev" riuscito nell'ambiente di test (o in alternativa, la build di test precedentemente distribuita, incluso/escluso il database).
4. I tester tecnici ei business tester attivano manualmente il build server per distribuire l'ultima build "Test" di successo (o in alternativa, la build di test precedentemente distribuita, incluso/escluso il database) nell'ambiente di controllo qualità.
5. Ad un certo punto uniamo il changeset che il QA approva per la distribuzione.
6. Successivamente il nostro server di produzione di produzione distribuisce questa versione alla gestione temporanea e successivamente ai nostri ambienti di produzione (la ospitiamo N volte in ambienti paralleli/indipendenti).

Come si può vedere, abbiamo una serie di versioni della nostra app ospitate internamente per le persone di supporto interno che hanno colpito prima di raggiungere la produzione. Vorrei che questi avessero un livello ragionevolmente basso di dipendenza da Azure. Non è necessario completare la dipendenza da sever, quindi continueremo a utilizzare le code di Azure e forse alcuni altri meccanismi solo perché sono facili da continuare a utilizzare, ma non vogliamo che il nostro build server debba essere distribuito in Azure per ognuno di questi ambienti (e in alternativa paga per tutto ciò che ospita).

Quindi, come possiamo ospitare i nostri ruoli di lavoro in locale in modo ragionevole in un modo in cui stiamo testando il codice che viene distribuito in Azure?

Un'opzione che è stata suggerita è che creiamo il ruolo di lavoratore come involucro/facciata e facciamo tutto il lavoro reale all'interno di una libreria di classi, che era il nostro piano. Tuttavia, il follow-up per permetterci di "ospitare" questo sarebbe quello di creare una seconda applicazione wrapper/facciata che esegua lo stesso lavoro del ruolo di worker, solo in un modo in cui possiamo eseguirla come un'attività pianificata o una finestra server. In definitiva, non mi piace questa opzione perché un intero progetto non viene mai testato fino a quando non colpisce la messa in scena.

E 'possibile fare qualcosa di simile in cui si crea una seconda applicazione involucro/facciata che invece di chiamare la libreria di classi che in realtà i riferimenti e chiama la funzione Run() nel ruolo dei lavoratori?

Answer 1

Secondo te Azure emulator potresti aiutarti? Questi sono gli differences tra il vero provider di Azure e l'emulatore.

Avere una facciata per il proprio ruolo di lavoratore sembra ragionevole.E utilizzare adattatori per adattare qualsiasi possibile cloud (o altra tecnologia di hosting) a quella facciata? Sto solo cercando di dare qualche idea. In realtà ho usato questo approccio prima, ma era un progetto "personale".

Utilizzare PowerShell per configurare i ruoli e cosa no. Configura il tuo emulatore di Azure come this.

Answer 2

L'approccio alla facciata è il migliore da adottare, ad essere onesti.

Quando si hanno distribuzioni che dipendono in ultima analisi dall'infrastruttura di supporto, è eccezionalmente difficile testare completamente fino a quando non si distribuisce su un'infrastruttura identica o comparabile. Questo è sicuramente il caso di un ruolo dei lavoratori di Azure.

Separando gli aspetti funzionali della vostra applicazione dall'infrastruttura punti di contatto, è possibile trascorrere il vostro sforzo per garantire che il codice si comporta come dovrebbe, dimostrare che la facciata si comporta come dovrebbe, quindi verificare la fiducia combinazione finale.

C'è sempre qualche elemento di compromesso a questo effetto a meno che gli ambienti di test non siano identici agli ambienti di produzione.

Ed è a cosa serve la distribuzione di gestione temporanea di Azure; quell'ultimo livello di test di fiducia prima di passare alla produzione.

È possibile creare una distribuzione di dimensioni estremamente ridotte, puramente per le fasi successive del test. Paghi per il tempo in cui viene distribuito il ruolo, quindi se elimini la distribuzione una volta completato il test, puoi ridurre al minimo i costi.

Infine, e il modello di facciata è un esempio, design per testabilità. Valuta il tuo codice per massimizzare la quantità che può essere testata prima della distribuzione e riduci al minimo il rischio nelle fasi successive del test.