Si tratta di un ambiente QA di Azure valido e possibile?

Question

Sto cercando di formulare un ambiente di sviluppo/controllo/controllo di qualità valido per la suite di applicazioni della mia azienda per migrare ad Azure. Tuttavia, sto forzando il vincolo su di noi che il nostro dev/test/qa/etc. gli ambienti sono effettivamente ospitati on-premise e distribuiti tramite un server di build (come CC.NET, TeamCity, Jenkins, ecc.).

In tale "Ambiente di test", abbiamo bisogno della capacità di attivare implementazioni di una specifica istantanea di codice (e dati) non rilasciati per un team di professionisti del QA e di Business per testare sia per i test tecnici che per i test di accettazione aziendale. Chiaramente tutte queste persone non compilano e colpiscono F5 in Visual Studio per fare questo test, quindi abbiamo bisogno di un ambiente per la distribuzione. Nel nostro SDLC, in realtà passiamo attraverso ~ 4 tali ambienti prima di arrivare alla messa in scena e alla produzione. In breve, abbiamo bisogno di un basso overhead (distribuzioni automatizzate) e di un processo facilmente riproducibile per questo.

Nella pianificazione di questo ambiente, la domanda "Come ospitare i servizi di Azure" è chiaramente la parte difficile. Quindi esaminiamo ogni parte di Azure. Le opzioni in corsivo sono quelle che vogliamo seguire.

• ruoli Web Beh, IIS può più o meno gestire questi per noi (almeno abbastanza per le situazioni dev/test - tutti, ma reale test di carico che chiaramente avremmo fare in Azure, che va bene).
• Ruoli di lavoro Abbiamo due opzioni qui, a quanto pare. Il primo è di avere una "app wrapper" che è un servizio di Windows e possiamo usarla per ospitare le DLL che i nostri Worker Roles chiamano per funzionalità (dopotutto, il nostro vero progetto Worker Role non dovrebbe essere altro che un file di configurazione e ~ 4 righe di codice che chiama una DLL per funzionare). Questa opzione funziona, ma richiede un codice applicativo e una gestione/manutenzione del codice di implementazione molto diversi. La seconda opzione consiste nell'utilizzare l'emulatore di calcolo di Azure. Questo funziona fintanto che i tuoi ruoli di lavoro non hanno bisogno di monitorare le porte esterne o altro. Nel nostro caso, i nostri ruoli di lavoro devono solo monitorare le code e successivamente accedere a varie risorse. I problemi con questo ruotano attorno ai diversi script di compilazione perché l'unico modo per automatizzare una distribuzione su Emulatore di Azure è eseguire CSPack e CSRun sul computer che ospita Azure Emultor, che probabilmente non è il server di build. Per questo motivo, dovrai eseguire una sorta di script remoto per ottenere questo risultato.
• VM ruoliNoi in realtà non si preoccupano di questi, quindi sono totalmente ignorando questo aspetto del test.
• Code Qui, abbiamo 3 opzioni. Il primo è usare MSMQ. Poiché ciò richiede una base di codice completamente diversa che non abbiamo (o almeno un'astrazione attorno a quella base di codice diversa), non sto considerando questa opzione. Il secondo è quello di mantenere le code in Azure poiché sono così piccole/economiche. In realtà lo stiamo facendo temporaneamente fino a quando non possiamo provare la terza opzione. La terza opzione è utilizzare l'emulatore di archiviazione di Azure. Non sono sicuro, ma credo che questa opzione consentirà solo i servizi in esecuzione sul computer locale per accedere agli oggetti di archiviazione. Per Code, il nostro codice applicativo è il codice che "distribuisce" effettivamente le code, quindi dovrebbe essere corretto purché il nostro codice applicativo sia effettivamente in esecuzione sul server che ospita l'Emulatore di archiviazione di Azure.
• Tabelle Qui, abbiamo 3 opzioni.Il primo è uno che odio e cioè utilizzare un database e creare una tabella per accedere a queste tabelle. Non sto considerando questa opzione. Il secondo è quello di mantenere le tabelle in Azure. Non mi piace perché è un sacco di avanti e indietro per cose che potrebbero archiviare dati di dimensioni significative (fino a 1 MB per record). Mentre le code sono incredibilmente leggere ed economiche, il costo del tavolo può essere abbastanza rapido. Questo ci lascia alla terza opzione, utilizzando l'emulatore di archiviazione di Azure. Non sono sicuro, ma credo che questa opzione consentirà solo i servizi in esecuzione sul computer locale per accedere agli oggetti di archiviazione. Non riesco ancora a capire tutte le tabelle pros/cons dell'emulatore.
• Blob Qui, abbiamo davvero 2 opzioni. Il primo è cattivo e ciò li tiene in Azure. Questi sono probabilmente file di dimensioni significative, quindi non è saggio. Pertanto, la seconda opzione, ancora una volta, consiste nell'utilizzare l'emulatore di archiviazione di Azure. Penso che questo sia ciò che dobbiamo fare.

Quindi, dato che abbiamo MVC Apps (ruolo web), servizi web WCF (ruolo web), code, Tavoli, ruoli Blobs, e dei lavoratori che vengono attivati ​​dalle code ma le tabelle di accesso, blob, e WCF servizi web, sembra un modo ragionevole per ospitare i nostri ambienti interni di QA (e simili)? E a parte qualche seccatura con lo scripting remoto CSPack e CSRun da distribuire all'emulatore di Azure, tutto questo sembra ragionevolmente automatizzabile con un server di build?

Answer 1

IMHO: Stai saltando attraverso troppi telai per non doverlo distribuire ad Azure per gli ambienti di QA Dev & perché non solo distribuire e testare gli script di distribuzione nello stesso tempo? Utilizza istanze xtra-small per mantenere bassi i costi.

L'emulazione di archiviazione non è/che/ottima affatto. Ci sono molte piccole differenze che renderanno il tuo test inaffidabile. Né stai testando il bilanciamento del carico - qualcosa che potrebbe trovare problemi con qualsiasi non pianificato per lo stato di sessione

Answer 2

Uno dei consigli più utili su Azure I è "Test su Azure il più presto possibile". Ti aiuterà ad affrontare le differenze tra Azure ed emulatore reali il prima possibile nel tuo ciclo di sviluppo, e ce ne sono molte.

In secondo luogo, le soluzioni alternative sembrano un sacco di lavoro solo per avere ambienti di test. Penso che l'hosting su Azure sarebbe più economico. E alla fine, dovrai ancora eseguire il test su Azure prima di rilasciare il tuo prodotto.